Agencies of 50 to 250 people

You are busy and the margin is gone. Those are the same problem.

Independent, non-holding-company agencies at roughly 50 to 250 people, usually with deep category specialisation and no in-house engineering.

An agency at high utilisation with disappointing margin has a process problem. The process converts payroll into delivery faster than it converts delivery into an invoice.

The leak comes in pieces too small to notice: dozens of small requests below any threshold anyone would raise paper for, revision rounds beyond what the statement of work (SOW) sold, and cash sitting in a client accounts payable (AP) portal because an invoice was rejected on a field nobody checked.

On any single job, none of it shows up as a loss. Across the book it shows up as effective rate falling while utilisation holds steady, which is the signature of work being given away by people too busy to log it.

300 to 600 hrs
Absorbed per year on a single $400K retainer, from small requests nobody logs. A quarter to half of one full-time employee.

Agency scope-management practice

30 to 60%
Share of concept-through-final labour consumed by revision rounds three onward, past what a two-round SOW sold.

Agency estimating benchmarks

$68,000
Cash tied up per day of days sales outstanding (DSO) at $25M AGI. Portal rejections are the largest avoidable component.

Agency finance benchmarks

Three places this pays for itself first.

Each one is fixed scope, ships in weeks, and either recovers money already earned or removes the thing blocking the work after it. Start wherever it hurts most. None of them requires you to sell more or change what you do.

01

Client AI-Permission Register

What breaks

Clients are writing AI clauses into master service agreements (MSAs) now: no-training guarantees, disclosure requirements, named model restrictions, audit rights. The rules live in contract PDFs, and the decisions get made by a copywriter at 9pm choosing which tool to open. The answer to "can we use AI on this account" depends on who you ask.

What gets built

Extract each client's AI restrictions from the executed MSA and SOWs into structured fields on the client record: permitted providers and tiers, whether confidential material may be entered at all, whether output may reach production, whether disclosure is required, who signed off. Then surface those fields as a blocking check inside the tools where the work happens. In a contracts folder they reach nobody.

What already solves this

Nothing sells this. Data loss prevention gateways block domains but have no concept of a per-client rule, because they do not know which client a piece of work belongs to. Enterprise AI tenants give you the no-training terms and the audit log, but enforce one policy per tenant. Contract lifecycle tools extract clauses and stop at the repository. The register sits between four systems, which is why it does not exist.

Opens onto: A governed AI workspace with provenance logging, an approved-tool register, and then every downstream build with a defensible answer to "whose consent covers this".

MSASOWPERMISSIONREGISTERAI-ASSISTED STEPACCOUNT AAI permittedACCOUNT Bno AI clause
Clauses become fields. Fields gate the work, per client.

Every other AI project

Depends on this existing first. It is the consent gate the rest of the work has to clear.

Client confidentiality and data handling practice

02

Out-of-Scope Capture and QBR Evidence

What breaks

The resize. The stat update. The one-off deck for a sales meeting. Each is 20 to 90 minutes, each sits below any threshold worth raising paper for, and refusing any single one looks petty. In aggregate they consume the account. The absorption is survivable. The problem is that nothing records it, so the consumption figure does not exist and the conversation cannot be had with data.

What gets built

Instrument the channel requests arrive through, detect the ones that never became a task or a time entry, and produce two artefacts: a weekly candidate list for the account lead, and a quarterly pack showing planned versus delivered hours by workstream with every absorbed request itemised.

What already solves this

Your professional services automation (PSA) platform tracks time against jobs and will tell you the job overran. It cannot see a request that never became a task, which is the whole population that matters here. Intake products work well for clients trained to use a front door and do nothing for the account that texts the account director. The unbuilt piece is passive detection on an unstructured channel, joined to what the SOW sold.

Opens onto: Change-order drafting that writes back to the budget and the resource plan, and then an estimating library built from your own closed-job actuals.

SLACK CONNECTSHARED INBOXSTATUS CALLBECAME A TASKPSA sees itDELIVERED,NEVER LOGGEDCAPTUREQBR EVIDENCEby workstream
The dotted box is the population your PSA cannot see.

22%

Once a client sees this share of hours went to items outside the SOW, the conversation shifts from whether to how.

Agency scope-management practice

03

Invoice Pre-Submission Validator

What breaks

Enterprise clients transact through Coupa, Ariba, Tungsten and proprietary portals that reject on mechanics: no valid open purchase order (PO), a PO consumed or expired at fiscal year end, line structure that does not match how the PO was written, a match-tolerance breach, a missing cost center. The rejection is silent or lands in a shared mailbox, so you find out 45 days later while chasing payment.

What gets built

Build the client billing profile as structured data (PO and remaining balance, portal, required fields, line structure, remit-to entity, backup format, submission deadline), machine-check every invoice against it before submission, and block the ones that will bounce. Pair it with a watcher on the rejection mailbox so a bounce is known in hours.

What already solves this

Accounts receivable (AR) automation platforms handle collections sequencing and dunning, and predicted-pay-date modelling is a headline feature. That half is a solved commodity and you should buy it rather than build it. What none of them do is pre-check an invoice against a specific client portal's field requirements before you submit. E-invoicing networks validate at the receiving end, which is the rejection this prevents.

Opens onto: Dispute reason-code mining, which pushes the fix upstream into the SOW and the PO process instead of into more collections effort.

INVOICEfrom PSANO CHECKREJECTEDPO consumed.Found day 45.VALIDATORPO balanceline structurecost centerACCEPTEDPaid on terms.
Same invoice, same work. One field decides which path it takes.

Most disputes

Are administrative. Nobody is arguing about the work, which is why a check at pre-bill is worth more than any amount of chasing.

Agency billing and AR practice

I know the shape of this. I don't know your version of it.

These are the questions that decide whether any of the above is worth building at your firm, and they get asked before anything is scoped. Several of them can kill the project, which is the point.

  1. Which channel do small client requests arrive through, and what share arrives verbally on a status call?
  2. Does the MSA on your largest accounts restrict AI processing of client communications?
  3. Is there a scope baseline in the PSA that reflects the SOW's own hours model, or was the project set up from the invoice value?
  4. What is current DSO, and what share of invoices are rejected on first submission?
  5. How many distinct AP portals do you submit to?
  6. Is the contracted revision-round count written into SOWs today, and is a round defined?

A first win buys the right to the bigger one.

Start here

One of the three above. Fixed scope, delivered in weeks, and it either recovers money you already earned or removes the thing blocking you from saying yes to AI work.

Then the loop that produced it

Round-count instrumentation, change-order automation that writes back to budget and resource plan, an estimating library derived from your own actuals rather than from memory.

Then the pricing question

Cost-per-deliverable history is the prerequisite for output-based pricing, which is the most achievable defence against a procurement productivity clause. You cannot set an output price without it.

Every figure on this page comes from industry research. None of it comes from my own engagements. I have not put a client's results here, because I am not going to dress up someone else's benchmark as my track record. When there is a delivered number worth showing, it will appear here with the client's name on it or not at all.