RevOps for Vertical SaaS

When your vertical SaaS crosses £5M ARR — usually around 30 to 40 employees — the pressure to expand into a second vertical feels obvious. You've got product-market fit. You've built a sales motion. The next play is to repeat it.

Then you hit a wall.

Midmarket logistics isn't midmarket fintech. The procurement process is different. The buyer committee looks different. The deal structure is different. The sales cycle isn't three months anymore — it's seven. And suddenly the RevOps playbook that worked for vertical one is actively breaking vertical two.

This isn't a scaling problem. It's a process design problem.

Most SaaS founders think RevOps is about tools. You integrate the CRM, the product, the data warehouse. You build a pipeline forecast. You layer in automation. Then you expect it to work across two verticals with fundamentally different deal structures. It doesn't.

The real issue: RevOps is only as good as the process it sits on top of. A broken sales process + a slick dashboard = a broken sales process that you can see in real time.

Vertical SaaS companies typically have two failure modes here.

The first is over-standardization. The sales team pushes back on "one CRM, one process, one forecast." So you carve out exceptions. Vertical one uses one forecast model. Vertical two gets custom fields. Vertical one has 30-day pipeline. Vertical two has 90-day. You've now got two CRMs in one system. Your data fragments. Your CFO can't forecast. Your VPs spend 30% of their week reconciling spreadsheets.

The second is under-standardization. You let each vertical do its own thing. Real enough at first. Then it compounds. Vertical two hires its own sales engineer, its own sales ops person. Vertical two's SDR talks to vertical one's AE in the hallway and discovers they're scoring leads differently. By the time you're at £15M ARR, you've accidentally built two separate sales organizations inside one company. Good luck integrating them later.

What works instead is building vertical-aware processes. Not one process. Not two separate processes. One architecture, multiple configurations.

This means: define the stages and the criteria. Don't say "prospect to qualified lead is 30 days." Say: "prospect to qualified lead requires three discovery calls, a technical evaluation, and a budget conversation. That takes 30 days in logistics because procurement is slow. It takes 45 days in fintech because compliance reviews the deal. The pipeline stage is the same. The timeline varies." Your CRM captures both.

Second, unify your data model early. Don't wait until you have five verticals. Write down exactly what information you need to forecast. For most companies: account status, deal size, close date, loss reason, technical fit, buyer seniority. Same fields for all verticals. You're not adding custom fields. You're filling the same fields with context that makes sense for that vertical.

Third, measure what matters. Most RevOps teams measure activity: calls, emails, meetings. Activity means nothing if it's wrong activity. Measure outcome: deals closed, time to close, win rate by vertical, by product line, by buyer persona. Once you have that data, you can actually see where one vertical is broken and where one is working.

The hard part isn't building this. It's getting a sales team that's used to doing their own thing to accept a unified process. You need to be honest about what you're asking them to do — accept trade-offs. Yes, you lose some flexibility. No, vertical two can't add seven custom fields just because the deal needs them. The exchange is clarity. The forecast actually works. Reps know where deals really are. Your CFO stops living in a spreadsheet.

This is where a lot of companies stumble. They say "unified process" but then don't enforce it. The CFO's dashboard is nice until the VP of Sales carves out exceptions every month. The process breaks down. By £10M ARR, nobody's following it anymore.

The companies that make this work think of RevOps as operational design, not tool setup. They design the process first. The tools follow. Salesforce is just the record. The real RevOps is how you move a deal through your system, what information you require at each stage, what happens when something is wrong.

Start there. Then the vertical expansion actually works.