Fixed-fee and retainer work can look profitable at the start of a project and quietly become much less profitable by the end. The culprit is often not one dramatic change. It is the steady drip of small requests that seem harmless in isolation.
A client asks for an extra report. A stakeholder wants another round of amends. Someone adds a new audience, channel, feature, branch, location or meeting. The account manager says yes because the relationship matters and the request sounds reasonable. Weeks later, the team is over budget and nobody has a clean record of what changed.
For consultancies, agencies and professional service firms, that is a margin problem as much as an admin problem.
The paper trail is usually created too late
When a client disputes a bill or a project overruns, account managers often have to go back through emails, Slack threads, meeting notes and old documents to work out what happened. That retrospective archaeology is slow, frustrating and incomplete.
The original scope of work might clearly define what was included, but the day-to-day conversation often lives somewhere else. If out-of-scope requests were agreed informally, it can be difficult to show the difference between “included in the retainer” and “additional work we absorbed without recording it”.
This is where a simple AI-assisted workflow can help. Not by arguing with clients, and not by automatically sending change requests, but by quietly building the internal evidence trail as the project happens.
An example AI-assisted workflow
Here is a practical example. This is not a real case study or a claim about a client result; it is an example workflow for a consultancy or agency that wants better control over scope creep.
For each active project, an assistant has access to the original scope of work document and a defined set of project communications. That might be a shared inbox, a project email thread, or a designated Slack channel export. The assistant is not reading every private message in the business. It is limited to the agreed project sources.
As new messages arrive, it looks for requests that may fall outside the known scope. For example:
- a client asks for a new deliverable that was not listed in the proposal;
- a stakeholder requests extra rounds of review beyond the agreed process;
- the project is asked to cover an additional location, audience or channel; or
- the client asks for work to be accelerated in a way that changes the resource plan.
When the assistant spots a possible scope change, it creates an internal draft entry. That entry includes the date, requester, source message, relevant excerpt from the scope document and a suggested classification such as “possibly out of scope” or “needs account manager review”.
What the change-log might contain
The output is not a formal client-facing change request. It is a running internal change-log, ready for an account manager to review.
Each entry might include:
- the new request in the client’s own words, quoted from the source message;
- the date and channel where it appeared;
- the person who requested it;
- the original scope clause it appears to exceed;
- a suggested in-scope or out-of-scope classification; and
- a space for the account manager’s decision.
That last point is important. The assistant proposes candidates. The account manager decides. Some items will be commercially sensible to absorb. Some will be misunderstandings. Some will deserve a formal change request. The value is that the decision is visible rather than buried in a message thread.
Why quoting the source matters
For this workflow, the assistant should quote the relevant client message rather than paraphrase it. Paraphrasing can accidentally make a request sound stronger, softer or clearer than it really was. If an item may later support a commercial conversation, accuracy matters.
The same applies to the scope document. The assistant should show the clause it is comparing against, not simply assert that something is out of scope. A good entry might say, in plain terms: “This appears to request an additional report. The SOW lists one monthly report under section 3.2. Suggested classification: possible additional deliverable.”
That gives the account manager a useful starting point without pretending the software has final authority.
Tools and access needed
A basic version of this workflow could be built with fairly ordinary tools:
- read access to the relevant shared inbox or project Slack channel;
- the signed scope of work or proposal document;
- an LLM to compare messages against the scope and identify possible changes; and
- a shared document or workspace, such as Google Docs, Notion or a project management system, to hold the running log.
The important design choice is to keep the access narrow. The assistant should only monitor the communications relevant to the project, and the log should remain internal until a human decides what to share with the client.
Guardrails to avoid overreach
This is a relatively low-risk automation if it is designed as an internal assistant. It should not send messages to clients. It should not create formal change requests automatically. It should not treat every client question as a billable variation.
Its classifications should be clearly marked as suggested. The account manager should approve, reject or edit each item. That protects the client relationship and avoids turning a helpful tool into a rigid process.
A practical way to protect margin
Scope creep is rarely solved by one piece of software. It is partly commercial discipline, partly clear proposals, and partly good account management. But AI can help with the bit humans are bad at: keeping a consistent, searchable paper trail while the project is moving.
If your team regularly does “just one more thing” for clients and only works out the cost later, this is a sensible automation to consider. It can save time, strengthen evidence for legitimate change-request invoicing, and make project reviews calmer because the facts are already gathered.
If this sounds familiar, describe your version of the problem and I can help map a safe, practical AI workflow around it — with the right human approval points before anything reaches a client.
