Automation for SaaS companies: the product-shaped processes
Trials, onboarding, usage signals, failed payments and churn risk are the processes SaaS lives on. Which to automate, and where product usage data changes what is possible.
On this page
- What we'll cover
- Behaviour beats the calendar
- The trial, and what actually predicts conversion
- Onboarding that responds to what happened
- Failed payments, the cheapest revenue available
- Churn signals worth acting on
- Keeping support and product connected
- The five events worth instrumenting first
- Frequently asked questions
- Related reading
A SaaS company has one advantage nobody else has when it comes to automation: it can see what its customers are actually doing. Not what they said in a call, not whether they opened an email, but whether they have used the feature they signed up for.
That changes which processes are worth building. The valuable automations in SaaS are the ones driven by product behaviour rather than by calendar dates, and most companies run the calendar-driven versions for years before switching.
What we'll cover
Behaviour beats the calendar
The distinction that separates SaaS automation that works from the version most companies run.
Calendar-driven: day three of the trial, send email two. Day seven, send email three. Day twelve, send the ending-soon warning. Everybody gets the same sequence regardless of what they did.
Behaviour-driven: somebody who completed setup and invited two colleagues gets a different message from somebody who signed up and never returned. The first needs a nudge toward the next capability; the second needs to be asked what stopped them.
The second is obviously better and most companies run the first, because the first needs only a signup date and the second needs product events reaching the systems that send messages.
Getting events out of the product is the enabling step for everything below. Not every event — a handful that genuinely indicate progress. Account created, first core action completed, second user invited, integration connected, first real data imported. Those five tell you more about a customer's trajectory than any amount of email engagement.
The common mistake is instrumenting everything and drowning, rather than instrumenting the five things that indicate someone is getting value. Start narrow.
The trial, and what actually predicts conversion
Find your activation moment first. Look at customers who converted and customers who did not, and find the action that separates them. It is usually specific and often unglamorous: importing real data, inviting a second person, connecting an integration, completing one genuine piece of work.
That single action is worth more than every other trial metric, because it turns a vague funnel into a binary question with an obvious intervention: did they do the thing, and if not, why not.
Then automate around it.
Somebody who activated should be moved toward the next thing and toward a conversation about paying. They are not at risk; they are an opportunity being under-served.
Somebody who has not activated by day two or three is the group worth intervening on, and a templated nudge is the weakest available intervention. Better: a genuine question from a person, or a message that names the specific thing they have not done.
Somebody who never returned after signup rarely converts on a fifth email. The honest automation here is one well-timed question asking what they were hoping to do, which occasionally produces a customer and reliably produces product insight.
Trial ending should reflect all of this rather than being one message to everyone. Somebody who activated and used the product daily gets a different note from somebody who logged in once.
Onboarding that responds to what happened
Post-purchase onboarding is where churn is decided, and it is usually run as a fixed sequence.
Provision everything immediately. Accounts, access, whatever setup you can do without them. The gap between paying and being able to start is the most damaging period in the relationship.
Sequence around progress, not days. The next step arrives when the previous one is complete rather than on a schedule, because a customer who has not finished step one does not need step two.
Escalate stalls to a person. A new customer who has not completed setup after a week is not an email problem. Getting that in front of whoever owns the account, with what they have and have not done, is the automation worth building.
Tell the internal team. When a new customer completes setup, or does not, the people responsible should know without checking a dashboard.
Ask at the right moment. A question about how onboarding went, sent automatically when it completes, while it is fresh. This is the only reliable source of improvement and it is always the step that gets dropped.
Failed payments, the cheapest revenue available
Involuntary churn — customers who intended to keep paying and whose card failed — is the most recoverable revenue in any subscription business and the most neglected.
Retry on a schedule that reflects why cards fail. Insufficient funds resolve on payday; expired cards do not resolve at all without the customer acting. A single retry the next day, then giving up, leaves money on the table.
Tell the customer in a way they will act on. An email that looks like a receipt gets ignored. One that says clearly what happened, what will stop working and when, with one link to fix it, gets acted on.
Escalate before the account is suspended, particularly for anything above a threshold. Suspending a customer who would happily have updated their card is an expensive way to save a phone call.
Notify someone internally for accounts above a value. A failed payment on a significant account should reach a person the same day.
Measure the recovery rate. Most companies do not know theirs, and it is usually improvable by a double-digit percentage with better timing and better copy alone.
The whole flow is triggers, conditions, messages and escalation — straightforward to describe and tedious to assemble. On CodeWords you describe it in plain language, including what should happen for a large account versus a small one, and Cody, the automation builder, builds it, connects it to your billing and messaging tools, and deploys it. Automations connect to more than 3,000 integrations. The free plan covers light use, with Pro at $39 per month and Business at $100 per month as usage grows; details are on the pricing page.
Churn signals worth acting on
Usage data makes early warning possible, and it also makes false alarms easy.
Signals that mean something: usage declining against that account's own baseline rather than against an average, the champion's login stopping while others continue, a support conversation that went badly, an integration disconnecting, seat count falling.
Signals that mean less than people think: a single quiet week, absolute usage compared across different customers, and email engagement, which measures whether somebody reads email rather than whether they value the product.
Compare each account to itself. An account that has always used the product twice a week is not at risk for doing that again. One that used it daily and now does not, is.
Route to a person rather than to a campaign. An at-risk account is a conversation. An automated win-back email to a customer considering leaving generally confirms their impression that nobody noticed.
Log the outcome. Which accounts were flagged, what was done, what happened. Without that, nobody can tell whether the signal is predictive or whether the team is chasing noise, and after two quarters the alerts get ignored.
Keeping support and product connected
The information that exists in support and never reaches the people who could act on it.
Tag conversations by theme and report the trend, so a rising pattern is visible before it becomes a recurring complaint in a board meeting.
Route by account value and health as well as by topic, so a struggling large customer does not wait behind routine questions.
Give support the context automatically. Plan, usage, tenure, open issues, recent activity, attached to the conversation. It shortens every interaction and it is a straightforward automation.
Close the loop when something ships. The customers who reported a problem should hear when it is fixed. Almost nobody does this, and it is disproportionately effective.
The five events worth instrumenting first
Rather than a taxonomy, the specific short list that unlocks everything above.
Account created, with source. The baseline for everything, and the one most companies already have.
First core action completed. Whatever your product fundamentally does, done once for real. Not a tour step or a sample — the genuine thing with their own data. This is usually the strongest single predictor of conversion.
Second user invited. Multi-user adoption is the most reliable retention signal in most business software, because a product one person uses is a product one person can stop using.
Integration connected or data imported. The moment a customer puts their own work into your product, switching becomes expensive for them. Accounts that cross this line churn at a fraction of the rate.
Recurring use established, defined however suits your product — three sessions in a week, use in two consecutive weeks. This distinguishes trying from adopting.
Five events, sent to wherever your messaging and CRM live. Every automation on this page is built on some combination of them, and a company with these five instrumented is in a better position than one with two hundred events nobody queries.
Frequently asked questions
What should a SaaS company automate first?
Failed payment recovery. It is contained, the revenue is real and recoverable, and most companies discover their recovery rate is worse than they assumed. After that, trial activation, once you know which action predicts conversion.
How do we get product events into our other tools?
A small set of meaningful events sent to wherever your messaging and CRM live, either directly from the product or via whatever analytics tool you already run. Start with five events that indicate progress rather than instrumenting everything, because the broad version produces noise nobody uses.
What is an activation metric?
The specific action that separates customers who convert from those who do not. It is different for every product and worth finding empirically by comparing the two groups. Once you have it, your trial automation has an obvious target rather than a vague funnel.
Should trial emails be time-based or behaviour-based?
Behaviour-based, with time as a fallback. Somebody who has completed setup and somebody who never returned should not receive the same message on day five, and sending it anyway is the most common reason trial sequences underperform.
How do we avoid annoying customers with automated messages?
Send fewer, triggered by something real, and stop when they act. The messages people resent are the ones that clearly ignore what they have already done, particularly a nudge to complete something they finished last week.
Can automation prevent churn?
It can surface risk early, which is genuinely valuable, and the intervention still has to be a person for anything above a small account. Automating the detection and the routing works; automating the save attempt usually does not.
What about product-led growth motions specifically?
The same behavioural principles apply and the volume is higher, so the automation has to carry more of the load. The practical approach is automating everything up to the point where an account crosses a value threshold, and routing to a person from there.
How do we know whether any of this is working?
Pick the metric each automation was meant to move and watch that rather than the automation's own volume, and write the target down before you build so the comparison afterwards is honest. Failed payment recovery has a recovery rate. Trial automation has an activation rate. Onboarding has a time-to-first-value figure you can track per cohort. If a workflow cannot be tied to a number that should change, it is worth asking what it was for, because a count of automations built is not a measure of anything except activity.