Revenue Operations (RevOps) is the function that owns the systems, data and processes shared by marketing, sales and customer service, so that one revenue number can be trusted across all three. It is not a sales support role, a CRM administration role or a reporting role, although it absorbs parts of each. RevOps exists because revenue is produced by three teams operating on one customer, and nobody else is accountable for the seams between them.
That definition is global. What follows is not. RevOps in South Africa operates under a specific set of legal, financial and channel constraints that most published material, written for the United States market, does not account for.
The six functions of RevOps
Every RevOps mandate resolves into six functions. A programme that covers fewer than six is doing part of the job.
| # | Function | What it owns |
|---|---|---|
| 1 | System architecture | The CRM object model, the lifecycle, and what connects to what |
| 2 | Data governance | Field definitions, data standards, record ownership, retention and lawful use |
| 3 | Process design | The workflow that actually happens on the floor, not the one in the documentation |
| 4 | Reporting and forecasting | One revenue number, produced by the system rather than assembled by hand |
| 5 | Enablement and adoption | Whether the people running the process have the means and the incentive to run it |
| 6 | Commercial operations | Quoting, approvals, contracting and the handoff into billing |
Function six is where most South African programmes break, because the handoff runs into an accounting system the CRM does not natively speak to.
The six functions describe what RevOps owns. They do not explain why implementations fail, which is a separate diagnostic: the three hidden pillars of people, process and priorities. Systems, data and strategy can all be clean and the programme still collapses, because those three were assumed rather than checked. Scope is the six functions. Survival is the three pillars. Data governance, function two, is where a single customer view is won or lost.
The seven South African constraints
These are the load-bearing differences. They are why a RevOps design lifted from a US playbook does not survive contact with a South African revenue team.
1. POPIA and the unified customer record. The Protection of Personal Information Act constrains the thing RevOps is usually built to produce. Purpose limitation means data collected for one reason cannot be silently repurposed for another, so merging records across business units needs a lawful basis rather than a technical justification. Section 69 puts consent conditions on electronic direct marketing to non-customers, which changes how lifecycle stages and subscription types are modelled. Data subject requests must be answerable from one place, which is itself the strongest operational argument for a single CRM. Every organisation must have a registered Information Officer, and in practice that person needs to be able to read the record the RevOps function built.
2. Multi-entity and multi-currency revenue reporting. South African businesses commonly trade through two or more legal entities, and frequently invoice in ZAR, USD, GBP and EUR from the same pipeline. If entity and currency are not modelled in the CRM from the first build, pipeline value becomes uncomparable across the business and the forecast quietly stops meaning anything. Retrofitting currency onto a live pipeline is one of the most expensive corrections in RevOps, because historic deal values have to be restated.
3. Platform cost and foreign currency exposure. CRM and marketing platform licences are priced in dollars and paid in rand, so the platform is a material line item that moves with the exchange rate rather than with the budget. Two things follow. Seat and tier discipline becomes a RevOps responsibility rather than a procurement afterthought, because unused seats cost real money every month and the total drifts upward without anyone changing anything. And the size of the commitment removes the option of trying it casually. A platform at this price cannot be bought on a knee-jerk, configured around whoever had capacity that week, and reviewed a year later. If a South African business commits to the spend, the implementation has to be designed properly the first time, because the remediation costs more than the original build and the licence keeps billing throughout.
4. Local quote-to-cash. The finance stack is Xero or Sage, with collections through Netcash, Peach Payments or PayFast. None of these is assumed by international RevOps guidance, and the direction of sync between CRM and accounting system is a design decision rather than a default. Deciding which system owns the customer, which owns the invoice and which owns the payment status is the single most common unresolved question in South African revenue operations.
5. Omni-channel communication, with WhatsApp weighted more heavily than anywhere else. South African commercial communication runs across email, phone, WhatsApp and in-app messaging, and WhatsApp holds a more significant place in business dealings here than in any other major market. It is used between businesses, not only between businesses and consumers, which is where the difference from US-written guidance shows. Two consequences follow. Conversation data lives outside email threads, so the CRM records an activity gap that looks like inactivity while the deal is actively progressing. And mobile number is often a higher-integrity identifier than email address, which inverts the deduplication and record-matching logic imported from US implementations.
6. Procurement and B-BBEE verification as pipeline stages. Enterprise sales cycles in South Africa route through procurement processes and B-BBEE verification that have no equivalent in US-written guidance. If those steps are not modelled as real pipeline stages with their own duration, the forecast systematically pulls in too early, because the deal looks won at the point the commercial decision is made rather than at the point the paperwork clears.
7. Field teams and intermittent connectivity. Sales and service teams working outside metro coverage cannot be held to a capture process that assumes a desk and a stable connection. A CRM requirement designed for an office produces nothing for eleven months and then a year of invented activity data entered in a single sitting. Mobile-first capture is a design constraint here, not a convenience feature.
The MO RevOps Maturity Model
Five stages. Each has a single test, and you are at the earliest stage whose test you fail.
| Stage | Name | The test |
|---|---|---|
| 1 | Fragmented | Marketing, sales and finance each hold their own version of the customer |
| 2 | Consolidated | One CRM holds the record, but reporting is still rebuilt by hand every month |
| 3 | Governed | Definitions, ownership and data standards are named, and lifecycle stages mean the same thing to every team |
| 4 | Operationalised | The process runs inside the system rather than beside it, and the forecast is system-generated |
| 5 | Compounding | Each new build lands on a base people trust, and the system surfaces decisions rather than reports |
Most South African organisations that commission a RevOps assessment are at Stage 1 or Stage 2. The jump that matters is Stage 2 to Stage 3, because it is the only one that is governance work rather than build work, and it is the one that cannot be bought as software.
Three South African RevOps benchmarks
Cost. Retained RevOps in South Africa starts at roughly R45,000 per month, with most programmes running between R65,000 and R110,000 per month. Platform licences, integrations and data work are quoted separately. For the full pricing breakdown, see how much RevOps costs in South Africa.
Time to one trusted revenue number. A single-entity business on a reasonably clean CRM reaches a system-generated revenue number in six to ten weeks. A multi-entity, multi-currency business takes four to six months, and most of the additional time is spent on entity and currency modelling rather than reporting.
In-house cost. A RevOps practitioner in South Africa costs roughly R40,000 to R70,000 per month, and a head of function between R60,000 and R120,000, depending on the size of the company and the scope of operations under management. The relevant comparison is not agency versus hire. It is that one practitioner typically covers two or three of the six functions, which is why the function is usually split.
Who actually holds RevOps in a South African business
In the United States, RevOps is a department. In South Africa it is two or three people, and often one of them holds it alongside another job. The workable division is a CRM administrator in-house who owns day-to-day system integrity, an analyst or finance-side owner for reporting definitions, and retained senior capacity for architecture and sequencing. That split matters commercially: the administration is cheaper to keep internal, and the design is the part that is expensive to get wrong.
The failure mode is assigning all six functions to one person with the means to do two of them. Check whether the owner has the tooling and the authority before adding accountability, because a requirement without the means to meet it produces compliance theatre rather than data.
For how a RevOps programme is scoped, sequenced and priced, see our revenue operations service.
Revenue operations spans more than one decision. For specific angles, see RevOps for B2B SaaS companies, why your sales forecast is wrong, how to measure RevOps success, and building a RevOps team.
Frequently asked questions
What does RevOps stand for?
RevOps stands for Revenue Operations. It is the function that owns the systems, data and processes shared by marketing, sales and customer service, so that revenue reporting is consistent across all three teams.
What is the difference between RevOps and sales operations?
Sales operations serves one team and optimises the sales process inside it. Revenue Operations owns the seams between marketing, sales and customer service, including the shared data model and the single revenue number. A sales operations function can exist inside a RevOps mandate, but not the reverse.
Do we need RevOps if we already use HubSpot?
Yes, and the HubSpot portal is usually the reason. A CRM is the place the function operates, not the function itself. Portals decay through orphaned connections rather than inactive assets, and without named ownership of definitions and data standards a well-configured portal reaches Stage 2 of the maturity model and stops there.
How does POPIA affect RevOps in South Africa?
POPIA constrains how a unified customer record is built and used. Purpose limitation restricts repurposing data collected for another reason, section 69 sets consent conditions on electronic direct marketing to non-customers, and data subject requests have to be answerable from a single source. In practice this makes consent, subscription types and record ownership part of the CRM design rather than a compliance layer added afterwards.
How much does RevOps cost in South Africa?
Retained RevOps starts at roughly R45,000 per month, and most South African programmes run between R65,000 and R110,000 per month. An in-house RevOps practitioner costs roughly R40,000 to R70,000 per month, and a head of function between R60,000 and R120,000, depending on company size and the scope of operations managed.
