Revenue operations, rebuilt by hand · B2B companies of 20–200

You already have a RevOps person.
It’s whoever fixes the automations when they break.

Nobody hired them for it. It isn’t in their title. They’re just the one who remembers why the routing works, which account the invoice sits under, and what the person who left three months ago wired into that zap. We take that job off a person and rebuild it as workflows that run inside the CRM, the ticketing system and the chat your team already uses — data hygiene, lead routing, attribution, pipeline reporting, and the automations underneath.

Nothing migrates. Your team learns no new tool. Clients pay from month one — we don’t run free pilots.

Five systems — CRM, ticketing, chat, the automation layer and a spreadsheet — all routing into one person: the operation rests on a person, not on a system, and that person is the single point of failure. CRM TICKETING CHAT AUTOMATION LAYER SPREADSHEET ONE PERSON
  • What you get named workflows, each with a failure alarm and a test attached.
  • Where it runs in your accounts, inside the tools your team already has open.
  • What stays yours the architecture, the code, the evals, the decisions log.

The state of things

Nothing is broken enough to fix. Everything is broken enough to hurt.

Companies your size don’t decide to build a go-to-market stack. They accumulate one — a CRM, a form, a few dozen automations, a chat channel where things get escalated, each added by someone solving a real problem on a real Tuesday. None of it was designed. All of it is load-bearing.

Then the person who built the automations leaves, and the automations stay. A field gets renamed and a workflow fails silently. Sales stops filling in the one property attribution depends on, so the pipeline number in the deck and the pipeline number in the CRM stop agreeing and nobody can say which one is wrong. Everything technical routes to the one person who can read a zap — usually the person who was hired to do something else entirely.

That person is not short on skill. They’re short on a mandate. Keeping the things that already exist from falling over eats the hours that were supposed to go into growth. And it never rises to the level of an emergency, so it never gets fixed. It just quietly sets the ceiling on how fast you can sell.

One customer held in three systems — marketing, sales and the CRM — where the same rows hold different values and one system is missing a field outright: the versions disagree, so reconciling the numbers is a data-model problem, not an argument. THE SAME CUSTOMER MARKETING SALES CRM
Rows are the same fields in all three systems. The gold outline is a field one of them does not have.
  • The stack has no map. Nobody can say what runs, what it touches, or whose personal account it’s registered to.
  • Fixes have one address. Every broken thing routes to the same person, whatever their actual job is.
  • Failures are silent. You find out an automation stopped when a customer tells you.
  • The numbers disagree. Marketing, sales and the CRM each have a version, and reconciling them is somebody’s manual afternoon.

The argument, part one

Two numbers explain why this never gets fixed properly.

Roughly 300,000 B2B companies between 20 and 200 people in the US and EU run a live go-to-market stack — a CRM with real deals in it, automations wired between tools, someone sending sequences. That’s our estimate, built from the public install base of the major CRMs and business-count data from the US Census and Eurostat.

In a year, that same market makes on the order of 6,000 dedicated RevOps hires.

Hold those two next to each other. The work exists in three hundred thousand companies. The role exists in a few thousand. Everywhere else the work doesn’t disappear — it gets handed to whoever is standing closest. Usually one person in marketing or ops who is good with tools and can’t say no. That’s not a hiring gap. That’s a market where almost nobody’s demand is shaped like a job posting.

The demand for the work is two orders of magnitude larger than the demand for the job title.

Two areas in true proportion: roughly 300,000 B2B companies running a live go-to-market stack, against on the order of 6,000 dedicated RevOps hires a year. Both figures are estimates. The demand for the work is far larger than the demand for the job title. 300,000 COMPANIES ON A LIVE GTM STACK 6,000 REVOPS HIRES A YEAR
Areas drawn in proportion. Both figures are estimates, built from public sources.

The argument, part two

The old answer could only ever reach about a tenth of the work.

Rule-based automation — the zaps, the workflows, the if-this-then-that layer every company of this size has — takes something like ten percent of what a revenue person actually does. Not because the tools are bad. Because everything above that line needs a judgment call: is this lead real, is this ticket a bug or an upsell, does this account belong to the same company under a different spelling.

So the ten percent gets automated and the ninety percent stays with people. And then the ten percent quietly becomes its own job. Someone has to watch it. A field arrives in the wrong format and the automation silently stops. The person who built it leaves and the automation stays, doing something nobody can explain. The stack grows another animal, and the only map of it lives in one person’s head.

One column of what a revenue person does: rule-based automation reaches about ten percent of it at the bottom, while an estimated sixty to eighty percent is reachable with AI in the loop. What changed is the reachable share, not the tooling. WHAT A REVENUE PERSON DOES RULE-BASED ~10% WITH AI IN THE LOOP 60–80% (ESTIMATE)

What changed is the ceiling, not the tooling. With AI in the loop, our estimate is that somewhere between sixty and eighty percent of that work is now reachable — two to three times the old line. Treat that as our read on where the technology is, not as a measured result from a client engagement.

And none of that reach lands on routing that misfires, data nobody trusts, or an attribution model three systems disagree about. Agents amplify the operation you actually have. On a clean one that’s leverage. On yours it’s faster mess.

At ten percent, you buy tools. At sixty, you rebuild the operation. That’s the whole difference, and it’s why the answer to this stopped being “add another integration.”

How this gets bought

It’s a role you’re filling, not a seat in someone’s software.

Every founder we talk to has already priced the obvious version of this: hire a RevOps person. Loaded cost sits around $120K a year, and the search runs six months or more before anyone good says yes — for work that arrives in bursts. Most companies look at that, decide it isn’t this quarter’s problem, and hand the work back to the person who’s been absorbing it all along.

We’re the other option in that comparison. Not a subscription your team has to adopt, and not a dev shop that builds what you spec — a small senior team that takes the operation apart inside your own systems and puts it back together as workflows. You’re comparing us to a hire, which is the right comparison, because that’s the shape of the thing being replaced.

What a hire gives you

One person’s throughput. One person’s memory. Six months to find, longer to ramp, and the whole thing walks out the door if they leave.

What we give you

Written architecture, codified workflows, tests and monitoring — all of it in your accounts. Two senior operators working inside your stack, and everything they build stays after they stop.

We don’t publish prices. Scope and cost are written down before anything is touched, and you’ll get real numbers on the first call — on the call, not in a proposal two weeks later.

The unit of delivery

We ship live workflows. You can count them, and each one comes with its own test.

A live workflow is one named piece of your operation, written down as explicit steps, moved off a person and onto an engine: a trigger, the steps in between, a place it writes to, and a human checkpoint wherever the call is genuinely a judgment call. It runs in your accounts, on your data, inside the tools your team already has open.

The second half is the part this category usually skips. Every workflow ships with an eval — a set of cases with known right answers that we run against it — and a failure alarm. Named, so you can point at it. Written, so it survives whoever built it. Alarmed, so when it breaks your team hears it before your customer does. Evaluated, so you find out it’s drifting without a customer having to tell you. Anyone can demo a workflow. The eval is what makes it maintainable after we leave.

That’s the unit. Not “AI transformation,” not a platform, not a number of hours. When a cycle ends you can list what now runs without a person in it, and what still doesn’t.

One workflow drawn as a single object: a trigger, the steps in between, a place it writes to and a human checkpoint, with a failure alarm branching off it and an eval running against the whole of it. The unit of delivery is countable and inspectable, and the eval keeps checking it after we leave. TRIGGER STEPS WRITES TO HUMAN CHECKPOINT FAILURE ALARM EVAL
  • Inbound from every channel normalized, matched to the right company, and classified before anyone opens a queue.
  • Automation failures collected, grouped by cause, and posted to the team’s chat with the fix attached, not just the alarm.
  • Enrichment and routing that keep the fields attribution depends on filled without asking a rep to remember.

What we build

Five zones. One operation.

These are the functions a RevOps hire would own. We build them as working systems inside your tools — not as a deck describing how they should work.

Data hygiene — the part everything else stands on

  • One source of truth for accounts and contacts, with deduplication running continuously instead of as somebody’s quarterly cleanup.
  • Formats enforced where automations depend on them, so a renamed field stops being an outage.
  • Records matched across the systems that currently disagree about the same customer, so “what do we know about this account” is a query rather than an excavation.

Lead routing — the right thing lands on the right person

  • Deterministic rules first: the obvious majority classified instantly and cheaply.
  • AI for the ambiguous middle, with a human checkpoint on anything irreversible.
  • Routing that survives someone leaving, because it lives in a documented workflow rather than in a colleague’s memory.

Attribution — one number, not three

  • The fields the model depends on populated by the system instead of by discipline.
  • A single definition of a stage and a source, written down and enforced in the pipeline.
  • Revenue traced back to what actually produced it, from closed deals rather than from MQL counts — and traceable, so your team can argue with it.

Pipeline reporting and the automations underneath

  • The numbers leadership argues about assembled from the source systems on a schedule, not hand-built in a spreadsheet the night before.
  • Fragile point-to-point automations migrated, in priority order, into something with version control and a rollback.
  • Monitoring on everything we ship: if data stops flowing, your team hears about it first.

Inbound and support — the end of the funnel almost nobody in this category works

Most of this market builds at the top: signals, outbound, ads, content. The bottom is where the companies we’ve worked with were actually drowning. Email, chat and messenger traffic normalized into one structured layer. Every message matched to an account with its history attached. Genuine noise filtered before a human opens the queue. Requests routed to the person who owns that account and answerable from the chat tool your team already lives in. And then the same stream read for what it also is — a signal feed for sales and product, instead of a queue somebody empties.

Email, chat and messenger traffic converging into one structured layer, and three things coming out of it: a request routed to an owner, a signal for sales, a signal for product. The same inbound stream is a queue or a source of revenue depending only on whether it is structured. EMAIL CHAT MESSENGER ONE STRUCTURED LAYER ROUTED TO AN OWNER A SIGNAL FOR SALES A SIGNAL FOR PRODUCT

Where GTM data is involved, we work alongside Extruct AI — an independent, agent-driven company-research platform. They’re a partner, not a part of what we sell, and every answer their agents return comes with its source.

Field notes

Three engagements, described without the client names.

We publish client names only with explicit permission and we don’t have it, so these are written without them — and without any of the clients’ own numbers. What’s here is what was actually broken, what was actually built, and what actually changed. On a call we’ll walk you through the architectures in full.

Case 01 A B2B SaaS company whose support lived in four places

What was breaking
Customer messages arrived by email, chat and messenger, and none of it was connected to the account it came from. Context had to be reassembled by hand on every ticket. Sales had no idea which of their accounts currently had something on fire.
What we built
An ingest and normalization layer across every inbound channel: messages parsed, matched to a company and a contact with their history attached, classified into real requests versus noise with deterministic rules first and AI only on the ambiguous remainder, routed to the manager who owns the account, acknowledged automatically to the customer, and surfaced for reply inside the team’s existing chat tool.
What changed
The queue stopped being a place where things were noticed by chance. Support history became something sales could see on an account before a call, which it had never been.
What stayed with them
The data model, the pipelines, the classification rules and the monitoring — all in their accounts.

Case 02 An overgrown automation stack nobody could fully explain

What was breaking
Dozens of point-to-point automations between tools, several built by people who had since left. Data about the same customer disagreed across four systems. Changing one tool meant rewiring an unknown number of others, so nobody changed anything, and the stack calcified around its own worst decisions.
What we built
First the map: every workflow written down with what it does, what depends on it, and what it would take to move it. Then a coherent data layer underneath, with the CRM, the ticketing system and the chat writing back to it as interchangeable front-ends. Then migration of the critical paths — starting with the ones sales couldn’t survive losing — out of brittle click-tooling into versioned code with rollbacks.
What changed
A single tool can now be swapped without rewriting the data model. The data model stopped living inside any one vendor, which is the only version of “no lock-in” that means anything.
What stayed with them
The architecture doc, the repository, the migration log, and a map of the stack that didn’t exist before we started.
The same tools wired two ways: on the left every tool connected to every other tool point to point; on the right the same tools around one data layer, each connected the same way. The tools became interchangeable because the data model stopped living inside any one vendor. POINT-TO-POINT ONE DATA LAYER

Case 03 Automations that failed silently

What was breaking
When something broke, it broke quietly. The team found out because a customer asked, or because one person happened to check. Half the recovery knowledge existed only as habit, in one person’s head.
What we built
Failures collected, classified by cause, and delivered into the team’s chat together with what to do about them. Alongside that, an access clean-up: services that had been signed up under one employee’s personal email moved onto shared accounts, with a dedicated inbox for system notifications.
What changed
Breakage became a visible, assignable event with a documented fix instead of something one person carried around.
What stayed with them
The failure taxonomy, the alerting, and an access map that says which service belongs to whom.

Anonymized by choice, not by convenience: we publish names only with explicit permission, and numbers from these engagements belong to the clients, not to us. If that costs us credibility with you, ask for the walkthrough on the call — that’s the version with the architecture diagrams in it.

How we hold ourselves to it

We count the share of the work our own hands are still touching.

Consulting has a structural problem: the more indispensable the consultant becomes, the better the consultancy does. We built delivery against that incentive on purpose.

Every engagement is instrumented from the start. We track what portion of delivery still runs through us — the steps someone on our team performs by hand, because they haven’t been codified yet or because the judgment involved isn’t safely automatable. That share is a number we keep, and it goes into the read-out at the end of every cycle whether it moved in the right direction or not.

Then the loop: every manual step we find ourselves repeating gets written down, turned into a workflow, given an eval, and moved off our hands. That’s the actual engine of this business. Not a model, not a platform — a discipline of noticing what we keep doing twice.

The honest part: on the first deployment that share is high. Most of the work is still ours. Anyone in this category telling you their agents are running a revenue operation unattended today is selling you a roadmap and calling it a product. We’d rather show you the number and where it’s heading.

How it runs

Access in week one. A read-out at every gate. A door at every gate too.

  1. Scope, in writing

    We pick one sharp axis to start: one channel, one segment, or one class of breakage. Not “a pilot across the business.” Scope, sequence and cost are written down and agreed before anyone touches a production system.

  2. Access and inventory

    Admin access to the core systems: CRM, ticketing, email, calendar, the automation layer. Then the inventory — every existing workflow written down with what it does, what depends on it, and what it would cost to move, plus which services are sitting on somebody’s personal account. This is usually the first time anyone has seen the whole map on one page, and the map is yours whatever happens next.

  3. The first flight

    Building, in cycles with a fixed scope and a fixed price agreed in writing before each one starts. A weekly rhythm you can set a calendar by: a planning call, a mid-week sync, an async retro, and a plan-versus-done tracker anyone on your side can open. Every decision lands in a running log, so the reasoning survives the people.

  4. Every read-out: three real options

    At the end of each cycle, a scheduled checkpoint with three outcomes that are all genuinely available. Continue into the next cycle, re-scoped on what the data now says. Pivot — same budget, different target, because the first axis turned out to be the wrong one. Exit — you keep everything and we stop, with no penalty.

A cycle running into a scheduled read-out, and three outcomes leaving it — continue, pivot, exit — drawn identically, in the same weight, each ending in its own arrowhead. Continue returns to the next read-out. Exit is a designed step of the process, not an escape hatch. CYCLE READ-OUT CONTINUE PIVOT EXIT

What we need from you

  • About an hour a day of attention from one person who can make decisions. A hard precondition, and we say it before you sign anything. The engagements that don’t ship are the ones where the client disappears.
  • Admin access to the core systems in week one. In practice this is the single most common thing that stalls a start — somebody hunting for who owns which login.
  • A willingness to cut scope. A first cycle that ships beats a roadmap that doesn’t.

What you keep

  • The architecture doc how your revenue data is modelled and why, in language your next hire can read.
  • The workflows running in your accounts, in your tools, under your credentials.
  • The evals the tests that tell you when a workflow drifts, and the cases they run.
  • The code in your repository, versioned, with the rollbacks that come with it.
  • The decisions log every call we made and the reason, plus the workflow inventory, including the parts we never got to.
Five artefacts — the architecture doc, the workflows, the evals, the code, the decisions log — drawn inside a boundary marked "your accounts", with RevFactory outside it and no line crossing between them. Everything built sits on your side of the perimeter, so nothing leaves when the work ends. YOUR ACCOUNTS THE ARCHITECTURE DOC THE WORKFLOWS THE EVALS THE CODE THE DECISIONS LOG REVFACTORY
The dashed line stops short on purpose: it is an edge that was never built.

It’s tool-agnostic by construction. The data layer doesn’t care whether your CRM is the one you have today — swap the tool, keep the model. You’re buying architecture, which is the opposite of buying lock-in.

The alternatives

Every column here is a real option. We’d rather you pick the right one.

This is the shortlist the companies we work with had open when they found us. Two of these are genuinely better choices in some situations, and we’ll say which on the call.

RevFactoryA senior RevOps hireA GTM / RevOps agencyAn AI SaaS subscriptionBuild it internally
What you’re buying The function, delivered as working systemsA person, and the function eventuallyOutput on one surface of the funnelA product, plus the job of running itYour own team’s next quarter
Where the work lives Inside your existing stackInside your existing stackOften partly in theirsIn their productInside your existing stack
Who builds it The people you talk to on the callOne person, aloneAn account team you meet after signingYou doThe person already doing three jobs
What’s left if it ends Architecture, workflows, evals, code, decisions logWhatever they wrote downUsually the results, rarely the systemNothing — it leaves with the subscriptionYours, if it ever ships
Honest failure mode Wrong scope on cycle one — that’s what the read-out is forA great hire with no leverage, burning out on hygieneWins at the top of the funnel on a broken foundationAnother animal in the zooIt never gets prioritised

Look at the second column first. If you have the budget approved, the patience for the search and a mandate wide enough to keep them, hire — genuinely. We’re the answer for the far more common case: the work is real, it’s bursty, and $120K plus a six-month search cannot be justified against it.

Before you book anything

Four things we won’t tell you.

  • That it’s autonomous. It isn’t, not yet. A meaningful share of this still runs on people, ours included, and we measure that share rather than describe it away.
  • That we’ve done it a hundred times. We’re a small senior team and we take on few engagements at once. What we have is depth in the ones we’ve run, not volume.
  • That you can be hands-off. About an hour a day of attention from your side is a hard precondition, not a nice-to-have. If nobody on your team has that hour, this won’t work, and we’ll say so on the first call rather than after the invoice.
  • That we’re right for everyone. If your revenue operation is genuinely simple, or you already have a strong RevOps function, you don’t need us. Talk to us anyway if you want a second opinion — but we’d rather tell you that than sell you a cycle.

Who does the work

The people on the call are the people writing the pipelines.

RevFactory is Greg Orlov and Georgy M., working out of Tbilisi. There’s no account layer between you and the build, no junior team you meet after signing, and no discovery theatre — the person who scopes the cycle is the person whose name is on the commits.

We’re small on purpose, which means we’re capacity-constrained and we say no fairly often. It also means we’ve run these functions ourselves rather than advised on them, and we build the systems we wanted back when we were the ones being escalated to.

Our clients come from RevGuild, the community of around fifty revenue and go-to-market operators across Europe and the US that we run. We’re not buying attention. People watch us work first and hire us afterwards.

  • Greg Orlov Tbilisi
  • Georgy M. Tbilisi

The long game

Do this long enough and the operation starts having a memory.

The reason a customer churned is in a support thread. The objection that kills your deals is in call recordings nobody re-listens to. The feature that would unlock your next tier of revenue has been asked for repeatedly, across three channels, matched to zero accounts. Every company your size runs on knowledge like this, and almost none of them can query it.

Each workflow is useful by itself. What happens over several cycles is less obvious: the support stream, the deal history, the enrichment records and the campaign results end up in one structured layer instead of four disconnected ones. Questions that used to require a person who remembers become questions you can ask the system.

We’re deliberately not selling that as the deliverable. Programs that start by promising a company-wide brain are exactly the ones that die in month four. It’s where this goes if you keep going — one workflow at a time, each one paying for itself before the next one starts.

Fit

We turn work down. Here’s the line.

This fits if

  • You’re B2B, somewhere between 20 and 200 people, with a go-to-market motion that already works well enough to be worth fixing.
  • Your stack has grown organically — a CRM, a ticketing tool, a chat tool, an automation layer, a spreadsheet that matters more than it should.
  • Nobody owns revenue operations, or somebody owns it on top of their real job.
  • The person reading this is the founder or the person running growth — someone who can say yes without a committee, and be on the calls.

This doesn’t fit if

  • You’re pre-product-market-fit and what you need is customers, not operations. Fix the motion first; there’s nothing to systematize yet.
  • You want someone to execute a fixed spec, or to run outbound campaigns. A dev shop is cheaper for the first; there are good agencies for the second.
  • You want a tool you can buy, install and forget. We’re not that, and we’d be a bad version of it.
  • Nobody on your side has an hour a day. This one isn’t negotiable.

The questions we actually get asked.

What does it cost?

Fixed scope and fixed price per cycle, agreed in writing before any work starts — which is why there’s no number on this page: the answer depends on scope, and we’d rather scope it properly than post a figure that’s wrong for you. The useful comparison isn’t a software line item, it’s the hire: a senior RevOps person costs around $120K loaded before you count the six-plus months of searching, and this work arrives in bursts that are hard to justify a salary against. You’ll get real numbers for your scope on the first call, on the call itself.

Is this a tool we have to adopt?

No. There’s no RevFactory interface, nothing to migrate and nothing new for your team to learn. They keep working in the CRM, the ticketing system and the chat they already use. What we build sits behind those tools, in your accounts, on your data. If we disappeared tomorrow, it would keep running.

How is this different from hiring someone?

A hire is one person’s throughput and it takes half a year to acquire. We’re two senior operators who have done this inside more than one stack, we start in weeks, and what we leave behind is written down: architecture, workflows, evals, code, decisions. If you make the hire later, they inherit a documented operation instead of an archaeology project. Some of our clients will make that hire eventually. That’s a good outcome, not a lost one.

How is this different from an agency, or from an automation freelancer?

An agency is usually paid to produce output on one surface — campaigns, sequences, ads. A freelancer builds the automation you ask for, and it works until something upstream changes. We work the other direction: inventory first, then a data model that doesn’t depend on any single vendor, then workflows on top of it, each one written down, alarmed and evaluated. The difference shows up the third time you change a tool.

Will AI be making decisions about our customers?

Not the irreversible ones. Deterministic rules handle the cases that are actually obvious, because they’re faster and cheaper and don’t hallucinate. AI handles the ambiguous middle. Anything high-stakes routes to a person with the context already attached. That isn’t a safety disclaimer — it’s the cheapest architecture that works.

How do we know a workflow still works six months from now?

Because it ships with an eval: a set of cases with known correct answers that runs against it. Combined with failure alerts on every pipeline, drift and breakage surface to your team rather than to your customer. This is the part most of this category skips, and it’s why handovers usually decay.

What if it doesn’t work out?

You exit at the end of any paid cycle without penalty and keep everything: architecture doc, pipelines, code, evals, decisions log, workflow inventory. Every cycle ends with a scheduled read-out where exit is one of three named options, not an awkward conversation you have to start yourself.

Who actually does the work, and how much of our time does it take?

The two people you meet on the call. No delivery team behind a curtain and no handoff to someone you’ve never spoken to — which is also the honest limit on how many engagements we run at once. From your side: about an hour a day from one person, plus admin access to the core systems in week one. We’re blunt about the hour because it’s the strongest predictor of whether an engagement ships.

Can you name a client, and where should we start?

We can’t name one: we publish names only with explicit permission and we don’t have it, and we’d rather say that plainly than dress up a case with a fake descriptor. On a call we’ll walk you through real architectures in detail, which turns out to be more convincing than a logo wall anyway. As for where to start — whatever is bleeding, and it’s usually obvious in the first ten minutes. Support drowning across channels. A CRM whose data nobody trusts. Automations that fail quietly. Leads sitting unrouted. If it isn’t obvious, that’s what the inventory is for.


Bring the actual stack and the actual problem.

Thirty minutes with Greg. No deck and no discovery theatre — we’ll go through what’s running today, tell you what we’d build first and roughly what it takes, and say plainly if this isn’t work we should be doing for you.

One call, one person, no follow-up funnel. If we’re not the right answer, we’ll tell you what is.