RevOps Consultancy UK: What Good Actually Looks Like

RevOps has become a label every consultancy has stuck on their website in the last three years. That makes it harder to tell the difference between someone who has actually built revenue operations from scratch and someone who has read the HubSpot Academy certification and rewritten their homepage.
What does a RevOps consultancy UK engagement actually involve? Jack Roberts covers maturity stages, failure modes, pricing, and how to choose the right model.
RevOps Consultancy UK: What Good Actually Looks Like
RevOps has become a label every consultancy has stuck on their website in the last three years. That makes it harder to tell the difference between someone who has actually built revenue operations from scratch and someone who has read the HubSpot Academy certification and rewritten their homepage. This post covers what a RevOps engagement actually involves: the maturity stages UK B2B companies sit at, what happens week to week, where these engagements fail, and how to choose the right model. No preamble.
What RevOps Actually Is (And What It Is Not)
RevOps is the operational layer that connects sales, marketing, and customer success through shared data, process definitions, and tooling. It is not a philosophy, a job title, or a rebranded sales ops function - and that last one is the most common mistake at the 30 to 50 person stage, where someone gets promoted into a "RevOps Manager" role without changing any of the underlying process or tooling.
It is also not a CRM implementation project. Buying and configuring HubSpot is a step inside a RevOps engagement, not the engagement itself. The same goes for a reporting exercise bolted onto the end of a quarter because the board wants better pipeline visibility.
The specific failure mode I see most often: companies implement the tooling - HubSpot, Salesloft, Gong - without first defining what a qualified lead is, what pipeline stages actually mean, or who owns the handoff between marketing and sales. The tooling then encodes the chaos rather than resolving it. Every workflow you build on top of an undefined process becomes debt. My starting point on any RevOps engagement is always process before configuration - agree what a lead is before you build lead routing, agree what a pipeline stage means before you build stage-based automation. Everything else follows from that.
The Four RevOps Maturity Stages - Where UK B2B Companies Actually Sit
Most UK B2B companies in the 20 to 50 person range are at Stage 1 or Stage 2. Worth knowing before you scope any engagement, because the right intervention looks very different depending on where you are starting.
Stage 1: No shared definitions. Pipeline data is unreliable because different people use different stages to mean different things. Marketing is measuring MQLs against one definition, sales is working a call list against another, and neither number maps to the other. This is common in UK recruitment agencies under 20 people where the CRM - often Bullhorn or a basic Salesforce org - was configured by a consultant three years ago and nobody has touched the config since. The clearest symptom: the monthly pipeline review involves someone manually correcting the report before it goes to the board.
Stage 2: CRM in place, inconsistently used. Some reporting exists but depends on who pulls it and when. The handoff from marketing to sales is informal - an email, a Slack message, a shared spreadsheet. Common in SaaS scale-ups at the 25 to 40 person stage post-Series A who have bought HubSpot but not configured it beyond contact records and a basic deal pipeline. The symptom here: sales reps have their own tracking system, usually a personal spreadsheet or Notion doc, because they do not trust the CRM data enough to rely on it.
Stage 3: Clean data architecture, defined funnel stages, attribution working in some form. A RevOps function exists - either a dedicated person or a fractional engagement. Handoff criteria are documented. The symptom at this stage is that the system works but breaks when someone leaves, because too much operational knowledge is held in one person's head rather than in the tooling and documentation.
Stage 4: Forecasting is reliable enough to drive decisions. Revenue data is the single source of truth. Tooling is integrated and maintained with a defined owner. Most UK B2B companies at this stage are 100 or more headcount with a dedicated RevOps hire. The board can pull a pipeline report without a footnote explaining why the numbers look different from last month's version.
Stage 3 is achievable in a structured three to six month engagement for a company starting at Stage 1 or 2. Stage 4 typically requires an internal hire. A consultancy can get you to Stage 3 and hand it over; it cannot replace an embedded owner at Stage 4.
What a RevOps Engagement Looks Like Week to Week
Most consultancy sites list services. None of them explain what actually happens. Here is what a structured engagement involves from week one.
The Audit Phase
A proper audit takes two to three days minimum before any recommendations are worth anything. What that actually means at a field and object level: checking field completion rates across contacts, companies, and deals - not in aggregate, but broken down by record type and by the fields that matter to your funnel. A contact record might show 70% completion overall, but if the fields that are empty are lifecycle stage, lead source, and last activity date, that number is meaningless.
Beyond field completion: duplicate contact records (30% duplication is not unusual in a CRM that has been running for three years without a deduplication rule), lifecycle stage transition logic tested against real records to see whether contacts are actually moving through stages or sitting indefinitely in a stage they were assigned eighteen months ago, and pipeline stage definitions mapped against what the sales team is actually doing. If the CRM has eight pipeline stages and the sales team uses three of them, the other five are noise. Worth flagging that in most audits, the gap between the defined process and the actual process is wider than the client expects.
Discovery and Scoping
The conversations that need to happen before scoping: sales, marketing, CS if it exists, and finance if they are pulling revenue data independently. What I am looking for is where the data splits - where the same deal or contact is being counted differently by different functions. The output of discovery is not a 40-slide deck. It is a prioritised list of problems with a rough fix sequence and a clear distinction between what needs fixing before anything else can be built and what can wait.
Implementation Sequencing
Fix process before configuration. If the pipeline stages are wrong, rebuild them before you touch automation. If lifecycle stages have no agreed definition, document and agree them before you build any lead routing. The reason sequence matters: every automation you build on top of a broken process becomes debt. I have seen companies spend four months building a sophisticated lead scoring model on top of a contact database where "lead source" means twelve different things to twelve different people. The lead scoring model then returns results nobody trusts, and the whole thing gets switched off.
Retainer vs Fixed-Scope
Retainer work involves being present in weekly ops cadences, owning the tooling backlog, handling ad hoc configuration requests, and running quarterly audits. Fixed-scope is right for a defined build - an integration, a migration, an audit with recommendations. The failure mode to watch for: hiring a retainer before the foundation work is done. The retainer time gets consumed fixing the same recurring data problems rather than building forward. A fixed-scope audit and clean-up first, then a retainer if ongoing support is needed - that sequence works. The reverse does not.
Fractional RevOps vs Consultancy vs Full-Time Hire - The Honest Trade-offs
There are three models, and the right one depends on where your business sits and what the actual need is.
Full-time hire: right when you have enough ongoing operational work to justify a £60,000 to £80,000 salary plus the management overhead of onboarding and developing someone. Wrong when the immediate need is a one-time system build or a defined integration project. You do not hire a full-time employee to build a pipeline configuration and then maintain it at 20% capacity for the next year.
Fractional RevOps: right for companies that need consistent operational support but cannot justify full-time cost - typically a 20 to 50 person company post-Series A with a functioning CRM that needs ongoing ownership. The honest drawback: if the fractional person is in your business two days a month, most of that time goes on re-contextualising rather than building. You need enough scope to make the engagement coherent, which means at least four to six days a month to maintain meaningful context across a complex stack.
Consultancy: right for a defined project with a clear start and end - an implementation, an integration, an audit. Wrong if what you actually need is someone embedded in weekly ops cadences over the long term. A consultancy delivers the build. You need an internal owner to maintain it after the engagement closes.
The specific failure mode I would flag here: hiring a fractional RevOps person before the underlying process is clean enough for them to be effective. They spend the first two months doing foundational audit and clean-up work that should have been done in a fixed-scope engagement first - and you pay fractional rates for work that should have been scoped and priced differently. Do the audit first, scope the foundation work as a fixed project, then bring in fractional or internal resource to maintain what has been built.
Stack Logic operates as consultancy and defined project work. If you need someone embedded five days a week in weekly standups indefinitely, that is a different model - and I will tell you that upfront rather than take the retainer.
Common Failure Modes - Why RevOps Engagements Go Wrong
Tool proliferation without process design. Buying HubSpot, Salesloft, Gong, Cognism, and an enrichment tool before anyone has agreed what a qualified lead is. Every tool ends up with data in it, none of it matches, and the sales team stops updating any of them because nothing they enter changes anything they see. The fix is not another tool. The fix is agreeing on definitions first, then deciding which tools need to exist.
RevOps without exec buy-in. The RevOps function builds the process, sales ignores the CRM because the sales director has not mandated usage, and within six months the data is worthless. The RevOps person spends most of their time chasing data entry rather than building. If the person running the sales team is not bought in, no amount of tooling configuration fixes that.
Attribution model conflicts. Marketing counts a contact as an MQL from a webinar three weeks ago. Sales counts the same person as cold outbound from a sequence they ran. Both teams report a win on the same deal. The revenue number looks correct but marketing and sales cannot agree on who sourced it, which means neither can be held accountable for pipeline quality. This is a process and definition problem, not a reporting problem - and it needs fixing at the definition level, not by adjusting the attribution model in HubSpot.
Lifecycle stage definitions nobody agreed on. Every report pulls different numbers because "active lead" means something different to marketing, sales, and the MD. The monthly pipeline meeting starts with five minutes of everyone explaining why the numbers do not match. I have sat in enough of these meetings to know that the fix is never in the report - it is in the definitions that should have been agreed before the CRM was configured.
RevOps implemented after the mess. A company grows to 60 people, the CRM has four years of dirty data, contact duplication is at 30%, and they bring in a RevOps person to fix it. The RevOps person spends the first six months doing data hygiene instead of building process. A fixed-scope audit and clean-up project is the right first move here - scoped separately, priced accordingly, delivered before any ongoing RevOps work begins.
UK-Specific Context - GDPR, Data Architecture, and B2B Sales Cycles
GDPR is not an afterthought. It shapes the CRM build from day one. Consent fields, suppression logic, lawful basis tracking - specifically distinguishing between legitimate interest and explicit consent - and data retention policies all affect how you structure contact records. A US-built HubSpot playbook will not account for this. You end up with suppression logic bolted on after the fact, which breaks attribution and creates compliance gaps that are not theoretical. The ICO has issued fines. Cold outreach via automated sequence to a contact with no documented lawful basis is a live risk, and it affects how lead routing, lifecycle stage transitions, and sequence enrolment logic need to be built from the start.
UK B2B sales cycles, particularly in recruitment and professional services, are relationship-driven and longer than US SaaS benchmarks. A deal sitting in discovery for 45 days is normal in UK executive search. Pipeline velocity metrics need calibrating against realistic UK cycle lengths or you will spend every pipeline review explaining why everything looks slow relative to the targets someone set using a US SaaS benchmark as a reference point.
For recruitment agencies specifically: Bullhorn as the primary CRM introduces data architecture decisions that HubSpot integrations need to account for carefully. Candidate records, client records, and placement records do not map cleanly to HubSpot's contact, company, and deal model. Syncing these without first defining the data architecture creates duplication and attribution problems that compound quickly. Worth flagging that Bullhorn's standard API tier rate-limits at 60 requests per minute, which becomes a meaningful constraint when you are syncing high-volume candidate records in real time - you need to design the sync logic around that limit from the start, not retrofit it after you hit the ceiling.
How to Evaluate a RevOps Consultancy UK - What to Ask
Ask to see a sample audit output or deliverable. If they cannot show you what they produce, that is a meaningful red flag. A consultancy with a repeatable process can show you the structure of an audit report, the categories it covers, and what the output looks like. Ask specifically what their CRM audit covers at a field and object level. If the answer is vague, so is the process.
Ask how they handle the situation where the diagnosis reveals the problem is process, not tooling. A good consultancy tells you to fix the process first even if that delays the implementation they are billing for. If the answer is "we will configure around it," that is the answer you do not want. Configuring around a broken process makes the process harder to fix later.
Ask specifically about UK compliance experience - GDPR, ICO, data retention. HubSpot certifications are not a proxy for this. Ask whether they have built consent management and lawful basis tracking into a CRM architecture before and what that looked like in practice.
Watch for consultancies that lead with the tool rather than the problem. If the first conversation is about HubSpot features, they are selling a product. If it is about your current pipeline data quality and what you can and cannot trust, that is a consultancy.
On pricing: a proper fixed-scope audit should run £2,000 to £3,000. A full implementation project from £8,000 to £20,000 depending on complexity - an audit plus pipeline rebuild plus one integration sits at the lower end, a full CRM migration with multiple integrations and custom reporting at the upper end. Retainer work at £1,500 to £4,000 per month depending on scope. Anyone quoting significantly below these ranges is either scoping very narrowly or cutting somewhere you will find out about later.
If you are not sure where your revenue operations currently sit, the Revenue Audit at stacklogic.co.uk/services is the right starting point. It is two to three days of structured diagnosis - covering CRM data quality, funnel definitions, tooling configuration, and handoff logic - that tells you exactly what to fix and in what order, before any implementation work begins. That sequencing is the whole point.