Most post-sales automation fails for one of two reasons. Either it fires on a signal without understanding the account, so customers get generic messages at the wrong moment, or it produces so many alerts that the team learns to ignore them. Both problems come from skipping a step in how the workflow is designed.
A reliable way to avoid this is to build every post-sales workflow from the same three parts: a trigger that starts it, account context that informs it and an action that ends it. Quivly's Workflow Automation page describes the pattern simply: a signal comes in, Quivly looks up the account, pulls health, calls and tickets and drafts the next step, and the team sends what needs a person.
This guide walks through each part of that structure, shows a worked example and covers how to decide which steps run on their own and which wait for review.
The Three-Part Anatomy of a Post-Sales Workflow
Think of a workflow as a small graph rather than a single rule. Quivly describes it as the graph that runs a motion: the trigger, then the tools, then the action. Each part answers a different question:
- Trigger: when should this run? A health move, a usage stall, a renewal window or someone running it by hand.
- Account context: what do we need to know? The customer record, health score, recent calls and support tickets.
- Action: what should happen next? An email, a Slack note, a QBR or an alert, which someone reviews or an agent sends.
The middle step is the one teams most often skip, and it is what separates a useful workflow from a noisy one. A trigger tells you something happened. Context tells you whether it matters for this account and what the right response is.
Step 1: Choose Triggers That Mean Something
A trigger should map to a moment where a timely response changes the outcome. Quivly lists four kinds of trigger, and they cover most post-sales needs:
- Health moves. An account's health score drops or rises past a threshold.
- Usage stalls. Activity on a core feature slows or stops.
- Renewal windows. A contract enters the period where preparation should begin.
- Manual runs. A person starts the workflow on demand, for example to prepare for a meeting.
When choosing triggers, ask three questions. Is the signal reliable enough that it rarely fires by mistake? Is there a clear response the team would want every time? And does the timing leave room to act? A renewal workflow that starts a week before the renewal date is too late to change anything. If you want a broader look at which customer events deserve an alert, our guide to automated alerts for customer events covers the options.
Step 2: Pull the Account Context Before Acting
Once a workflow is triggered, it should gather what a good CSM would check before responding. In Quivly, a workflow reads the customer record, health score, recent calls and support tickets, and the draft it produces cites those sources.
Citations matter more than they might seem. A drafted email or summary that points to the call, ticket or metric it is based on is easy to verify. A draft with no sources forces the reviewer to redo the research, which removes most of the time saved.
Useful context sources for most post-sales workflows include:
- Account record: plan, contract dates, owner and key contacts.
- Health score: the current score and what is driving it.
- Calls: recent conversations, commitments and concerns raised.
- Support tickets: open issues, severity and how long they have been open.
- Usage: adoption of key features and recent trends.
Having this data in one place makes the step far easier to build. A single Customer 360 view means a workflow can read one profile instead of stitching together several systems at run time.
Step 3: End Every Workflow in a Clear Action
A workflow that ends in a dashboard update has not really finished. Quivly's rule is that every workflow ends in a task: an email, a Slack note, a QBR or an alert. The output should be something a person can act on immediately or that an agent can complete.
When designing the action, be specific about four things:
- Format. Is the output a customer email, an internal Slack message, a document or a task?
- Owner. Who receives it, and does that change by segment or account tier?
- Content. What should the draft include, and which sources should it cite?
- Delivery. Does it wait for review, or can it be sent automatically?
In Quivly, tasks that need a person land in the Actions Feed. Quivly describes the relationship clearly: the Actions Feed is the queue a person works, and workflow automation is what fills that queue when a signal lands.
A Worked Example: QBR Preparation
Quivly's page shows a QBR preparation workflow that makes the three-part structure concrete. It runs in this order:
- Trigger: a manual trigger, started by the CSM ahead of the review.
- Get customer details: look up the account record by ID.
- Get health score: pull the current score and its drivers.
- Search recent calls: find recent conversations and what was discussed.
- Search support tickets: check open and recent issues.
- Get AI insights: summarise and connect the findings.
- Action: generate a QBR document that creates a cited review from live CRM, usage and call data.
The same shape works for many other motions. Swap the manual trigger for a usage stall and the QBR for a check-in email, and you have a re-engagement workflow. Swap it for a renewal window and an executive summary, and you have renewal preparation.
Decide What Runs Automatically and What Waits for Review
Automation does not have to mean messages sending on their own. In Quivly, messages only send automatically when that step is handed to an AI Agent; everything else waits in review. That gives teams a simple way to stage their rollout:
- Start with review. Let workflows draft, and have people approve every output.
- Track edits. Note which drafts go out unchanged and which need rework.
- Hand over the trusted steps. Move low-stakes, consistently accurate outputs, such as internal Slack notes or routine reminders, to an agent.
- Keep high stakes human. Executive outreach and commercial conversations should stay with a person.
Workflows, Plays and Agents: How They Fit Together
These terms often get blurred, so it helps to separate them. Quivly defines a play as the named motion, such as rescue, expansion, onboarding or renewal. Workflow automation is the graph that runs it. Agents go a step further by reasoning about each customer's state and adapting when things change. In practice, a team defines its plays, builds workflows for the repeatable steps and assigns agents to the steps they trust them with. For a step-by-step build process, see our guide on how to automate post-sales workflows in six steps.
Want every customer signal to end in a clear, cited next step? See how Quivly Workflow Automation turns triggers into tasks your team can review or hand to an agent.
FAQ
A trigger that starts it, such as a health move or renewal window; account context it reads, such as the customer record, health score, calls and tickets; and an action it ends in, such as an email, Slack note, QBR or alert.
Not by default. In Quivly, a message only sends on its own when that step is handed to an AI agent. Everything else waits for a person to review.
A play is the named motion, such as onboarding, rescue, expansion or renewal. Workflow automation is the graph that runs it, from trigger to tools to action.
Citations let reviewers check a draft against the calls, tickets and metrics it is based on, so they can approve it quickly instead of redoing the research themselves.
