The Friday your scheduling tool can't solve
Two engagements both flagged the same senior consultant for Friday. One is a fixed-fee implementation where she's the only person who understands the client's data model. The other is a time-and-materials assessment where the partner has been promising the client "our best person" for three weeks. Your resource calendar shows a conflict. It does not show that one of these clients is up for renewal in May and the other already churned a sister account last year. That context lives in three engagement managers' heads, and the Friday client call is in 48 hours.
This is the actual shape of a dispatch exception in a consulting firm, and it's why "let AI optimize the staffing calendar" misses the point. The calendar optimizes for utilization. The exception is about exposure: scope creep on the fixed-fee work, a partner's credibility on the T&M work, and which engagement lead has the authority to overrule the other. A model that resolves the conflict by minimizing idle hours will reliably make the wrong call, because it can't see the relationship stakes nobody wrote down.
The adoption research is worth reading precisely because it warns against this. The RSM middle-market AI survey, the San Francisco Fed small-business AI analysis, and the OECD SME AI adoption report all point to the same gap: firms that adopt fastest are the ones that decided, in advance, what data the system reads and who owns the decision it informs. For dispatch in a consulting practice, that means deciding which record is the source of truth for client priority before you let a model rank anything. The answer is almost never the calendar.
Build the exception packet, not the prompt
Here's the move most firms get backwards. They start by writing a clever prompt — "given these two engagements, recommend a staffing decision" — and discover the model produces a confident, fluent answer that no engagement manager will sign their name to. The fix isn't a better prompt. It's deciding what travels with the exception before any model touches it.
Say a 60-person advisory firm builds a standard exception packet that fires whenever a consultant is double-booked across two active engagements. The packet carries: the conflict itself (who, when, which two projects), the contract type on each side (fixed-fee scope risk reads very differently from T&M), a client-relationship flag (renewal window, account health, prior escalations), the named engagement lead on each engagement, and the override history — who has overruled whom before, and what happened. Now the model has something to reason over besides hours. And just as important, the packet names the human who gets the decision: when two engagement leads are in conflict, it routes to the practice lead, not to whoever the model finds least busy.
This is where the security frameworks earn their place. Use the NIST AI Risk Management Framework to fix the boundaries: who is accountable for the staffing call, what "acceptable" looks like when the model is wrong, and how you'd know. Use CISA AI Data Security Best Practices to decide what client-sensitive context — account health notes, contract terms, prior-escalation history — the model is allowed to see, retain, or log, because some of that is exactly the data a client would be alarmed to learn fed an automated routine. The rule of thumb: the model can draft the recommendation and assemble the evidence, but the assignment of a named human consultant to a named client engagement is a decision a person approves. A general assistant summarizing dispatch notes is a draft. A routine that reassigns billable people across client contracts needs deterministic checks around it and a reviewer signoff before it writes anything to a system of record.
The metric that matters: did an owner decide before the client did
The trap with consulting AI pilots is measuring the wrong win. "The model summarized 40 dispatch conflicts this week" is activity, not value. Deloitte's State of AI in the Enterprise 2026 is blunt about this distinction — the firms getting returns moved past pilot volume to production outcomes. For dispatch, the production outcome is specific: an accountable engagement lead made a deliberate staffing call before the client noticed there was a problem.
So measure the things a client actually feels. Time from conflict-detected to owner-decided. How often a staffing conflict became a client-visible escalation (the partner had to make an apology call) versus how often it was resolved quietly upstream. Specialist reassignment delay. How often the practice lead's override matched what the model recommended — because if they diverge constantly, your packet is missing the context the override is reacting to. And the one that ages badly if you ignore it: unresolved exceptions sitting open past the next weekly client touchpoint. If the pilot can't show you why one client's risk outranked another's, that's not a model problem — it's a sign your client-priority source is still living in people's heads, and you fix that before adding another AI surface.
Start narrow. Pick one delivery queue — one practice area, one set of engagement leads — and run every double-booking through the packet for a month. Use the manual-work scoring guide to confirm the conflict volume is actually worth automating before you build anything, then use the 90-day AI implementation plan to sequence the source cleanup, the prototype, the reviewer training, and the launch. The bar for expanding past one queue isn't "the summaries got cleaner." It's "our partners stopped getting blindsided on the Friday client call."
