How we drive new customers to activation

The first thirty days decide most renewals long before the renewal date shows up. An account that gets its workspace live, finishes setup, and hits its first real result in week one tends to stick. An account that signs and then goes quiet — no second login, no setup finished, no teammate invited — is already at risk, and usually nobody notices until the CSM happens to open HubSpot and wonder why an account they haven't heard from in three weeks is still on "customer since" last month.

We run a customer-onboarding agent on Kortix that checks every new account against its onboarding milestones every day, catches the ones that are stalling, drafts a nudge for the customer, and alerts the owning CSM with exactly what's stuck and why. It never changes an account and never sends anything itself — it hands the CSM a head start instead of a surprise churn conversation two quarters later.

The problem

A new account's onboarding progress lives in two places that don't talk to each other: the product events and activation milestones sit in Postgres, and the account record — who owns it, when it became a customer — sits in HubSpot. Neither system on its own tells a CSM whether an account is on track. A login count means nothing without knowing what day of onboarding the account is on; a HubSpot record means nothing without knowing whether the account has actually done anything since it signed.

The usual fallback is a CSM manually checking their book of accounts, or a dashboard that shows raw usage numbers with no sense of what "on track" even means for a given account's age. By the time a stalled account gets noticed, it's often past the point where a simple nudge would have fixed it.

What we built

On Kortix, a daily cron triggers an agent that reads HubSpot for every account inside its onboarding window and owned by a CSM, checks that account's activation milestones and product events in Postgres, and classifies each one as on track, stalled at a specific milestone, or overdue for full activation. For every stalled or overdue account, it drafts a nudge email addressed to the customer's own missed step and posts an alert to the owning CSM's Slack with the specific context — what's done, what's stuck, and what the nudge says. The draft waits in the CSM's inbox; the CSM decides whether to send it, edit it, or reach out a different way.

How it works

Guardrails

The agent touches new, revenue-relevant accounts, so what it can do is narrow and explicit:

• Draft and alert only. The agent never sends the nudge email itself and never contacts the customer directly. The email is a draft in the CSM's inbox until the CSM sends it.
• No account changes, ever. The agent never touches a plan, a seat count, a billing setting, or any other account state — in HubSpot or anywhere else. It reports and drafts; it does not administer.
• Scoped writes. The only thing the agent writes back to HubSpot is which milestone a nudge was last drafted for — never the deal stage, the owner, or any account property a CSM relies on.
• Isolation. Every run happens in its own microVM sandbox. Credentials for Postgres and HubSpot are encrypted in the Secrets Manager and injected at runtime, never exposed to the model or the logs.
• Everything is code. The milestone framework, the stall thresholds, and the per-system permissions are files in the repo, versioned and changed through a reviewed change request rather than a dashboard setting.

The outcome

Onboarding stalls that used to surface only when a CSM happened to look now arrive the same day they start, with the exact missed step and a nudge already written. The agent watches every new account and does the noticing; the CSM still decides what to send and when.