Consulting scope changes: turn client requests into approval decisions

Before adding AI, I would identify the current signed scope, approved changes, and delivery plan. A folder containing six similarly named proposals is not enough. The application needs a stable reference to the version the team has agreed to use.

Each captured request should retain its source message, requester, timestamp, client or engagement identifier, and relevant attachments. If the request arrives through an informal channel, the delivery lead can confirm whether it should enter the change process. Capturing a message does not mean accepting the request.

I would also preserve the words that make the request ambiguous. “Can we add this?” and “Please include this in the approved release” may require different follow-up. A generated summary should not turn either into a confirmed commitment.

The useful output is a proposed comparison: requested behavior, relevant existing scope section, possible overlap, missing information, and affected systems. The model should cite the scope section it used and leave uncertainty visible.

If the client asks for a new dashboard, the comparison might identify an existing reporting deliverable but note that the requested data source is absent. That is a review cue. It is not proof that the work is out of scope or that an additional fee is owed.

The delivery lead decides whether the request is already covered, a clarification, a defect, or a proposed change. Those distinctions matter commercially and operationally. I would keep the final classification as a human decision recorded separately from the model's suggestion.

After classification, the team may need a technical estimate, a schedule assessment, or a client decision. The workflow should route those tasks to named owners and collect their responses without inventing a price.

For a new integration, the engineering owner might identify authentication work, data mapping, a test environment, and an operational handoff. The delivery lead can use that information to prepare a change proposal. Any quoted fee or date must come from the authorized person and approved commercial process.

The approval screen should show the exact proposed change, exclusions, dependencies, fee if supplied, and schedule effect. A generic “approve change” button leaves too much room for disagreement. Approval should attach to a specific revision, with an expiry or re-review rule if the underlying facts change.

A captured change request should not immediately become committed delivery work. I would use a distinct review state and prevent it from appearing in the team's promised release until the required approvals exist.

Once approved, the integration can create or update delivery tasks with a link to the approved revision. It should preserve the relationship between the original scope, the change decision, and the resulting work. That makes it possible to answer why a task exists without reconstructing a month of chat.

If the project-management write fails, retain the approval and mark task creation pending. Do not ask the client to approve again simply because a connector failed. Conversely, do not mark the change implemented because the task was created. Approval, scheduling, implementation, and acceptance are separate states.

A rejected request should keep its rationale and source. The same idea may return later with a smaller scope or a different budget. Preserving the decision prevents the team from repeating the same investigation without context.

Withdrawn requests need a clean path too. If a client withdraws a change while it is awaiting estimation, cancel the pending estimate request where possible and preserve the withdrawal event. If work has already begun, the delivery lead needs to decide what happens next. The software should not infer that a withdrawal reverses incurred effort or changes contract terms.

I would also allow the owner to return a request for clarification. The question should identify the missing decision: which users need access, which data source is authoritative, or whether the change replaces an existing deliverable. This is more useful than asking the client to “provide more detail.”

Anthropic's workflow and agent distinction is relevant here: a predefined sequence is a good fit when the process already has known decision points. I would implement capture, comparison, classification, estimation, approval, and task creation as explicit steps.

If n8n is used, its human review mechanism can pause selected tool actions. I would still enforce engagement permissions and revision matching in the application. A message from an unauthorized participant cannot substitute for the required approval.

The model should have access only to the engagement material needed for the comparison. It should not search unrelated client scopes for pricing precedents or expose another client's terms in the proposed response.

I would test a request that is already covered, one that conflicts with a prior approval, one with no identified requester, and one that changes after approval. Include duplicate messages from two channels and a task-board outage after the decision is recorded.

Acceptance evidence should show that each request has one durable identity, that approval applies to the correct revision, and that no unapproved work is labeled committed. The delivery lead should be able to trace a task back to its authorization in one or two steps.

Measure review time, requests returned for clarification, tasks created without valid approval, and manual reconciliation effort. Those observations can show whether the process is becoming easier to operate. They do not establish increased margin unless the firm also measures delivery effort and commercial outcomes.

I would test a synthetic request for a dashboard using an existing data source. After the delivery lead classifies and estimates it, I would change the request to include a second external system. The earlier approval should no longer authorize the expanded version.

The review history should show both revisions, the changed dependency, and the decision needed. The task board should retain any legitimate work already approved while clearly holding the additional scope. The workflow should not delete history or make the new request look as though it had always been included.

Then I would approve the revised request and temporarily fail the task-board connector. Recovery should create the intended tasks once and link them to the revised authorization. This exercise tests commercial boundaries, versioning, and technical replay together. It also gives the delivery lead a concrete way to judge the implementation without needing to inspect its code.