The question is usually framed as a choice between hiring in-house, outsourcing to a contractor, or engaging an agency. That framing produces the wrong answer, because it treats RevOps as one job.
RevOps work splits into four types, and most resourcing mistakes come from buying one and needing another:
- Architecture: the data model, pipelines, lifecycle stages, revenue definitions and permission structures. Low volume, high consequence, expensive to unwind.
- Build: workflows, properties, dashboards, integrations, automation. Where the hours go during an implementation.
- Operations: data hygiene, request triage, user setup, small changes, keeping automation honest. Recurring and never finished.
- Enablement: training, documentation, adoption, and confirming that the process people were trained on is still the one they follow six months later.
Most businesses need all four. The useful question is which mix, and in what order.
Which model is strongest at which work
| Work type | What it covers | Best resourced by |
|---|---|---|
| Architecture | Data model, pipelines, lifecycle stages, revenue definitions, permissions | Agency. Pattern recognition across many portals matters more than proximity |
| Build | Workflows, properties, dashboards, integrations | Agency or contractor, inside an architecture someone else owns |
| Operations | Hygiene, triage, user management, small changes | In-house, once volume justifies a permanent role |
| Enablement | Training, documentation, adoption | Agency to establish, in-house to sustain |
| Model | Strongest at | Failure mode | Best fit |
|---|---|---|---|
| In-house hire | Operations and enablement | Single-person dependency, and scope drift into ad hoc reporting | Sustained change volume and enough process maturity that the role is not swallowed by report requests |
| Outsourced contractor | Build | Executes the brief without questioning it; stalls quietly when access is restricted | Discrete, well-specified work inside an architecture someone else owns |
| Agency | Architecture and build | Permanent dependency where enablement is not contracted | Implementation, remediation and periods of significant change, or when the requirement is not yet clear |
Three questions that decide it
These settle the decision faster than a headcount calculation.
Can you name the person who owns your CRM? If not, no resourcing model helps until that is resolved. Ownership is a decision, not a hire.
Is there a documented design for your CRM? Not a diagram. A document stating what each object is for, what each stage means, what each revenue metric includes and who may change what. Where it exists, an in-house hire can maintain it. Where it does not, you need architecture before capacity, which argues for an agency first.
What happens if your most capable administrator resigns next month? If the honest answer is that reporting stops, you have a continuity problem rather than a resourcing problem, and a second trained champion plus written documentation is cheaper than a new role.
1. In-house: proximity, with two predictable risks
An internal hire develops a deep understanding of the commercial model and can turn a hallway request into a workflow the same afternoon. Where a client has appointed a genuine RevOps owner, decision quality improves immediately.
On a B2B SaaS engagement, an incoming Head of RevOps joined partway through the project and advised against investing in a complex revenue calculation fix, on the grounds that finance was restructuring the underlying deal data and a simplified figure was adequate for tiering in the interim. That is a call only someone inside the business can make.
On a US fintech engagement, the client's Revenue Operations Specialist identified duplicate records introduced during a data transfer, exported them, worked through the ones she could confirm herself, marked which rows were handled and which still needed review, and escalated the remainder with a specific question. Local ownership, informed escalation, problems surfaced without waiting for a scheduled call.
The two risks are consistent. Single-person dependency looks efficient until they resign: portals arrive for audit carrying several hundred workflows, one of them 545 workflows deep, where nobody remaining can explain what the automation does because the people who built it have left. Scope drift is the quieter one, where a hire brought in to fix a structural problem spends most of the week producing ad hoc reports for whoever asks most persistently and never reaches the architecture work.
What to check: whether more than one person can operate your portal, and what percentage of your RevOps hire's week goes to ad hoc reporting.
2. Contractors: capacity, not ownership
A contractor executes defined work well and scales up and down. The problem is that RevOps requirements are rarely as specified as they look, and a meaningful share of the value in any engagement comes from someone questioning the brief.
On a national training provider's implementation, the client wanted a separate company record for each regional branch, which would have replicated the structure that produced duplicate records in their previous CRM. The correct answer was one company record per client with contacts associated to the relevant branch. That is an architecture decision, and it surfaced only because the requirement was challenged rather than built.
Access is the second constraint. On one engagement the client declined super administrator and partner administrator access on certification grounds, which restricted the work until an explicit list of equivalent view and edit permissions had been compiled and approved. That is manageable inside a structured engagement with a documented process. Task-to-task, it tends to end with work stalling for reasons nobody escalates.
What to check: whether anyone in the arrangement is accountable for saying the requirement is wrong.
3. Agency: architecture, and the dependency trap
The case for an agency is pattern recognition. Having configured pipelines across hundreds of businesses tells you which structures fail at scale and which survive a change of CRM owner.
In practice that shows up as a defined process rather than a defined outcome. MO engagements open with a structured kick-off with a dedicated account manager and a set of foundational discovery questions, then two rounds of discovery workshops, with the second reviewing sample exports from the existing CRM or spreadsheets for data hygiene and refining field mappings. The output is a CRM Design Document covering objects, properties, pipelines, views, automation rules and user role permission sets, formally approved before anything is built in the portal, with a second review cycle where changes are required. Deliberately slow at the front so that less has to be unwound at the back.
Experience also buys the ability to reorder a scope. On one engagement, multiple integrations and workflows were writing conflicting values into the same fields with no agreed source of truth. The scope was resequenced so data integrity and deal-to-company-to-contact associations were resolved before anyone touched an automation layer of several hundred workflows. Repairing the workflows first would have felt more productive and achieved very little.
The failure mode is dependency, which is why enablement has to be contracted rather than assumed. On a health benefits engagement, the stated objective was two trained HubSpot champions able to manage the portal independently, supported by four training sessions across the project and a full close-out report and handover package. Two rather than one is the whole point: when the person who understands the portal takes leave, the business continues. On another engagement, two training tracks were built, one for beginners and one for advanced users, because a single session pitched at the average leaves both groups behind.
What to check: whether your agreement names the documentation, training sessions and internal owners you receive at handover.
The mix that works
For most enterprise and growth-led companies, the sequence is:
- Agency for architecture and build, producing a signed-off design document you own as an asset.
- Two internal champions identified from the start, involved during the build rather than trained at the end.
- In-house operations once volume justifies it: hygiene, triage, user management, small changes.
- Retained external support for architecture-level change: a new hub, region, revenue model or integration. Infrequent, high-consequence, cheaper to buy than to keep on staff.
Contractors sit inside step one or three as additional hands. They are a capacity decision, not an ownership decision.
What each option actually costs
The visible numbers, at 2026 rates and ex VAT:
| Option | Typical monthly cost | What that buys |
|---|---|---|
| In-house RevOps practitioner | R40,000 to R70,000 (salary) | Usually two or three of the six functions, not all six |
| In-house head of RevOps | R60,000 to R120,000 (salary) | Leadership and ownership, still one person's capacity |
| Outsourced or retained (agency) | From R45,000; most clients R65,000 to R110,000 | The full function set plus senior architecture, delivered by a team rather than one hire |
A single in-house hire looks cheaper than a retainer until you count coverage. One practitioner typically owns two or three of the six functions of RevOps, so full coverage usually means a second hire, and the salary line does not include recruitment, ramp time, tooling, or the risk of the whole function sitting with one person. A retainer buys the full function set and senior architecture capacity for roughly what one senior hire costs, which is why most enterprise and growth-led companies run a mix rather than staffing all six functions internally. For the full breakdown, including what most clients actually spend and what sits outside the retainer, see how much RevOps costs in South Africa.
The cost that never appears in the budget
Comparing salary against day rates against agency fees misses the cost of getting architecture wrong, which is measurable once someone looks.
On one enterprise portal, remediation involved merging more than 5,000 duplicate contacts and close to 4,000 duplicate companies, resolving formatting issues across more than 98,000 records, consolidating 11 duplicate properties that existed across objects into single authoritative fields, and reducing an accumulated set of super administrators to a documented RACI.
None of that work generated pipeline. All of it was the deferred cost of architecture and governance decisions that were never made.
What to check: whether your cheapest option includes a documented design, or whether you are buying a build and deferring the design cost.
What to look for in a RevOps partner
The single most useful test is whether they diagnose before they recommend. A new CRM does not fix an unclear sales process, another dashboard does not fix inconsistent revenue definitions, and an integration does not repair a data model that was never designed around how the business operates.
The second test is whether they will recommend against their own work. On one enterprise data remediation engagement, the duplicate volume was large enough that native deduplication through export and import was assessed as both painful and genuinely risky, so a specialist third-party tool was recommended instead. On another, a client's request for additional pipeline stages was declined because the existing closed-won and closed-lost statuses were sufficient for the synchronisation those stages were meant to support.
Neither recommendation increased the scope. Both reduced the eventual cost.
MO Agency's methodology is Diagnose. Design. Deliver. The process maps the current revenue system, identifying what exists, what is missing and what is disconnected, before designing the architecture and moving into implementation.
Why MO Agency for Revenue Operations?
MO Agency works with enterprise and growth-led companies to design and operate revenue systems across marketing, sales and service, covering CRM architecture and data governance, process and automation design, systems and data integration, and revenue reporting and forecasting.
The focus is the wider revenue architecture rather than treating CRM configuration as the whole function. For businesses without the internal capability to design or transform that architecture, an external partner can establish the foundations while the organisation takes ownership over time, which is why enablement and ongoing optimisation are part of the engagement rather than a courtesy at the end.
How you resource RevOps is one decision inside a bigger one. See what revenue operations is, how much RevOps costs in South Africa, and our revenue operations service.
Frequently asked questions
Is it better to hire a RevOps person or use an agency?
It depends which work you need. An agency is stronger at architecture and build, an in-house hire at operations and enablement. Most businesses buy architecture as a project and own operations internally, rather than choosing one model for everything.
When should a company hire a RevOps person?
Once there is enough recurring operational work, meaning data hygiene, request triage, user management and small changes, to fill the role. Hiring before that produces scope drift into ad hoc reporting. Hiring to solve a structural problem produces a single point of failure.
How many internal people should be trained on the CRM?
At least two. A single trained administrator is the most common structural weakness found during portal audits. Where handover is treated as a deliverable, the standard is two nominated champions able to operate the portal independently, with documented training.
What should an agency hand over at the end of an engagement?
A design document describing the objects, properties, pipelines, views, automation and permission structures built, a close-out report, and training delivered to named internal owners. Without documentation you have a working portal you cannot safely change.
Can RevOps be outsourced?
Build work, yes. Architecture and ownership, not reliably. A contractor executing task to task has no mandate to say a requirement is wrong, which is where much of the value in an implementation sits.
Should RevOps report to Sales or Marketing?
Neither exclusively. RevOps needs visibility across the revenue organisation because the role is connecting processes, systems and data between functions rather than optimising one department.
Build the RevOps capability your business actually needs
The businesses that resource RevOps well are not the ones spending the most. They separate architecture from operations and resource each appropriately: architecture bought as a project with a documented outcome, operations owned internally by more than one person who understands the system.
The ones that struggle hired a single administrator to fix a structural problem, bought a build without buying the design, or handed a well-configured portal to a team that was never trained to run it.
The decision should follow the diagnosis, not precede it.
Building a RevOps function or trying to determine what your business actually needs? Explore MO Agency's Revenue Operations services.
