Ten kinds of work, organised around what is actually wrong.

Most revenue operations were never designed. They accumulated. A tool bought for one campaign, a process invented to work around a limitation, a report built for one board meeting that became the number everyone quotes. Individually each decision made sense. Together they produce a machine nobody understands end to end.

We start by writing down how revenue is actually produced today, then agree what the operating model should be: who owns which stage, what the definitions are, which system is the source of truth for what, and how the teams hand work to each other. The technology work follows from that, and it is usually smaller than clients expect.

Typically includes

• Operating model and ownership map
• Revenue process design end to end
• Shared definitions across marketing, sales and success
• Team structure and RACI
• Systems and data source-of-truth decisions
• Sequenced change roadmap

We go through the CRM, the marketing automation platform, the integrations, the processes around them, the data underneath and the reporting on top. Then we tell you what is broken, which parts of it matter, what each one is costing in time or lost revenue, and what we would fix first.

The output is a written assessment rather than a workshop summary. Plenty of clients take it and act on it with their own team, which is a perfectly good outcome. It is also the cheapest way to find out whether you want to work with us on anything larger.

Typically includes

• CRM and marketing automation review
• Integration and data flow assessment
• Data quality and governance findings
• Process and handoff gaps
• Reporting and metric integrity check
• Prioritised remediation roadmap

This is the work where independence matters most, so it is worth restating: we hold no partner status, resell no licences and take no commission from any vendor. Whichever platform you end up on, our fee is the same.

Selection starts from requirements you can defend. What the business model demands, which processes have to be supported and which are negotiable, what your data looks like, which systems have to connect, who will administer the platform internally and what they can realistically maintain, the budget over three years rather than one, and the growth you are planning for. Then we score the shortlist against that, run the demos with your questions rather than the vendor's script, and write up the recommendation with its trade-offs stated plainly.

Typically includes

• Requirements definition and weighting
• Shortlist and structured scoring
• Demo scripts built from your processes
• Total cost of ownership over three years
• Migration and effort assessment per option
• Written recommendation with trade-offs

CRM strategy, architecture, implementation and enablement, in that sequence. We design the object model and the processes it has to carry before anything gets configured, because the alternative is a system that matches the specification and not the business.

Rollout is treated as part of the build rather than a phase at the end. Role-based enablement, a realistic view of what each team gains from using it properly, and a first quarter of measurement to catch the parts of the design that did not survive contact with real work.

Typically includes

• Data model and object architecture
• Pipeline, stage and lifecycle configuration
• Automation, triggers and alerts
• Integrations to the rest of the stack
• Permissions, security and governance
• Role-based enablement and documentation

Migrations rarely fail on the export. They fail on data that was never clean, on process differences nobody surfaced until go live, and on a team that was told about the change two weeks beforehand. We plan for those three.

Consolidation after an acquisition, or after years of separate business units buying their own tools, is the same work with an extra layer: deciding whose definitions win. That is a commercial decision rather than a technical one, and it is better made deliberately than by whoever migrates last.

Typically includes

• Migration plan and cutover sequence
• Field-level data mapping
• Data cleansing and deduplication
• Workflow and integration rebuild
• Validation, reconciliation and test cycles
• Rollout, training and hypercare

Two hundred custom fields, forty of them used. Three pipelines that mean the same thing. Automation somebody built four years ago that still fires and nobody will turn off. Sales working from a spreadsheet because the CRM asks for twelve things they do not have at that point in the conversation.

Rebuilding is mostly subtraction. We work out which parts of the system reflect how the business actually operates, remove the rest, and redesign what is left around the way the team works now rather than the way it worked when the CRM was first configured. Adoption tends to follow on its own once the system stops asking for things nobody has.

Typically includes

• Usage and adoption analysis
• Field, object and automation rationalisation
• Pipeline and stage redesign
• Data cleanup and deduplication
• Simplified interface and required-field policy
• Re-enablement for the teams who stopped using it

This is the design work that makes a CRM configuration possible in the first place. What the stages are, what a record has to satisfy to enter and leave each one, who owns it while it sits there, what should happen automatically and what should stay a human decision, and which number tells you whether the stage is working.

Done properly it settles arguments that otherwise recur every quarter, because both teams agreed the definitions in advance rather than after a bad month.

Typically includes

• Customer journey mapping, acquisition to renewal
• Lifecycle stage definitions with entry and exit criteria
• Stage ownership and handoff points
• Trigger and automation design
• Marketing automation programme design
• Stage-level KPIs and conversion targets

Qualification criteria that a human can apply consistently, scoring built on behaviour that actually correlates with buying rather than on whoever opened an email, routing rules with response times attached, and sales stages defined by what has been proven rather than by how the rep feels about the deal.

The handoffs get the same treatment. Marketing to sales, sales to customer success, and the return path when a customer needs to go back to marketing. Each one with a named owner, an agreed trigger and a service level, because the gaps between teams are where most pipeline is lost.

Typically includes

• Lead management process end to end
• Qualification framework
• Lead scoring model
• Routing rules and response SLAs
• Sales stages with exit criteria
• Handoff definitions and ownership

Reporting problems are almost never reporting problems. They are definition problems and data model problems that only become visible in a dashboard. So we start with the definitions, agree them across the teams who will be measured by them, then check the data model can actually support them before anyone builds a report.

After that: the reports themselves, pipeline management and forecast method, attribution where it is worth having and an honest note where it is not, and a small set of numbers leadership can act on rather than a dashboard nobody opens twice.

Typically includes

• Metric and KPI definitions
• Reporting framework by audience
• Pipeline management and forecast method
• Attribution model
• Data model changes needed to support it
• Dashboards and report build

Connecting the CRM to the rest of the systems that touch a customer, deciding what synchronises in which direction, and removing the tools that duplicate something you already pay for. Automation gets designed rather than accumulated, with a clear view of what should stay manual because a person needs to make the call.

Some clients keep us on afterwards for a set number of days a month: reviewing what changed, keeping data quality from drifting, building the next thing on the roadmap, and being available when something breaks. No retainer is required to work with us on a project.

Typically includes

• Integration architecture and build
• Technology stack rationalisation
• Workflow and trigger automation
• AI use cases where they earn their cost
• Data quality monitoring
• Ongoing optimisation and support