# How we help new customers reach activation A daily agent on Machine checks every new account's onboarding progress in Postgres, writes a nudge email when one gets stuck, and gives the account's CSM the full story in Slack. Canonical page: https://themachine.myapps.ai/use-cases/customer-onboarding Most renewals are won or lost in the first month, long before anyone talks about renewing. A customer who gets their workspace running, finishes setup and sees a real result in the first week usually stays. A customer who signs and then goes silent is in trouble already: no second login, setup half done, not one colleague invited. Often nobody spots it until the CSM opens HubSpot one afternoon and realises an account that joined last month has not made a peep in three weeks. So an agent on Machine now looks at every new account each day and compares it with the onboarding milestones it should have hit. When one is stuck, the agent writes a nudge for the customer and tells the CSM who owns the account exactly what has stalled and why. It never edits an account and never sends a thing by itself. The CSM gets an early warning, not a surprise churn call six months later. - **Team:** Machine - **Runs on:** Once a day, on a schedule - **Connected systems:** Postgres · HubSpot · Slack · Email - **Mode:** Drafts and alerts only · the CSM hits send ## The problem How a new account is getting on is split between two systems that never compare notes. Product events and activation milestones live in Postgres. The account record, including its owner and the date it became a customer, lives in HubSpot. Neither one can tell a CSM if the account is on course. Ten logins mean little if you don't know which day of onboarding the customer is on. A HubSpot record means little if you can't see whether the customer has done anything since signing. Usually the CSM falls back on clicking through their own accounts one by one, or on a dashboard of raw usage numbers that has no idea what "on course" looks like for an account of a given age. By the time someone notices the stall, a friendly nudge is often no longer enough. ## What we built Each day a cron on Machine starts an agent. It pulls from HubSpot every account that is still inside its onboarding window and has a CSM assigned. For each one it looks up the activation milestones and product events in Postgres, then sorts the account into one of three buckets: on course, stuck at a particular milestone, or late for full activation. For every stuck or late account, it writes a nudge email aimed at the exact step the customer skipped, and sends the owning CSM a Slack message with the details: what is finished, what is stuck and what the nudge says. The draft sits in the CSM's inbox. The CSM chooses to send it, change it or contact the customer some other way. ## How it works ### Schedule a daily run A **cron trigger** starts the agent once a day. Each start creates a brand-new **session**, a fresh cloud computer (sandbox) that remembers nothing from yesterday. The account list and all the milestones are read again from HubSpot and Postgres every time. A marker field on the HubSpot record notes which milestone was last nudged, so a stall that lasts a week does not earn the customer seven identical emails. ### Teach the agent your onboarding plan The milestones are written into a **skill**, a playbook that goes wherever the agent goes. It defines what workspace-live, core setup, first activation event, team expansion and full activation each mean, and by which day each one should happen. It also sets the stuck and late cut-offs and the tone a nudge should take. When we learn which milestones really signal a healthy account, we update the skill, and every account gets the benefit the very next day. ### Plug in Postgres and HubSpot **Connectors** are scoped connections to your tools, and the keys stay on our servers rather than with the model. Through them the agent: - **Pulls accounts from HubSpot:** the ones still in the onboarding window, and the CSM each one belongs to. - **Reads milestones and product events in Postgres:** read-only, to see what each account has and has not done since it signed. - **Saves one note back to HubSpot:** the milestone a nudge was last drafted for, and nothing else. No plan, no seat count, no other account setting. ### Alert in Slack, draft in email Each channel does one job. In **Slack**, the owning CSM gets a message with the account's progress and the exact step that is stuck. In **email**, the nudge to the customer waits as a draft for the CSM to open, tweak and send. ### Draw the lines The agent follows progress and writes drafts. It never alters the account and never talks to the customer directly. Sending the nudge is out of its reach, and so is any plan, seat, billing setting or other account detail. Credentials are stored encrypted in the **Secrets Manager** and only handed to the agents you grant them to, at the moment a run starts. ### Pass it to the CSM Once it is running, the CSM opens Slack to a concrete reason one account needs help today, not a vague "check on your accounts" ping. Their inbox already holds a nudge written around the precise step the customer missed. They read it, judge whether it fits, and send it themselves. > **The pattern** > A daily **cron** creates a session with read connectors into Postgres and > HubSpot. The milestones are kept in a **skill**. The agent spots the stall, > writes the nudge and pings the CSM, and the CSM reads it, adjusts it and sends > it. ## Guardrails Brand-new paying accounts are precious, so the agent's reach is small and spelled out: - **Draft and alert only.** Sending the nudge is never the agent's job, and it never reaches out to the customer itself. The email stays a draft in the CSM's inbox until the CSM sends it. - **No account changes, ever.** Plans, seat counts, billing settings and every other account detail are off limits, in HubSpot and everywhere else. The agent reports and drafts. It does not manage accounts. - **Scoped writes.** Its one write to HubSpot records the milestone a nudge was last drafted for. The deal stage, the owner and every field a CSM depends on are left alone. - **Isolation.** Each run lives in a sandbox of its own. Credentials for Postgres and HubSpot are stored encrypted in the Secrets Manager and only handed to the agents you grant them to, injected when the run starts. - **Everything is code.** The milestones, the stall cut-offs and each system's permissions are files in the repo. They keep a version history and change through a reviewed **change request**, not a setting in a dashboard. ## The outcome - **Every day:** Each new account checked again against fresh milestone data - **0 sent:** Emails sent or settings changed without a person - **5 milestones:** Followed from the first login through to full activation A stalled onboarding used to surface only when a CSM happened to glance at the account. Now it shows up the day it begins, along with the step that was missed and a nudge ready to go. The agent keeps watch over every new account and does the spotting. The CSM still decides what goes out, and when.