Should you hire a RevOps consultancy on a retainer or a fixed scope?

Where this comes from: published contracting research, plus what we've learned from our own deals and from sitting in competitors' sales processes as a buyer. Public figures were checked on 29 July 2026.

The evidence

The best data argues against fixed price, not for it. In 2017 Magne Jørgensen, Parastoo Mohagheghi and Stein Grimstad looked at 407,815 small outsourced software projects — 404,348 fixed-price and 3,467 time-and-materials. After controlling for client, provider, collaboration and project variables, fixed-price contracts showed 16.4 times the odds of failure. The overall failure rate in the data was 11.8%. The authors are careful not to claim this proves cause, and the time-and-materials sample is small next to the fixed-price one.

Fixed-price risk gets worse as projects get bigger. A 2022 study of 338 software projects found costs were underestimated by 12.6% on average. The underestimation was worst in the largest 20% of projects.

Contract type might not be the real lever. Mohammad Suprapto and colleagues studied 113 capital projects. Once they controlled for how well the teams worked together, contract type made no direct difference to performance. What mattered ran through collaboration quality instead.

Buyers still prefer fixed price. IDC surveyed 656 business consulting buyers in March 2026. Fixed price was the preferred model for 62.2%, time-and-materials for 28.5%, outcome-based for 9.1%.

But almost nobody uses one model only. A March 2025 Productive survey of 93 agency leaders found 76% mostly use project-based billing. Promethean Research's 2026 report found the common pattern is a mix of time-and-materials, fixed bid and retainer, with 8% or fewer agencies using a single model exclusively.

Why the order matters more than the billing model

We sell retainers. We just won't sell you one first, and the research above is why.

The Jørgensen finding is about fixed price when the scope is unclear. A twenty-hour diagnostic at about €1,400 carries almost no fixed-price risk, because the scope is small and knowable. What it buys is certainty for the next decision.

Before a first project, nobody can price the real work honestly. We don't know which workflow nobody dares touch. We don't know where your lifecycle logic contradicts itself. We don't know whether your reporting problem is a reporting problem or a data problem in disguise. And you don't know whether our estimates hold, or whether we document anything.

There's theory behind this too. Cornelia Gaebert and Karlheinz Kautz looked at 468 short-term software outsourcing contracts. They found contract choice follows who can watch the work: when the client monitors delivery, deals lean toward time-and-materials; when the vendor does, they lean toward fixed price. The right contract depends on what you know. A first project is how you get to know it.

How the four billing models compare

Retainers fail because they get vague. Fixed scope fails because it pretends to certainty it doesn't have. Time and materials fails because buyers get nervous about the running total. Where you draw the boundary matters more than what you call the deal.

For what each of those models costs in practice, see how much fractional RevOps costs.

Where open-ended retainers go wrong

The problem isn't that a retainer is monthly. The problem is that it can become unclear what you're paying for. And unclear deals drift in the provider's favour, not yours.

Jonathan Stark has the best name for it: the zombie retainer. It keeps invoicing after the client has stopped taking the advice and stopped using most of the reserved hours. Still billing, no longer clearly delivering. That's a named practitioner observation, not a study, and we couldn't find data that measures how often it happens.

Drew McLellan of the Agency Management Institute writes about scope creep as the thing that quietly destroys agency margin — agencies over-delivering against a contract nobody manages any more. He also notes clients dislike the word "retainer" because it sounds like a long commitment. Those are the same problem seen from opposite sides of the table.

The strongest case for retainers, which we take seriously

Systems work doesn't end at go-live. A build-and-leave model can hand you an implementation that slowly falls apart.

HubSpot's own documentation shows why. Super admins control permissions and partner access. Workflow failures can come from the workflow itself or from a single record. Real systems collect permission drift, odd records, broken syncs and failing automations. Someone has to look after that — which is the argument for revenue data observability, so the failures surface before someone notices a number is wrong.

Practitioners who inherit systems are blunt about it. SalesforceBen describes taking over a third-party-built org as potentially overwhelming, because of bugs, automation complexity and technical debt. KeelCadence says documentation is usually incomplete and ownership unclear. As a rough analogy for software decay, a study of GitHub projects found fewer than half survive beyond five years.

So: ongoing care is often genuinely needed. What that doesn't prove is that the care has to be an open-ended retainer with the firm that built the thing. An internal admin, a support-only specialist, or a capped support plan all solve maintenance without the vagueness. If you're weighing what that admin work costs either way, what a HubSpot admin costs splits it into the three jobs it really is.

The clauses that decide whether you can leave

If a firm says you can leave cleanly, the contract has to say so. Ask for these no matter who you hire, including us.

Access and ownership

• Name your own super admins on day one. HubSpot's documentation is clear that the super admin controls user permissions and partner access. If the consultancy holds that seat alone, you don't control your own system.
• A written right to remove partner access, without breaking anything when you use it.
• Written ownership of custom code. Paying for work doesn't automatically transfer ownership — US Copyright Office guidance on work made for hire is strict about this. Pair it with a carve-out so the firm keeps its own frameworks and you get full rights to your build.

Getting out

• Documentation as a contract deliverable — architecture, a list of workflows, dependencies, credentials, standard procedures. Every source above says this is the thing that turns out to be missing.
• Data export rights, and an agreed handover format.
• The right to end the contract for convenience, with a set notice period and a transition-help clause. UK government exit schedules and the US federal continuity-of-services clause show what experienced buyers ask for.
• A final sign-off milestone. Without one, "done" stays a matter of opinion and the project drifts into support work nobody agreed to.

We couldn't find many public cases of firms refusing to hand over admin access. What the sources show is quieter than that. Lock-in usually looks like a system that works, where nobody inside knows why. Enterprise HubSpot implementations are where we see that pattern most often.

Which is the real argument for buying a small scope first. You get to see whether the documentation shows up before you depend on it.

Related reading

• How much does fractional RevOps cost? — what each engagement model costs, and the arithmetic behind published retainers.
• How much does a HubSpot admin cost? — the three jobs hiding inside "admin," and why seat count doesn't matter.
• How we scope work, and what a first conversation looks like.

Frequently asked questions

So do you sell retainers or not?

Yes, but not as the first thing. A fixed-scope project comes first. Then a retainer or a second scope, depending on what the work turns out to need.

Isn't a fixed scope riskier for me?

For a big build where nobody is sure of the requirements, yes. The research is clear on that. For a small first project it's close to risk-free, and its whole job is to make the bigger scope possible to estimate.

What if I already know exactly what I want built?

Then a fixed scope is the right tool and the first project can be the build. The order exists to handle uncertainty. If there isn't any, skip it.

Why not just use time and materials for everything?

It's a defensible choice, and the data treats it better than most agencies admit. The trade-off is that you carry the overrun risk and have to stay closely involved — which is probably why it works.

How long should a first RevOps project be?

Long enough to produce a plan you can trust, short enough that being wrong is cheap. Ours start at 20 hours, and the top-priority items are usually live in about three weeks.