Your inventory walks out the door at 6 p.m.
A manufacturer can count its inventory on a shelf. A consulting firm can't. Your inventory is billable hours, software seats, and the inputs a project needs to stay profitable, and most of it is invisible until the month-end reconciliation tells you a senior consultant was double-allocated for three weeks, a project ran two sprints without a signed-off data feed, or you've been paying for forty Salesforce seats while thirty-one people actually log in. None of those sit on a shelf. They surface in a margin number, after the money is already gone.
That is why inventory exception reporting in a consulting firm is not a warehouse problem dressed up in AI. It is a capacity-and-commitment problem. The exception that matters is the gap between what a project was scoped to consume and what it is actually consuming, surfaced while a partner can still reassign someone or pause a burn. Deloitte's State of AI in the Enterprise 2026 and the OECD's report on AI adoption among small and medium-sized firms both describe the same pull: services firms reaching for AI to get operating visibility they never had. The pull is real. The implementation decision is still yours, and it lives at the level of a single queue.
So build one queue, not a platform. One feed that pulls from your PSA or time system, your license admin consoles, and your project intake, and that emits a single line per exception: the source record, the project it threatens, the owner who can act, and the decision required this week. If your first version produces a dashboard nobody opens, you've rebuilt the problem you already have.
The test isn't "did it flag," it's "did a partner change the plan"
Here is where most consulting firms quietly fail: they wire up an alert that fires every time a consultant crosses 95% utilization, and within two weeks the alert is noise because the firm runs hot on purpose. An over-allocation alert is only an exception if it predicts a missed deadline or an unbillable scramble. Tune the rule to the thing you can act on, not the thing that's easy to measure.
Pick three exception types that actually move margin and ignore everything else at first. Say a 60-person firm starts with: a consultant allocated above their committed hours across two or more active engagements, a paid software seat with zero logins in 30 days, and a project that has logged time but is missing a required client input or signed change order. Set the baseline honestly — how many of these surface today only at month-end, and how late. Then, every week, look at four numbers: how many flagged exceptions a partner actually accepted and acted on, how many were false alarms, how often the underlying source data was stale, and how many margin-affecting items got caught before the weekly portfolio review instead of after.
If accepted exceptions go up and false alarms go down over a month, the workflow changed operator behavior. If a partner is still finding the over-allocation themselves on a Friday call, the queue isn't earning its keep yet — fix the rule before you add a fourth category. Only once those numbers hold should you reach for the AI Opportunity Score or the AI ROI Calculator to size the next workflow, and only with a named owner attached to each.
Define the exception before you automate it — and guard the client data
An exception you can't define precisely will generate alerts you can't trust. Write down, in one sentence each, what "over-allocated," "idle seat," and "missing input" mean — including the threshold and the time window — and name the source-of-truth owner for each. The PSA owner owns allocation. IT or ops owns license logins. The delivery lead owns project inputs. When an alert fires and someone disputes it, you want the definition and the owner already settled, not litigated in the moment. The NIST AI Risk Management Framework is a practical structure for documenting intended use, risk, and accountability for exactly this kind of internal tool.
Consulting amplifies one risk most operators underweight: your exception logs are stitched together from client project data. A queue that surfaces "Project X is missing input Y" is, by construction, touching confidential engagement detail. Use CISA's best practices for securing the data used to train and operate AI systems to set retention limits on those logs, scope who can see cross-client patterns, and keep client-identifying detail out of any model context you don't control. Require human review before any exception triggers an action that reaches a client or changes a staffing plan.
Run that single queue until partners trust the alerts enough to act without re-checking them. That trust — not a feature count — is your signal to extend from capacity into adjacent license and project-input signals. Monday's move: open your last three months of project P&Ls, list the margin misses you discovered too late, and check how many trace back to one of these three exception types. That list is the specification for your first queue.
