RevOps for UK Scale-Ups: A Practical Guide

Most RevOps guides for scale-ups start with a definition, move on to a tool comparison, and end with a case study that is too vague to be useful. This one starts somewhere different: with the diagnosis that most RevOps problems at the scale-up stage are traceable to a CRM data model that was built around the founding sales motion and never updated when the business changed.

If you are a founder, VP Sales, or CRO at a UK B2B business somewhere between £2M and £20M ARR, and you are reading this because your pipeline reporting does not feel trustworthy, or because a Series A conversation has suddenly made the state of your CRM very visible - this is written for you. The advice here is based on repeatedly inheriting broken HubSpot instances and working out what went wrong and why. The pattern is almost always the same.

What RevOps Actually Means at the Scale-Up Stage

At £2M-£20M ARR, RevOps is not a department. It is a set of decisions: how pipeline data flows through your systems, who owns which records in the CRM, whether your lifecycle stages reflect how the business actually sells or how someone thought it would sell in 2021. Most scale-ups are already doing RevOps - they are just doing it badly, without naming it, split across three people who have never agreed on the definitions.

The distinction worth making early is between RevOps as a discipline - process design, data model governance, handoff logic, attribution - and RevOps as a hire. Conflating the two is how you end up writing a job description before you have decided what the function is supposed to do. The job title inflation in this space is significant. "RevOps Manager" at a 30-person company often means "the person who maintains HubSpot and runs the weekly pipeline report." That is CRM administration with a better title. It is useful work, but it is not the same thing.

The clearest signal that RevOps is broken before anyone admits it: the leadership team does not trust the pipeline number. If the VP Sales and the CEO are reconciling the forecast in a separate spreadsheet on a Monday morning, you have a RevOps problem regardless of what your CRM looks like or what your tech stack costs per month.

The Four Things That Break First

Attribution nobody trusts. Marketing says the lead came from a LinkedIn campaign. Sales says it was an outbound sequence. The CRM says "offline source." The real problem is not that the attribution model is wrong - it is that the argument about attribution is replacing the conversation about why conversion is low. In HubSpot, a specific failure mode to watch for: the original source and latest source fields are both set to "direct traffic" for 60% or more of your contacts because UTM parameters were never configured consistently and sequence enrolment overwrote the original source value on first contact. Once that data is gone, it is gone. You cannot rebuild it retroactively from the CRM.

The HubSpot instance the last SDR set up. Custom properties created for a campaign in Q3 2022 that nobody uses. Deal stages with names like "Qualified - Hot" that were added informally and now sit in the pipeline alongside stages with actual entry criteria. Lifecycle stage fields that have been manually overridden so many times the automation has stopped firing correctly. A deal stage that has not moved in 90 days is almost always a stage the team does not believe in - they are skipping it manually because it does not reflect how they actually sell. If you pull your pipeline and find deals clustered in one or two stages with very long average times, that is not a performance problem. That is a data model problem.

Handoff that lives in Slack. Sales to CS handoff is a message to a shared channel with a link to the deal. No handoff checklist, no required fields enforced at close, no CS visibility into what was promised during the sales cycle. The CS team finds out three weeks into implementation that the customer had specific onboarding requirements that were discussed in a call in month two of the sales cycle and never made it into the CRM. People call this a communication problem. It is a data model problem. The information was never required to exist in a structured form, so it did not.

Reporting built for the founding team. The dashboard was set up when the company had five salespeople and one marketing channel. It shows total new deals created, total revenue closed, and average deal size. A Series A CFO will look at this for a few seconds before asking for conversion rate by stage, average sales cycle by segment, MQL-to-SQL conversion rate, and pipeline coverage by rep. None of that is in the existing report because nobody built it, and building it retroactively requires clean historical data that does not exist.

All four of these trace back to the same root cause: the CRM data model was built around the founding sales motion - usually one or two enterprise deals closed personally by the founders - and was never updated when the ICP changed, the sales cycle shortened, or a second channel was added. You cannot fix attribution without fixing the data model. You cannot fix reporting without fixing attribution. The order matters, and skipping steps is why so many RevOps projects at this stage produce dashboards that look credible and measure the wrong things.

Fractional RevOps vs. In-House Hire vs. Agency: The Honest Trade-Offs

Under £5M ARR: A Full-Time Hire Is Usually the Wrong First Move

The function does not yet have enough scope to keep a full-time RevOps person genuinely busy with the right work. What you need at this stage is someone to build the foundation - data model, lifecycle stages, attribution framework, handoff definitions - not someone to run it indefinitely. A full-time hire at this point typically ends up maintaining a CRM and attending pipeline reviews. That is £55,000-£70,000 a year in London for work that should take three months to complete properly and then be handed over to an operations-capable person in the existing team.

When Fractional Makes Sense

Fractional RevOps works best as a scoped project resource, not as a cheaper alternative to a full-time hire. The pitch is often "senior expertise without the full-time salary" - which is accurate, but it misses the more important question, which is whether you need a project or a function. Fractional works well post-Series A when you have a specific implementation to deliver, a defined timeline, and someone internal who will own the output once the engagement ends. It breaks down when it becomes open-ended and the fractional person ends up doing the same ongoing operational work a junior in-house hire would do, for more money per hour. Worth being honest with yourself about which one you are actually buying before you sign anything.

When In-House Is the Right Call

The right call is when you have a VP Sales or CRO who needs genuine operational support every day - a function, not a project. At Series A and above, with a sales team of ten or more and multiple channels running, the volume of operational work justifies a dedicated hire. The key question to answer before you post the job: are you hiring for a build or a run? Those are different roles and they attract different people.

When an Agency Model Works

One-off implementations, integration projects, compliance work, or specific tooling builds. An agency does not work for ongoing pipeline governance or process adoption - that requires someone embedded in the team who is in the weekly meetings and understands the context. The agency model works when the scope is defined, the timeline is fixed, and there is a clear internal owner to hand over to at the end. Without that internal owner, you will be back six months later with a different problem caused by the same underlying gap.

HubSpot vs. Salesforce at the Scale-Up Stage: A Decision Framework

For most UK B2B scale-ups at Series A and below, Salesforce is the wrong choice. That is not a reflection on Salesforce as a product - it is a reflection on what a proper Salesforce implementation actually requires. You need a dedicated Salesforce admin in-house, a consulting partner for the initial build, and a realistic six-month runway before the system is functioning well enough to be useful. Most scale-ups at this stage have none of those three things, and attempting Salesforce without them produces something worse than a well-configured HubSpot instance.

Salesforce starts making sense at specific trigger points: a dedicated admin already in-house, complex territory management requirements, multi-currency and multi-entity finance integration, or an investor or board mandate - which is common when a US VC has Salesforce-based portfolio reporting and wants consistent data across their UK companies. If none of those apply to you right now, HubSpot is the right answer and the conversation is over.

HubSpot has specific limitations that matter at Series B and above, and being vague about them is not helpful. The custom report builder has improved significantly but you will hit real constraints on cross-object reporting - particularly when you need to combine deal, contact, and company data in a single filtered view. The multi-object association framework introduced post-2022 has closed a lot of gaps in the data model, but if you need complex relationship hierarchies - multiple business units under a parent account, each with separate pipelines and separate CS owners - HubSpot will require workarounds that create their own maintenance overhead. Custom objects, which are the main tool for extending the data model, are available on Enterprise tier only. If you are on Sales Hub Professional, you do not have them, which means the data model ceiling is lower than you might assume.

The practical decision rule: if you can describe your revenue model clearly enough that HubSpot's standard objects - contacts, companies, deals - cover it with minor extensions, use HubSpot. If your revenue model requires a data model that those objects do not map to cleanly, that is the point where Salesforce starts to be worth the overhead. Most UK scale-ups at Series A are nowhere near that point.

Building Pipeline Attribution That a CFO Will Believe

First-Touch vs. Multi-Touch: Consistency Matters More Than the Model

The attribution model matters less than most people think. The most damaging attribution failure at this stage is switching models mid-year because the board asked a question the current model could not answer. A first-touch model that has been consistent for 18 months tells you something meaningful about where your pipeline is coming from. A multi-touch model that was switched to in October tells you nothing about the first nine months of the year, and any CFO doing proper diligence will notice the gap immediately.

The HubSpot Attribution Reports Worth Using

The contact create attribution report using the original source breakdown is useful, but only if your UTM discipline is solid. Run the report and check what percentage of your contacts have "direct traffic" or a blank as their original source. If that number is above 30%, the report is not telling you much. The revenue attribution report in Marketing Hub is worth using if you want to understand which campaigns are contributing to closed revenue rather than just to contacts created - the distinction matters and the numbers will often surprise you.

The report that looks impressive but measures the wrong thing for most scale-ups: deal attribution by "first page seen." It is technically interesting but practically useless unless you have consistent web tracking across every touchpoint, which most businesses at this stage do not have. Do not present it to a CFO.

The GDPR Attribution Gap

UK B2B scale-ups running outbound sequences have a specific attribution problem that most RevOps guides do not address. A contact is enrolled in a HubSpot sequence from a cold outreach list. They do not reply, but three weeks later they fill in a form on the website. Depending on how the form was configured, HubSpot may record their original source as "email marketing" or overwrite it with "organic search." The CRM does not know whether the form fill happened because of the sequence or independently of it. One channel gets the credit and the other gets nothing, and the model cannot tell you which assignment is correct.

This has a compliance dimension that goes beyond reporting. If your legitimate interest basis for processing that contact's data was documented against the outbound sequence, and they came inbound independently, your consent records and your attribution records are now both ambiguous. That ambiguity tends to be discovered for the first time during Series A due diligence, not before it.

What I would do here is create a custom contact property to record the first human-documented touchpoint separately from HubSpot's automated source tracking. It is an extra field, but when the automated attribution report produces a number that does not feel right, the CFO can interrogate the manual field. That is the one they will trust.

UK-Specific Considerations Most RevOps Guides Skip

UK GDPR and Outbound CRM Strategy

Most UK scale-ups running outbound sequences are relying on legitimate interest as their legal basis for processing prospect data. That is a defensible position, but a legitimate interest assessment needs to be documented and proportionate. The majority of businesses using this basis have not written one - they have made a business judgement that legitimate interest applies and moved on. If that gets challenged through an ICO complaint, a subject access request, or due diligence from an acquirer, the absence of documentation is a material problem.

In HubSpot terms: if you are enrolling contacts in sequences without a documented legal basis recorded against each contact source, your CRM is holding data it may not be entitled to hold. The volume of that data tends to become visible for the first time during Series A due diligence, at a point when there is very little time to fix it cleanly.

The UK RevOps Talent Market

London has RevOps talent but the title is inflated and the market is expensive. A "RevOps Manager" in London with two years of HubSpot experience and a history of building dashboards will cost £55,000-£70,000 and may not have the process design or systems integration skills the role actually requires. Regional markets - Manchester, Bristol, Leeds - have operations-capable people who have been doing the work under titles like "Sales Operations Analyst" or "CRM Manager" without the RevOps branding. Worth looking there, and worth writing a job description that describes the specific scope rather than relying on the job title to filter candidates. "RevOps Manager" in a job title attracts a wide range of experience levels, a lot of which will not match what you actually need.

What UK Series A Investors Are Starting to Expect

US VCs with UK portfolio companies are bringing US-style RevOps expectations into Series A conversations. They want pipeline coverage ratios, MQL-to-SQL conversion rates, and a defined ICP backed by CRM data. UK founders who have raised from UK-based angels or early-stage VCs often have none of this documented in a form that reads cleanly to a US LP's operating partner. The gap between what the investor expects and what the business has actually built is usually wider than the founder realises. The RevOps work that would have closed that gap was never prioritised because it was not visible until the conversation was already happening.

A RevOps Maturity Model for UK Scale-Ups: Seed to Series B

The point of this model is not to reach Stage 4 quickly. The point is to know honestly which stage you are actually at. Most scale-ups I speak to describe themselves as Stage 3. On closer inspection, the majority are at Stage 1 or early Stage 2. The tell is almost always the same: the leadership team is making decisions from memory and instinct because the CRM data is not trusted enough to rely on.

Stage 1: Seed

The CRM exists and is being used inconsistently. Pipeline is tracked manually in a spreadsheet alongside the CRM, and both are slightly different. No attribution. No defined lifecycle stages. The highest-leverage thing to fix at this stage is getting deal stage definitions agreed in writing and used consistently. Not automated - just agreed. The conversation about what "qualified" actually means is more valuable at this point than any tooling you can add. You cannot automate a definition that does not exist yet.

Stage 2: Pre-Series A

The CRM is becoming the system of record but handoffs are still informal. Reporting is basic - total pipeline, total closed, average deal size. Marketing and sales are operating with separate definitions of what a good lead looks like, and neither definition is written down. The highest-leverage fixes: define MQL in writing and get both teams to agree on it formally; build a single pipeline view that the leadership team uses in the weekly meeting instead of the spreadsheet. Getting rid of the spreadsheet is the milestone that signals Stage 2 is complete.

Stage 3: Series A

Attribution is in place, even if imperfect. Lifecycle stages are defined and at least partially automated. Sales and marketing are aligned on MQL definition. Forecasting is still judgement-heavy but there is data to interrogate. The highest-leverage fixes at this stage are bringing CS into the revenue model - expansion ARR, net revenue retention, churn attribution - and building the sales-to-CS handoff logic into the CRM so it is not dependent on individual effort or a well-timed Slack message.

Stage 4: Series B

RevOps is a formalised function with at least one dedicated hire. CS is included in revenue reporting. Forecasting uses documented assumptions rather than gut feel. The CRM is consistent enough that a new CFO could understand the shape of the business from the data within a week, without needing someone to explain what the fields mean.

Where to Start If You Are Building This From Scratch

The sequence matters: audit before you buy, fix the data model before you build the reporting, define the handoff rules before you automate them. Reversing any of those steps makes the next one harder. The most expensive RevOps mistake I see repeatedly is building a reporting dashboard on top of a broken data model and then spending weeks trying to work out why the numbers do not add up. They do not add up because the inputs are wrong. Fix the inputs first.

The audit questions worth asking before anything else:

• Are deal stage definitions written down somewhere, and does the team actually use them? Check this by looking at how many deals have been sitting in the same stage for more than 60 days.

• Is contact owner hygiene maintained, or are there contacts owned by people who left the company? Pull the list. The volume is usually surprising.

• Is lifecycle stage being set by automation or being overridden manually? Pull the lifecycle stage change history for your last 50 closed deals and see what path they actually took through the CRM versus what the automation intended.

• Is original source data complete? Check what percentage of your contacts have "direct traffic" or a blank value. Above 30% and the attribution report is not reliable.

• Are there required fields enforced at deal close, or is the team closing deals with critical data missing from the record?

Once you have answers to those five questions, you know what stage you are actually at. Do not skip this step in favour of buying a new tool or rebuilding the pipeline stages. The audit tells you what you are actually trying to fix.

On handoff logic specifically: write the handoff rules as a document before you touch the CRM. What information must exist in the record before a deal can close? What does CS need to see on day one of onboarding? Who owns the contact record at each stage of the lifecycle? Once that is agreed between the people who have to follow it, the automation is straightforward to build. Without that agreement, any automation you build will be wrong in ways that are hard to diagnose - because the system will be doing exactly what it was told, and what it was told was based on a process nobody actually signed off on.

Most RevOps projects stall not because the tooling is wrong but because the process was never genuinely agreed by the people who have to follow it. A workflow can enforce a field. It cannot enforce a decision that sales and marketing have not actually made yet. That decision is the work. Everything else is implementation.

If you are at the audit stage and not sure what you are looking at, that is the work I do at Stack Logic. The Revenue Audit at stacklogic.co.uk/services is a structured review of your CRM data model, pipeline logic, and attribution setup - designed to tell you what stage you are actually at before you spend anything on tooling or headcount.