Workflow automation for RevOps: one number, four answers

Somebody asks how many customers you have and four systems give four answers. None of them is broken. The CRM counts accounts, the billing system counts paying entities, the product counts workspaces, and the finance model counts something else again — and every one of those definitions is correct for the purpose it was built for.

RevOps exists largely to resolve that, and the common mistake is to resolve it by syncing: making the systems agree by copying values between them. That makes the disagreement permanent rather than settling it, because the definitions were never reconciled and now they are entangled.

What we'll cover

• Four systems, four correct answers
• Definitions before pipelines
• Deciding the order of authority
• Building it with CodeWords
• Why syncing makes it worse
• The handoffs between teams
• Hygiene that actually holds
• Reporting people will trust
• Being the team everybody asks
• Making it survive
• Limits worth knowing about
• What to build first
• Frequently asked questions

Four systems, four correct answers

Each system counts what it needs to count for its own job.

A customer might be an account, a billing entity, a workspace, a contract, or a logo, and those differ in every business of any size.

The differences are structural, not errors: one company with three subsidiaries on two contracts using four workspaces is a real situation.

Nobody is wrong, which is why the argument never resolves by checking who made a mistake.

The number quoted depends on who is asked, which is a credibility problem long before it is a data problem.

The fix is a definition, agreed and written down, and then a single place that computes it.

Definitions before pipelines

Write the definition down — what counts, what does not, and at what moment.

Name the edge cases explicitly: trials, free accounts, churned-and-returned, subsidiaries, internal accounts, partners.

Agree the timing. A customer counted at signature, at first payment or at first use produces three different curves from one reality.

Get sign-off from the people who will quote it, which is finance, sales leadership and the board pack author.

Version the definition and date it, so a change in the number can be attributed to a change in the rule rather than the business.

Publish it beside every number that uses it, permanently.

Deciding the order of authority

One system owns each field, and everything else reads it.

Billing usually owns money, the CRM owns the relationship, the product owns usage, and the finance system owns what is reported externally.

Write the map down, field by field, since this is the artefact that prevents most future arguments.

Downstream systems display, not store, wherever possible, so there is nothing to diverge.

Where a copy is unavoidable, make the direction explicit and one-way.

Review it when you add a system, because every new tool wants to own something and defaults to owning it.

Building it with CodeWords

CodeWords connects to more than 3,000 integrations, and the connection is made once and reused.

1. Open CodeWords and start a new automation.
2. Describe what should happen in plain language to Cody, the automation builder: which system is authoritative for what, how records are matched, and what is reported when they disagree.
3. Authorize the connections — the CRM, the billing system, the product analytics and the warehouse.
4. Describe the exceptions: an unmatched account, a subsidiary structure, a trial, a manual override.
5. Run it over last quarter and compare the computed numbers against what was reported at the time.

You describe the outcome; Cody builds it, connects it, and deploys it. 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.

Why syncing makes it worse

A sync makes systems match without agreeing on what the value means.

Conflicts have no natural resolution, so somebody's rule wins silently.

Loops form when two systems update each other.

The copy diverges anyway, on the records where matching failed, which are the interesting ones.

Debugging becomes archaeology, because the value in front of you came from somewhere else and possibly several steps ago.

Compute in one place instead. A warehouse or a single authoritative service producing the number, with everything else reading it, is both simpler and arguable.

The handoffs between teams

Marketing to sales, where the definition of a qualified lead is the classic unsettled argument.

Sales development to account executive, where context is lost and the customer repeats themselves.

Sales to customer success, where what was promised during the sale is frequently not written anywhere.

Success to renewal, where the account's history determines the conversation and is scattered.

Automate the context transfer, not the decision, so the receiving person has what they need rather than a notification that something moved.

Measure each handoff: how long it takes and how often it goes back, which is where the pipeline actually leaks.

Hygiene that actually holds

Validate at entry, since fixing data afterwards is a permanent programme and preventing it is a one-off change.

Deduplicate continuously, not in quarterly clean-ups that are undone within a month.

Derive rather than ask. Any field a person must remember to fill will be wrong; a field computed from activity will not.

Report data quality as a number, by team, which makes it visible without making it personal.

Delete fields nobody uses, which most CRMs accumulate in the hundreds and which make every form worse.

Fix the cause. A field that is always wrong is a process problem, and cleaning it monthly is treating the symptom forever.

Reporting people will trust

One source, many views, rather than each team building its own version.

Show the definition on every report, every time.

Reconcile to the externally reported figure, and explain the difference rather than hiding it.

Report the changes to definitions as prominently as the numbers, since an unexplained step change destroys confidence in everything.

Make the underlying query visible so somebody can check it, which is what makes a number defensible.

Do not rebuild history silently. Restating last quarter without saying so is the fastest way to lose a board's confidence.

Being the team everybody asks

RevOps absorbs requests from every function, and most of them arrive as a solution rather than a problem. How that queue is handled determines whether the team builds anything or spends the quarter answering questions.

Ask what decision the request supports, since a surprising proportion of report requests dissolve once the underlying question is stated.

Publish the self-service answers for the questions that recur, which is most of them.

Batch the small changes into a regular release rather than handling each as an interruption.

Say no to one-off fields. Every bespoke field added for one campaign is permanent, and the CRM's field count is the accumulated history of those yeses.

Keep a visible queue so requesters can see where theirs sits rather than asking.

Reserve capacity for the foundational work, or it never happens — the definitions, the matching, the hygiene, all of which are invisible until they fail.

Making it survive

Make matching deterministic and logged, since account matching is where most of these systems go wrong.

Handle the unmatched record as a visible queue rather than dropping it.

Version every definition change and keep the history.

Alert on reconciliation drift between systems rather than discovering it in a meeting.

Report the outcome: records processed, matched, unmatched, and the variance between systems on the key numbers.

Limits worth knowing about

System APIs limit what can be read and how quickly, which constrains freshness.

Historical restatement is expensive, and sometimes impossible where a system does not retain what it held.

Account hierarchies are genuinely hard and no tool handles every real corporate structure cleanly.

Attribution is loose, and no amount of pipeline work makes marketing attribution precise.

Definitions are political. Agreement is an organisational outcome that tooling supports rather than produces.

What to build first

The definitions document: the five or six numbers your company quotes, what each includes and excludes, at what moment they count, and which system is authoritative. It is not automation and it is the prerequisite for all of it, and producing it usually surfaces at least one disagreement that has been quietly costing time for a year.

Two habits make the difference. Compute each number in one place and have everything else read it, rather than syncing values between systems that never agreed what they meant. And publish the definition beside every number, because almost every dispute about revenue reporting turns out to be two people correctly computing different things.

Frequently asked questions

Why do four systems give four customer counts?

Because each counts what it needs for its own job — accounts, billing entities, workspaces, contracts. None is wrong, which is why the argument never resolves by looking for a mistake.

What comes before building any pipeline?

The definition: what counts, what does not, at what moment, with the edge cases named — trials, free accounts, subsidiaries, churned-and-returned — and sign-off from everybody who will quote the number.

Why is syncing systems a bad answer?

It makes them match without agreeing what the value means. Conflicts resolve silently, loops form, copies diverge on exactly the records where matching failed, and debugging becomes archaeology.

What should be done instead?

Compute in one place — a warehouse or a single authoritative service — and have everything else read it. One system owns each field, written down field by field, with downstream systems displaying rather than storing.

How do I make CRM hygiene stick?

Validate at entry rather than cleaning afterwards, deduplicate continuously rather than in quarterly efforts, and derive fields from activity rather than asking people to fill them. Any field requiring somebody to remember will be wrong.

Where does the pipeline actually leak?

At the handoffs — marketing to sales, development to account executive, sales to success, success to renewal. Automate the context transfer rather than the decision, and measure how long each handoff takes and how often it goes back.

How should a definition change be reported?

As prominently as the number. An unexplained step change destroys confidence in every other figure, and version history is what lets you attribute a movement to a rule change rather than the business.

Can tooling settle a definition disagreement?

No. Agreement is an organisational outcome. Tooling makes the disagreement visible and enforces the decision once it is made, which is valuable and is not the same thing.

How should RevOps handle the request queue?

Ask what decision each request supports — many dissolve once the question is stated — publish self-service answers for recurring ones, batch small changes into a release, and keep a visible queue so nobody has to chase.

Why refuse one-off CRM fields?

Because they are permanent. A CRM's field count is the accumulated history of one-off yeses, and every one of them makes forms longer and reports harder.

Related reading

• Automating sales pipeline updates
• Automating lead scoring
• Connecting Stripe to Google Sheets