The quote is stuck and sales does not know why
The deal is waiting on a system nobody in the room owns, and every person being chased is genuinely unable to help.
What actually happens
This is not an outage and it will never appear in an availability report, which is exactly why it can sit unresolved for days.
A quote is approved in the CRM and needs to become an order in the ERP. The integration between them is a queue, and the record enters it normally.
Something rejects it. A missing tax code, a customer record that exists in one system under a slightly different name, a product code retired last quarter. The message goes to an error queue.
Nothing alerts, because from each system perspective nothing failed. The CRM sent it. The ERP never received something it was expecting, so it is not waiting on anything. The error queue has a monitor, and that monitor emails a distribution list that was set up during the original implementation.
Sales notices when the customer asks. They contact support, who can see the quote is approved and cannot see the ERP. Support contacts finance, who can see no order and cannot see the CRM. Each escalation is reasonable and none of them can reach the queue.
Days pass on a record that takes about two minutes to fix once someone with access to the error queue looks at it.
Every person in this chain did the right thing. The record was sitting in the one place none of them could see, and nothing was watching it on their behalf.
The same order, two ways
This clock is measured in days rather than minutes, which is what makes it worth putting next to the outage stories.
Illustrative, not measured. The times below model a scenario built from the patterns we see in production estates. They are not timings recorded at a named customer. The point is the shape of the clock, not the totals: check it against your own last ten incidents.
Today, found when the customer asks
- Day 0Quote approved. Integration message rejected into an error queue. No alert reaches an owner.
- Day 0 ↓ Day 3WaitingRecord sits. Sales assumes it processed. Finance sees no order and assumes none was raised.
- Day 3Customer asks about their order. Sales contacts support.
- Day 3 ↓ Day 4WaitingSupport checks the CRM, escalates to finance, finance checks the ERP. Neither can see the queue.
- Day 4Integration owner located. Error queue inspected. Missing tax code identified.
- Day 4Corrected and reprocessed. Two minutes of work.
~4 days · on a two-minute fix
With Sentinel watching the flow
- Day 0Message rejected. Sentinel treats the flow as the monitored object, not the systems either side of it.
- Day 0CRM record state, integration queue, ERP order state and the rejection reason correlated.
- Day 0Cause identified: missing tax code on the customer record. Two comparable rejections found this month.
- Day 0Action Ticket raised, routed to the account owner in finance rather than to an implementation-era distribution list.
- Day 0Sales notified that the order is held, with the reason and the expected resolution, before the customer asks.
- Day 0Tax code corrected and approved. Message reprocessed under governance. Order created.
Same day · and sales heard it from us, not from the customer
There is no MTTR figure worth quoting here. The fix takes two minutes in both columns. The four days are entirely detection and routing.
What makes this pattern expensive is not the individual record, it is the rate. Every integration between two enterprise systems has an error queue, and the proportion of records that land in it is small but never zero.
The mechanism is monitoring the business flow rather than the systems that implement it. A quote that has been approved and has not become an order after a defined interval is an exception regardless of what either system reports about itself.
Routing is the second half and it is often the more valuable one. An alert that reaches the account owner in finance is actionable; the same alert reaching a distribution list created during implementation is not.
Why the number is what it is
There is no MTTR figure worth quoting here. The fix takes two minutes in both columns. The four days are entirely detection and routing.
What makes this pattern expensive is not the individual record, it is the rate. Every integration between two enterprise systems has an error queue, and the proportion of records that land in it is small but never zero.
The mechanism is monitoring the business flow rather than the systems that implement it. A quote that has been approved and has not become an order after a defined interval is an exception regardless of what either system reports about itself.
Routing is the second half and it is often the more valuable one. An alert that reaches the account owner in finance is actionable; the same alert reaching a distribution list created during implementation is not.
The mechanism is monitoring the business flow rather than the systems that implement it.
Who decides to press go
Correcting a customer master record and reprocessing a financial transaction are both changes to systems of record, so both are gated.
Detection, correlation, notification and routing all run under policy. None of them change a record.
The Action Ticket is raised with the proposed correction, the affected records and the rollback path attached, and routed to the accountable owner in finance for approval.
Reprocessing a message into a financial system is exactly the kind of action that must have a name against it, because a duplicate order is a worse outcome than a delayed one.
Quote approved in the CRM with no corresponding order in the ERP after the expected interval. Message present in an integration error queue with no monitored owner.
CRM record state, integration queue, ERP order state and rejection reason correlated. Missing tax code identified. Comparable rejections this month surfaced.
Action Ticket raised and routed to the account owner in finance. Sales notified that the order is held with the reason attached. Correction and reprocess held for approval.
Flow-level monitoring retained for quote-to-order elapsed time. Tax code validation added at quote approval so the rejection cannot recur silently.
This is a platform capability, not a published customer deployment for this exact scenario. The mechanism, which is cross-system correlation followed by governed MOP execution with pre-check, post-check, rollback and approval gating, is running in production today across managed estates; see governed day-2 operations across 2,000+ nodes and closed-loop network automation. The timings shown are modelled, not measured at a named customer.
If the action carries no service impact
Detection, correlation, notification and routing all run under policy. None of them change a record.
If it corrects data or reprocesses a transaction
The Action Ticket is raised with the proposed correction, the affected records and the rollback path attached, and routed to the accountable owner in finance for approval.
What Sentinel did, step by step
- ObserveQuote approved in the CRM with no corresponding order in the ERP after the expected interval. Message present in an integration error queue with no monitored owner.
- InvestigateCRM record state, integration queue, ERP order state and rejection reason correlated. Missing tax code identified. Comparable rejections this month surfaced.
- ActAction Ticket raised and routed to the account owner in finance. Sales notified that the order is held with the reason attached. Correction and reprocess held for approval.
- OptimizeFlow-level monitoring retained for quote-to-order elapsed time. Tax code validation added at quote approval so the rejection cannot recur silently.
Bring us your integration error queues
We will show you how long the oldest record has been sitting there.