Professional Services

One record, from the first email to the last invoice.

The enquiry is in one system, the project is in another, the time is in a third and the invoice is in a fourth. We put the engagement on one record, then let the system do the drafting and the comparing that nobody has time for.

  • Enquiry to proposal
  • One record to invoice
  • Delivery reporting
  • Pricing kept human

The margin leaks between the systems, not inside them

Every one of these is a place where two facts about the same engagement live in two places and nothing brings them together while there is still time to act. Six patterns turn up in almost every firm we map.

The enquiry lands in one person's inbox and stays there

It arrives by email, by referral, through the website and through a partner nobody told. Whether it becomes an opportunity depends on how busy that person was on the day it came in.

A pipeline that describes who is organised rather than what is real.

Every proposal is written from scratch

The firm has delivered the same shape of work a dozen times and none of that reaches the next scope. Somebody rebuilds the phases, guesses the effort and prices it from memory of the last one.

Two days of senior time per proposal, and a scope nobody can check.

The estimate and the actual never meet

The project was quoted at 240 hours and took 290. Both numbers exist, in two systems, and nothing brings them together while there is still time to do anything about it.

SPI Research put average project overrun at 10.7 percent in 2025.

Time gets recorded from memory

Consultants fill timesheets on Friday for a week they half remember, which is the point at which the short tasks stop existing and the long ones get rounded.

Billable utilization fell to 66.4 percent in 2025, the lowest SPI has recorded in nineteen years.

Nobody can say why the firm lost that one

The bid went in, the client went quiet, and the reason lives in a conversation somebody had on a call. SPI put the average bid-win rate at 48.1 percent, so roughly half of all that effort produces nothing anyone learns from.

The same losing bid, submitted again next quarter.

Resourcing is a spreadsheet somebody rebuilds on Mondays

Who is available, from when, and at what utilization is a question the firm answers by asking around. On-time delivery sat at 73.8 percent in 2025 against a five-year average of 76.

Work promised on capacity the firm did not have.

The four benchmark figures above are from SPI Research's Professional Services Maturity Benchmark, which surveys more than 500 firms. They are here to say that these are industry conditions rather than a problem with your firm. What they cannot tell you is which of them is costing you the most, and that is what the mapping is for.

Give the system the assembling and keep the commercial call

Controlled delegation is the whole design, and everything below this band is an application of it. Repeatable work goes to the system. What the client pays, what the firm commits to and what the client is told goes to a person.

  • 01

    The same work arrives again

    An enquiry, a scoping call, a proposal, a project set up from that proposal, a timesheet and an invoice. The same six shapes, on every engagement, assembled by hand each time.

  • 02

    The system carries the record between them

    Reading an enquiry, matching it to a company you already have, scoring it against your own rules, pulling the engagements it resembles, drafting a scope and setting up the project from what was agreed. None of it is judgment.

  • 03

    People price it, sell it and deliver it

    The fee, the commercial terms, whether to bid at all and what the client is told are decisions with risk and relationship in them. They reach a person with the work already assembled.

See it run

An enquiry becomes a scoped proposal on one record

The enquiry gets matched to the CRM, checked against the work the firm has already done, qualified against the firm rules and scoped from the service catalogue. The fee is left for a partner.

Enquiry to Engagement
  1. Input
  2. Context
  3. AI work
  4. Action
  5. Approval
  6. Recorded

Connected systems

  • Website and email Enquiry capture updated
  • CRM Organizations and opportunities updated
  • Service catalogue Scope and effort patterns updated
  • Knowledge base Past engagements updated
  • Proposals Documents and terms updated
  • Project management Delivery setup updated

Enquiry Halcyon Utilities Operating model review

  1. Enquiry received Contact form plus a two-page brief
  2. Organization matched Two prior conversations, no engagement
  3. Past work searched 3 comparable engagements in the same sector
  4. Service matched Operating model review, 6 to 9 weeks
  5. Brief read and structured Objectives, constraints, decision date
  6. 6 of 6 qualification rules met Sector, size, budget signal, timing, access, fit
  7. Scope drafted From the three comparable engagements
  8. Effort estimated 34 to 41 consultant days, banded not fixed
  9. Opportunity created Stage, owner, decision date, source
  10. Proposal drafted Scope, approach, team, assumptions
  11. Fee left empty Price is not a system decision here
  12. Delivery shell prepared Held unpublished until the work is won
  13. Held for a partner The fee and the commitment
  14. Run recorded Rules applied, sources cited, estimate basis stored

Result

Proposal ready to price Everything a partner needs to set a fee, without the four days of gathering.
  • CRM relationship Prior contact
  • Comparable work 3 engagements
  • Qualification rules 6 of 6
  • Effort estimate 34 to 41 days
  • Fee Not set
  • Days to proposal Same day

Completed automatically

  • Opportunity created in the CRM
  • Three comparable engagements attached
  • Scope drafted from past work
  • Effort banded with its basis
  • Proposal drafted, unpriced
  • Delivery shell prepared

Requires a person

The fee, and whether the firm wants this work.

Engagement partner

Price and sendRevise scopeDecline
View audit trail
  • 11:20 Enquiry received. Source: website form with attachment.
  • 11:21 CRM matched on domain. Two prior conversations attached.
  • 11:21 Qualification rules 1 to 6 applied. Rule set version 7.
  • 11:22 Effort estimate derived from 3 named engagements. Basis stored with the estimate.
  • 11:22 Fee field left null by policy. Held for the engagement partner.
6 actions completed 3 systems updated 2 exceptions 1 approval

This demo uses fictional data. The workflow gets configured around your systems. Build a workflow like this

Four workflows, and the order they usually go in

The order matters more here than in most sectors. The record comes before the reporting, because a system cannot compare an estimate to an actual until both are attached to the same engagement.

Revenue

Enquiry to scoped proposal

The first draft written from work you have already delivered

Reads the enquiry, matches it to the company already on record, scores the fit against your own written rules, pulls the engagements that resemble it with their actual hours rather than their quoted ones, and drafts a scope with the assumptions stated as assumptions. The fee field stays empty.

  • Scores against your rules size, sector, budget and the problem you sell against
  • Cites real engagements hours as delivered, not as originally quoted
  • Leaves the price to a person a comparable says what it took, not what to charge
How a workflow gets built

Data: enquiries, your CRM and your delivered engagements. Human: a partner prices it and approves the scope.

Operations

One record from enquiry to invoice

The four systems that hold one engagement, joined up

The enquiry, the opportunity, the project, the time and the invoice on one record with one reference. This is the unglamorous half of the work and it is the half that decides whether any of the rest is possible, because a workflow can only compare an estimate to an actual if the two are on the same object.

  • One reference, carried through from the first email to the final invoice
  • Estimate and actual on one record compared while the project is still running
  • Scope changes recorded as changes so the overrun has a cause attached
How the record gets built

Data: your CRM, project system and accounting. Human: project leads own the scope and the change.

Operations

Delivery reporting that writes itself

The status report as a by-product of the work

Progress, hours, budget position and open risks assembled from the systems the project already runs in, drafted into the format the client expects and the format the partner expects. Two audiences, one set of facts, neither of them retyped.

  • Assembled from the project record rather than from a call with the project manager
  • Two versions, one truth the internal read and the client read stay consistent
  • Risks carried forward an open risk stays open until somebody closes it
How a workflow gets built

Data: project, time and budget records. Human: the project lead approves anything the client sees.

Insight, later

Which work is worth doing again

Margin, win rate and overrun, by the thing that causes them

What the firm actually makes by service line, by client type and by who sold it. Which enquiries convert and which ones the firm should stop bidding for. This one comes last because it stands on the record the second workflow builds, and it is worthless before that exists.

  • Realised margin by service line after the write-offs, not before them
  • Win rate by source which referrers and which channels send work you win
  • Overrun traced to a cause scope, estimate, resourcing or client behaviour
How the data layer gets built

Data: your own delivery and financial records. Human: partners decide what the firm stops selling.

Most firms want the fourth one and have to buy the second one first. Margin by service line is the report every partnership asks for, and it cannot be produced honestly until the estimate, the actual, the change and the write-off are on the same record. A dashboard built before that is a picture of four systems disagreeing.

Six decisions taken before anything is built

These get agreed with the partners and whoever owns IT before a build starts, and between them they decide what the workflow is allowed to be. Two of them are about your clients rather than about you.

Client confidentiality
Which client material a workflow can see, what stays masked, and which engagements are excluded entirely because the client contract says so. Some of your clients have signed you up to terms that decide this for you.
Qualification rules, in writing
What the firm counts as work worth bidding, written down and versioned. The value of a rule is that it can say no to something attractive, which only works if it exists before the attractive thing arrives.
Pricing and commercial terms Kept human
The fee, the payment terms, the liability position and whether to bid at all. These stay with a person on every engagement, on every workflow on this page, without a value threshold underneath them.
Access model
Who can see margin by engagement, who can see it by consultant, and who can see neither. In a partnership this is a more sensitive question than most data questions, and it is better settled early.
Audit trail
What was scored, on which rule version, what was cited, what was drafted and who approved it. Enough that an override can be reviewed later and the rules improved because of it.
Escalation path
What happens when an enquiry cannot be scored, a comparable does not exist, or an estimate and an actual diverge past a threshold. A workflow with no escalation path escalates to whoever notices.

What counts as working. Accepted output against your own baseline is the proof. The baseline gets taken before the build exists, and afterwards the same work is measured against it with the review burden counted openly, because a system that produces plenty and has to be checked twice has saved nothing. How we measure AI work sets out the method.

The record first, then the workflow on top of it

This sector is the one where the order is worth stating plainly, because the thing most firms want to buy sits on top of the thing most firms have not built.

Map the work
Two to three weeks. How enquiries, proposals, delivery and billing actually run, where the margin leaks, and the candidates scored by value and readiness so the first move is an evidenced choice. This is FusionMap.
Build the record
Five to nineteen weeks depending on scope. One record from enquiry to invoice, because the reporting and the workflows above it are not possible until an estimate and an actual sit on the same object. This is Systems Build.
Build one workflow
Four to six weeks. One workflow on top of that record, tested against the baseline agreed at the start, usually the proposal draft because it is the one senior people feel immediately.
Train and operate
Ongoing. Into daily use with the team trained to run it, reviewed against the baseline, then the next workflow if the first one earned it.

Where this has already been built

The approach on this page comes out of these engagements. One is a professional firm mapped end to end, and three are the design patterns the workflows above are built on.

A digital readiness audit for a law clerk firm

A professional services firm running on standalone databases that did not talk to each other, with document handling done by hand. We audited the operation, mapped the gaps and built a four-pillar roadmap the firm could take to any implementer.

4 pillars documents, workflow, data, reporting Sequenced with platforms and budget against each
Read the case study

A client profiling engine with the approval kept human

An intake questionnaire becomes a profile, a classification and a recommendation document, with the scoring on fixed rules and every output waiting in an approval queue. The same design as the proposal workflow above: drafted by a system, released by a person.

Under 5 min form to a review ready file 8 weeks concept to a deployed platform
Read the case study

Research that arrives before the call

Territory research a team used to do by hand now lands every morning without anyone triggering it. The pattern behind the enquiry workflow: gathering a person would do badly at nine in the evening, done before the day starts.

550+ districts researched per territory 3 agents kept running and updated
Read the case study

AI enablement across an investment management firm

A phased program that put capability ahead of deployment: role-based training first, then pilots in research, client engagement and reporting, then the roadmap to scale it. A professional firm learning to supervise the work rather than just run the tool.

3 phases train, pilot, then roll out 6 months to enterprise rollout
Read the case study

Begine Fusion is a Zoho Authorized Partner working across Canada, the United States, the United Kingdom and Nigeria, with a team on the ground in Nigeria since 2013. Every engagement is published in full, including what was measured and what was a design target. The full set is on our work.

Whether this is the right conversation yet

The work pays back when the firm is big enough that nobody holds the whole picture in their head any more. If that is not where you are, the right column says what to do instead.

This fits if

  • Enquiries arrive through more than one door and no single place holds all of them
  • Proposals are written from scratch when the firm has delivered that shape of work before
  • You can find an estimate and an actual for the same project, in two systems, that do not agree
  • Partners are asking for margin by service line and nobody can produce it honestly
  • Somebody in the firm can own the qualification rules, because writing them down is most of the value

Start somewhere else if

  • You do not yet know where the margin goes. Go to FusionMap and find out before commissioning a build.
  • Consultants are already using AI on client material and there is no written position on it. That is FusionGuard, and it costs less than the build it governs.
  • The firm is small enough that one person genuinely holds the whole pipeline. Come back when that stops being true, and it will.
  • Nobody is looking after the systems you already have. Go to Managed Operations.

Start where the problem is

The same five offers every other client buys, scoped to a firm that sells time and has to know what it cost. Find the line that sounds like yours.

The firm is busy, the margin is thinner than it should be, and nobody can say which engagements did it

FusionMap

Enquiries, projects, time and invoices live in four systems that do not agree

Systems Build

One workflow is defined, agreed, and ready to be built properly

FusionBuild

Consultants are already using AI on client work and nothing is written down about how

FusionGuard

The systems went in, they work, and nobody has looked after them since

Managed Operations

Your people have to supervise what a system produces, not just operate it

AI Systems Mastery

No price is quoted on this page. A sector is not an offer and does not have a price of its own. What a firm here pays follows which of those six lines is the real one and how much of the record already exists. Working out which line is yours is what the first call is for.

Asked on every call with a firm

The seven that decide whether a build is worth starting, answered before the proposal rather than inside it.

Does the system price our work?

No, and it is built so that it cannot. A comparable engagement tells you what work of that shape actually took. It says nothing about what this client should pay, because that is a judgment about risk, relationship, appetite and what else is in the pipeline. The fee field on a drafted proposal is empty and stays empty until a person fills it in.

We already have a CRM and a project system. Do we replace them?

Usually not. The common problem is that the two hold different versions of the same engagement and nothing reconciles them, which is a connection problem rather than a software problem. If the mapping finds a system that genuinely cannot carry the work, we will say so and give you the reasoning rather than a recommendation.

What about the confidentiality terms our clients hold us to?

Some of your client contracts already decide what tooling may touch their material, and those terms win. Which engagements are in scope, which are excluded and what stays masked are settled before the build, written down, and shown to a client who asks. We would rather scope a smaller workflow than one you cannot describe to your largest client.

Our consultants will not fill in timesheets. Does this fix that?

It reduces the problem rather than solving it. Time captured against a record that already knows what the person was working on is a correction rather than a reconstruction, and that is a different task on a Friday afternoon. What it will not do is make people record work they have decided not to record, and any partner who has run a firm knows the difference.

Can it tell us which work to stop selling?

It can show you realised margin by service line and by client type, after write-offs rather than before them, and win rate by where the work came from. Most firms find at least one service line that looks profitable at the quote and is not at the invoice. What to do about that is a partnership decision, and it usually involves more than the numbers.

How do we know it worked?

A baseline is taken before the build exists: current time to a proposal, review effort, rework, and the gap between estimate and actual on the work in question. Afterwards the same work is measured against it with the review burden counted openly, because a system that produces plenty and needs checking twice has saved nothing.

How long before anything is running?

The record usually comes first and runs five to nineteen weeks depending on how many systems come into scope, sequenced so something is live well before the end. A workflow on top of it is four to six weeks. Ahead of both sits the mapping, which is two to three weeks and produces a decision you can act on whether or not we do the build.

Bring the engagement that made money on paper and not in the ledger

Thirty minutes with a partner, whoever runs delivery and whoever owns the numbers is enough to name the first workflow, the record it needs underneath it, and the baseline it gets measured against.