When AI flags added scope and the project manager doesn't act, don't retrain the detector first. Trace one real flag from creation to a recorded commercial decision. The first missing transition tells you whether to fix delivery, evidence, authority, or the time and incentives to act.
We helped an engineering firm raise operating margin from 15.9% to 23.8%, and its CFO credited a large part of that overall improvement to our work. One rollout mistake inside that engagement gives a narrower lesson for ignored alerts. A manager reviewed only 2 of 14 flags after the pilot team's shared channel was carried into rollout. The team traced the problem to the manager having muted that channel, moved the flags to his inbox, and he reviewed 11 the next week. The change was in the decision path, not in the alert detector. You can read the full engagement in the engineering scope-change case study.
Here's what that looks like in practice. An illustrative flag, EX-02, points to a client's added equipment request. It lands in a shared channel, but no acknowledgement or decision reaches the project record. The question isn't whether the model needs another prompt. The question is where EX-02 stopped becoming a decision.
Trace one flag to the first missing transition
Start with one alert that should have led to a commercial choice. Follow the source request, alert, delivery event, review, decision, and project record. Don't begin with an adoption survey or a dashboard average. Those can tell you that use is low without showing where the work broke.
Copy this table into a worksheet or your current project system. The engineering COO owns the trace until a project manager or principal owns the next action.
| Flag ID | Source request | Delivered to | Seen evidence | Decision owner | First blocker | Change to test | Recorded decision |
|---|---|---|---|---|---|---|---|
| [ID] | [Email, meeting note, RFI, or comment with date] | [Destination and delivery time] | [Open, acknowledgement, or none] | [Named person and role] | [Delivery, evidence, authority, or time/incentive] | [One change] | [Price, recorded waiver, escalation, or pending] |
| EX-02 | Illustrative added equipment request | Shared channel | Manager reports the channel was muted | Project manager | Delivery | Use the manager-approved inbox route | Pending review |
For EX-02, the first failed transition is delivery to a place the manager actually checks. Move this one alert to the manager-approved inbox and observe whether it is opened and reviewed. Keep the source request, evidence packet, owner, and decision rules unchanged. If the manager now reviews it, you have evidence that delivery was the blocker.
That small test matters because every later problem looks like “low adoption” from the dashboard. A flag that never reached the manager needs a different repair from a flag the manager understood but couldn't price.
For an engineering COO, this is one place to test why project profit is leaking. Whether it deserves the next investment depends on what most limits the firm's goal, including the work before and after the alert.
If you're an engineering COO and want to grow your firm without working harder on projects that earn less than they should, we'll identify the biggest bottleneck standing in your way, build the plan to remove it, and implement it in eight weeks* or less - guaranteed or we continue to work for free and you don't pay.
Find my bottleneck* Eight-week delivery, or twelve weeks when substantial data foundations are required, as agreed before work begins. If a covered stage fails its agreed benchmarks, we provide up to four additional weeks of remedy work at no charge, then waive or refund that stage's fee if it still fails. Successfully delivered stages remain payable. Agreed client-caused delays pause the clock. Delivery guarantee terms.
Give each blocker a different repair
Use four branches after you reconstruct the trace. Stop at the first one supported by the record.
| Branch | Evidence in the trace | Change to test | Don't change yet |
|---|---|---|---|
| Delivery | No open, acknowledgement, or review event at the destination the manager uses | Ask where this decision should arrive, route one flag there, and confirm receipt | Detector prompt, thresholds, or evidence fields |
| Evidence | The manager opens the flag but can't tell what changed, where it came from, or what rule applies | Add the source passage, scope reference, work already underway, and a draft notice | More reminders or escalation layers |
| Authority | The manager understands the flag but can't approve the price, waiver, or exception | Route it to the named principal or set a documented approval limit | Delivery route that is now working |
| Time and incentive | The manager has the evidence and authority but notice work loses to deadline or utilization pressure | Give the decision a due owner, count approved notice work correctly, and align the scorecard | The alert detector |
In the documented engineering rollout, both delivery and incentives mattered. Managers were measured on utilization while notice preparation counted as overhead. We proposed counting that work as project time and adding recovered fees to the scorecard. Leadership adopted both changes. The manager now had a reachable decision and a measure that recognized the work required to make it.
If the trace shows that alerts are noisy or missing real changes, return to the scope-change triage method and repair the detector. But don't use a detector change to solve a destination, authority, or incentive problem.
Carry the same flag through the later branches
Suppose the inbox change works. The manager opens EX-02, but the alert only says “possible change.” It doesn't show the client's request, the affected scope, or whether work has started. Delivery is no longer the first blocker. Keep the inbox route and repair the evidence packet.
A review-ready alert should contain the source passage, source time, relevant scope reference, a short description of the added work, work already underway, and the firm's approved commercial rule. AI can read correspondence and project records, connect the candidate change to its sources, and draft a notice. Fixed workflow rules should record where the alert was delivered, who owns it, when it is due, and what decision was entered. The project manager still decides whether to price the work, absorb it with a recorded reason, or escalate it.
Now change the condition again. EX-02 reaches the inbox with complete evidence, but the proposed price exceeds the project manager's approval limit. Another reminder won't create authority. Keep the working route and evidence packet, then send the decision to the named principal with the manager's recommendation attached.
Change the condition once more. The manager has the evidence and authority, but the notice remains open while deadline work is rewarded and notice preparation is treated as overhead. The engineering COO now owns the repair. Decide how approved notice work counts, set an age for escalation, and make unresolved decisions visible to the person accountable for project profit.
Each branch preserves the parts of the workflow that already passed. That gives you a smaller change to test and a clearer explanation if the result improves.
Define a decision before measuring adoption
An alert isn't complete because somebody opened it. It is complete when the responsible person records one of the firm's valid commercial choices.
- Price the added work. Record the proposed amount, source request, approver, notice, and client response.
- Absorb it with a reason. Record why the firm chose not to charge, who approved that choice, and what work it covers.
- Escalate it. Record the principal or commercial owner, the question they need to decide, and the due date.
The engineering case counted a waiver because the manager had made and recorded a commercial choice. That distinction prevents a dashboard from treating silent absorption as a decision. It also lets finance follow an accepted price back to the source request without claiming that a billed amendment is collected cash.
The record should also retain corrections. If the manager finds that the request was already included in scope, mark the alert as a detector error and preserve the reason. That evidence belongs in the next detector review. It shouldn't be mixed with alerts that were accurate but failed later in delivery or authority.
Measure the transition you changed
After the small repair, rerun the trace on fresh flags. Compare the transition you changed before you make a rollout decision.
| Measure | What it answers | Keep separate from |
|---|---|---|
| Delivered to the approved destination | Did the alert reach the manager's working surface? | Whether the alert was correct |
| Seen or acknowledged | Did the manager encounter it? | Whether they had authority to decide |
| Documented decision within the firm's target age | Did the flag become a commercial choice? | Whether the client accepted the price |
| Priced and billed additional services | Did accepted work enter billing? | Cash collection and firm margin |
| Detector errors and review effort | Is the evidence accurate enough to justify attention? | Delivery and incentive problems |
Use counts with their denominators and periods. The documented rollout tells us that the manager reviewed 2 of 14 flags before the route changed and 11 the next week. It doesn't give the later week's total, so it doesn't support a review percentage. The wider engagement later moved documented decisions within ten business days from 43% to 86% across the programs, while first-quarter additional services billed rose from a prior run rate of about $225,000 to $410,000. Those are separate operating and billing measures. Neither is collected cash.
If you are evaluating whether the wider AI effort improved job economics, the whole-job pilot review shows how to include review, correction, revision, and closeout work instead of stopping at alert speed.
Change one step, then run the trace again
Take one ignored flag today and complete the eight fields in the trace. Stop at the first missing transition. Change only that step, keep an owner on the unresolved decision, and watch what happens to the next fresh flags.
If the flag is unseen, change delivery. If it is unclear, change the evidence. If the manager lacks authority, change the escalation path. If the manager has everything except protected time or a reason to act, leadership needs to change the operating measure. Only return to the detector when the trace shows that detection is the first failure.
That gives the engineering COO a concrete decision instead of another adoption campaign. It can recover scope that should be priced, but it is still one operating mechanism. Start the wider investment decision with the firm's growth or profit goal, then investigate whether scope decisions or another bottleneck most limits it.
If you're an engineering COO and want to grow your firm without working harder on projects that earn less than they should, we'll identify the biggest bottleneck standing in your way, build the plan to remove it, and implement it in eight weeks* or less - guaranteed or we continue to work for free and you don't pay.
Find my bottleneck* Eight-week delivery, or twelve weeks when substantial data foundations are required, as agreed before work begins. If a covered stage fails its agreed benchmarks, we provide up to four additional weeks of remedy work at no charge, then waive or refund that stage's fee if it still fails. Successfully delivered stages remain payable. Agreed client-caused delays pause the clock. Delivery guarantee terms.