Ask ten people how to automate revenue operations and you'll get ten lists of workflows. Lead routing, quote-to-cash, health scoring, renewal alerts, invoice generation. The lists are mostly the same and mostly correct, and they're not the useful part.
The useful part is the order, because RevOps workflows sit on top of each other. Build the wrong one first and you'll rebuild it in six months when the thing underneath it changes. We've done that rebuild for enough clients to have a strong opinion about the sequence.
The principle: automate the handoff before the report
Every RevOps process has two kinds of steps. There are steps where work moves between people or systems, and there are steps where someone looks at what happened and decides something.
Automate the movement first. Always.
The reason is that a report is a function of the data underneath it, and the handoff is where that data gets created. If a rep manually creates the project record after a deal closes, then project start dates are whenever somebody got around to it, and any cycle-time report built on that field is measuring administrative diligence rather than delivery speed. Automate the handoff and the timestamp becomes real. Now the report means something, and you didn't have to build the report twice.
This is why teams that start with dashboards so often end up disappointed. The dashboard works. It's just describing a process nobody instrumented.
The readiness test
Before building any workflow, it has to pass three checks. We run these in scoping and they kill maybe a third of requested builds, which saves everyone money.
Does a trigger exist? Something in a system has to change. A stage moves, a field is set, a payment posts, a form submits. If the real-world trigger is "the account manager decides the client is ready," there is no trigger, and the first build is whatever makes that decision visible in a system.
Is there one right answer? If two people would produce different outputs from the same input, you have a definitions problem wearing a workflow costume. Automating it just makes one person's interpretation official without anyone agreeing to it.
Does it happen enough? Under about twice a month, a build rarely pays back before something changes and invalidates it. There are exceptions where the stakes carry it, like a compliance gate that runs quarterly, but volume is the default test.
The build order
1. The closed-won cascade
The moment a deal closes, several systems need to know. Project created, folder provisioned with the right permissions, kickoff scheduled, first invoice raised, finance notified, records written back to the CRM.
This goes first for a reason that isn't obvious: it's the single point where sales data becomes delivery data and finance data. Automate it and three departments start sharing a timestamp and an amount. Leave it manual and every downstream report inherits the transcription errors. We've written up the full quote-to-cash version, and the case study has the actual node structure from a 60-person firm.
2. Invoice generation and payment write-back
Second because it closes the loop the first one opened, and because it touches money, which makes it the fastest thing on the list to justify.
The build is straightforward: a milestone or stage change produces a draft invoice with correct line items, a human approves it, it sends, and payment status writes back to the deal record. Keep the human approval. The failure mode with automated invoicing isn't a wrong number. It's a wrong number sent confidently to a client, and the fix costs a phone call plus some credibility. The Salesforce and Stripe version covers the field mapping in detail.
3. Data quality monitoring
Third, and this is the one everyone wants to skip.
A nightly job that counts duplicates, blank required fields, records stuck past a threshold, and validation failures, then posts the counts to a channel where an owner sees them. It builds nothing visible. It's also the thing that stops steps one and two from silently degrading, because both of them read fields that humans can edit.
Skip it and here's what happens, usually around month four: someone changes a picklist value, the cascade stops firing for one deal type, nobody notices for three weeks, and the trust you built with steps one and two is gone in an afternoon. The data quality playbook has the specific checks worth running.
4. Routing and assignment
Lead routing, account assignment, ticket triage. Fourth because it's high visibility and moderate value, and because it depends on territory and ownership definitions being settled, which they often aren't.
The build is easy. The prerequisite is not. If your routing rules encode a territory model that two sales leaders disagree about, the automation makes the disagreement fire fifty times a day instead of once a quarter. Settle the model, write it down, then build. Lead routing in Salesforce covers the mechanics once the model exists.
5. Reporting and distribution
Now build the dashboards, because now the fields underneath them are populated by systems rather than by intentions.
The part teams underinvest in is distribution. A dashboard nobody opens is worth nothing, and getting people to open dashboards is a losing battle. Push instead: a Monday morning digest in Slack with last week's numbers and the delta, an alert when forecast and actual diverge past a threshold, a monthly job that assembles the board pack data. The architecture is here.
6. Retention and expansion motions
Renewal alerts at 120, 90, 60, and 30 days with usage and health context. Health score decay warnings. NPS at lifecycle milestones with detractors escalated.
Last, not because it's least valuable, but because health scores are only as good as the usage and support data feeding them, and most companies don't have that plumbed until the earlier steps are running. A churn score built on incomplete data is worse than none, because CSMs will act on it.
What forces a rebuild
Three things, in our experience.
Building on a field humans edit freely. If the trigger field can be changed by anyone with a mouse, the workflow will fire on someone's typo eventually. Either lock the field or trigger on something derived.
No error handling. A workflow that fails silently is worse than no workflow, because the team stopped doing the manual version months ago and nobody is checking. Every build should alert a person on failure, and the alert should say what failed and for which record.
Encoding a process that was about to change. If a workflow's logic depends on the current org chart, the current pricing model, or the current tool, ask how confident you are in each of those over eighteen months. Build the parts that are stable, and leave the volatile parts as a configuration table rather than logic buried in nodes.
Where to start on Monday
Take the audit questions or just do question five: sit with someone in sales ops and someone in finance for twenty minutes each and write down every place they read a value off one screen and type it into another.
Then find the one where the same value gets typed in both conversations. That's your first build, and it isn't a coincidence. A fact that two departments transcribe independently is a fact those departments will eventually disagree about, and the automation is worth more for ending the disagreement than for saving the four minutes.
The RevOps and data catalogue lists these builds with hour bands and price ranges if you want to size one before committing. Or send us the two transcription points you found, and we'll tell you which of them is actually one problem. Thirty minutes settles that faster than a scoping document.