Operations & Systems

Operations and systems: process, KPIs, CRM, training, and automation

Operations and systems work covers the operating backbone of the business: how work moves, which numbers run it, the CRM that records it, the training that makes the habits stick, and the automation that carries the repetitive parts. It is organised in five areas. Each one is scoped and quoted separately, and each can stand alone.

The five areas

The five groups follow a sequence worth reading in order: structure and process first, then the measures that read it, then the system that holds the record, then the training that keeps the record honest, then the connections between systems. Each group names what it covers and the deliverable that ends it, so you can see where a scope would start.

01

Business structure & processes

How the business is organised, where work crosses between teams, and what is written down rather than remembered.

  • Operational consulting — structure, decision rights, and the handoffs between sales, delivery, and finance
  • Process improvement — the steps work actually takes, the rework and bottlenecks inside them, and the order to fix them
  • SOP documentation — departmental procedures and playbooks written with the people who do the work
  • Business continuity & change management — what the business relies on, what happens when a key person or system is unavailable, and how change is sequenced

Deliverable: A current-state map, a prioritised change list, and the documented procedures.

02

KPIs & performance systems

The few measures that run the business, how each is defined, and where they are actually reviewed.

  • KPI definition — the small set of measures that predict the outcome, each with one agreed definition
  • Dashboards and data sources — where each number comes from, and what happens when two reports disagree
  • Operating cadence — the reviews that use the numbers, with an owner and a follow-up for each item

Deliverable: A metric definitions sheet, the dashboards, and the review agenda.

03

CRM strategy

The system of record for pipeline and customer history, architected around how you sell rather than around a template.

  • CRM strategy & implementation — pipelines, fields, ownership, and reporting designed against your sales motion
  • CRM audits — a structured review of what the account already contains, findings ranked by what to fix first
  • CRM dashboards — metrics that agree with each other, so leadership and the team read the same numbers
  • Workflow optimisation — overlapping or conflicting automation untangled before anything new is added
  • Ongoing administration — an agreed monthly scope of configuration upkeep, logged so the system stays explainable
  • Platform-specific configuration — work on Zoho, HubSpot, or Salesforce sits inside these same scopes rather than in a separate menu

Deliverable: A scoped configuration change with written findings and an admin log.

04

Training & adoption

The habit layer: what each role records, when they record it, and how managers review it afterwards.

  • CRM training & adoption — role-based sessions run in your own account, written playbooks per role, and a review cadence for managers
  • Adoption measurement — usage, data completeness, and stage adherence read against your own baseline rather than a benchmark

Deliverable: Role playbooks, a documented process, and an adoption baseline with three reports.

05

Integration & automation

How the tools pass data to each other, what is worth automating, and what keeps the moving parts running.

  • Systems integration & automation — a map of the systems and data flows, then the integrations and automations worth building
  • Custom software & application development — built where an off-the-shelf tool genuinely does not fit the work
  • AI tools & business automation — narrow, reviewable uses of automation and AI, with a person accountable for the output

Deliverable: A systems map, the built integrations, and documentation of what runs and who owns it.

Where a first scope tends to come from

The situations below are illustrative and hypothetical. They describe patterns these scopes are built to address; they are not client accounts, and no outcome is promised.

The first maps to process and documentation, the second to KPI definitions and CRM reporting, the third to integration. Buying software alone can leave the process and the ownership of it unresolved, which is why the scope is written before anything is purchased.

When this work fits, and when it does not

A fit when

  • The business has outgrown the way it is held together, and decisions sit with too few people.
  • Processes exist but are undocumented, so consistency depends on who is doing the work.
  • Reports disagree with each other and nobody can say which number is the real one.
  • A CRM is in place and either underused or worked around.
  • Tools are bought but not connected, so work is duplicated between them.

Not the right scope when

  • The business needs a full-time operations leader rather than a scoped engagement — a fractional COO conversation comes first.
  • You want a tool recommendation without defining the process it has to support.
  • You are looking for staff replacement rather than documented, transferable process.
  • A platform migration is already committed and underway; sequencing that first is the better decision.

How an engagement runs

01 · Diagnostic

Diagnostic

The current state, established from evidence: the process as it runs, the systems in use, the numbers leadership trusts, and where those three disagree.

02 · Scope

Scope

One area written up as a scope: what changes, what it depends on, what it deliberately excludes, and the price for that scope.

03 · Design

Design

The target process or structure agreed on paper before any system is touched, so configuration follows a decision rather than standing in for one.

04 · Build

Build

Documentation written, systems configured, integrations connected — in the sequence the scope sets.

05 · Train & measure

Train and measure

Roles trained in the real system, then measured on usage, data completeness, and adherence to the documented process.

06 · Handoff

Handoff

What changed, what now runs on its own, what needs an owner, and what was deferred to a separate decision.

The operations scopes in detail

Talk through an operations scope

Request an operations review, or describe the constraint first

A first scope starts from the process or system that is causing the most friction. Describe the situation in plain terms and we will say which of the five areas it belongs to, and whether it needs a scope at all.

Operations and systems: common questions

Where should operations work start?

With the constraint that is actually costing the business, judged from evidence rather than from a preference for tools. Three starting points cover a lot of cases: work that only one person knows how to do, reports that disagree with each other, or a system the team works around instead of in. Any of the three is a legitimate first scope.

Is this consulting, or do you also do the implementation?

Both, in the same scope. A recommendation nobody builds is a document; a build with no agreed design is a change nobody agreed to. Each scope states what is being designed, what is being built, and what is being handed over.

What does operations and systems work cost?

Each area is quoted per scope before work starts. The figure depends on the size of the process or system involved, how many roles it touches, and whether documentation has to be written from scratch. No rate card is published here because scope varies; you get a written number to approve first.

Do we have to change CRM platform?

No. Platform configuration work is scoped inside the CRM area on whatever system you already own, and the subscription stays yours. A platform change is a separate strategic decision, and it is not required to fix pipelines, fields, or reporting.

What happens to the systems and documentation after the engagement?

Everything built in a scope is handed over: the documented procedures, the configured system, the definitions sheet, and the admin log. Where ongoing administration is wanted, it is a monthly scope with an agreed cadence rather than open-ended support.

Do you guarantee a result?

No. What is guaranteed is the deliverable: the documented process, the configured system, the training, and the measurement. Business outcomes depend on adoption and decisions made inside the business, and those are not things a consulting scope can promise.

Start the Conversation

Bring us the opportunity, challenge, or next step. We'll start by understanding where you are, where you want to go, and what it will take to get there.