When automation misses work without raising an error

The dashboard shows every run succeeded. A customer is still waiting for a request that nobody can find in the work queue.

Both can be true. If the request never became a job, the automation has no failed job to report. The operator needs a second question beside “Did the runs finish?”: “Did every eligible request reach a recorded outcome?”

That is an intake reconciliation problem. It starts outside the automation's own activity log.

Start with the requests that should have arrived

Consider a hypothetical equipment service business. Customers submit service requests through a form. An automation creates a case, prepares a brief and places it in the dispatch queue. A dispatcher checks the brief before scheduling a visit. This is a design example, not a reported client result.

During one morning, the form system records 40 eligible requests. The automation receives 38, creates 38 cases and reports 38 successful runs. Its run success rate is accurate, but two customers have no case.

A useful check starts with the form system's saved submissions and compares them with the case records. It does not ask the automation to list the requests it remembers receiving. That would reproduce the same blind spot.

Define the source precisely. Is it the saved form submission, an accepted email or an entry in an existing CRM? If several channels feed the process, reconcile each channel. A form-only check cannot prove that email requests were covered.

Also name the boundary of the check. Comparing saved submissions with cases will not detect someone who tried to submit a broken form and never created a source record. That needs a separate check of the intake experience.

Agree what counts before counting it

Write down the eligibility rule with the person who owns dispatch. For example: include submitted service requests, exclude explicitly marked test records, and keep withdrawn requests visible with their withdrawal reason.

An exclusion should be explainable from a source field or an authorised decision. “The automation did not pick it up” is not an exclusion rule.

Choose a reconciliation window and one timezone. Record when the source request was accepted, when the automation received it and when the case reached the next agreed state. Those timestamps answer different questions.

Allow for a documented normal intake delay. A request submitted seconds before the check should not automatically look lost. But a grace period must expire: an old request cannot remain “probably on its way” indefinitely. Revisit recent windows to catch late arrivals, and retain older unresolved discrepancies until someone closes them with evidence.

Compare identifiers, then summarise the totals

Carry the source request identifier into the case record and any downstream dispatch record. Keep a mapping if the systems use different identifiers. A customer name is not enough: the same customer may legitimately request two separate visits.

Matching individual records reveals problems a total cannot. If 40 source requests produce 40 case records, the intake may still contain one missing request and one duplicate case.

For each eligible source request, assign a reconciliation state:

Use totals to summarise this record-level comparison. Do not let a count difference become a substitute for a list of the actual requests that need attention.

Give missing work a recovery path

A discrepancy needs a named owner, a review deadline and the source record. Add the last known processing step, any downstream identifiers and the customer's current request status.

The owner should first establish what happened. Was the source filtered incorrectly? Did the intake connection stop delivering? Was the case created but its acknowledgement lost? Has the customer since withdrawn the request?

Only then choose the recovery action. A confirmed missing case may be eligible for controlled replay. An uncertain case needs a destination check. A withdrawn request should not become a fresh dispatch instruction simply because it appeared on yesterday's missing list.

Record the replay against the original request identifier so the next reconciliation can see the recovery. Where the destination supports it, use a stable reference to prevent the same request creating repeated cases. Do not assume that repeating an action is harmless.

For a broken connection, use the automation failure recovery process. Reconciliation identifies the affected work; recovery restores the connection and handles the backlog. Keep both records linked so the team can verify that fixing the integration also recovered the missed requests.

Check the checker

The reconciliation itself can stop running or lose access to the source. Its report should show when it last completed, which source and time window it covered, and whether the source read was complete.

A failed source read must produce “coverage unknown”, not “zero missing”. If the source returns records in pages, the check needs to account for every page in the chosen window. A partial extract can make a busy morning look quiet.

Before relying on the report, test a small set of deliberate failures:

1. Leave one eligible source request out of the automation queue; it appears as missing after the grace period.
2. Create two cases for one request; the duplicate does not cancel out another request's absence.
3. Delay a valid request; it moves from waiting to matched without losing its history.
4. Create a case but omit its acknowledgement; recovery checks the destination before another creation attempt.
5. Withdraw a request before recovery; replay respects the current source state.
6. Interrupt the source extract; the report marks coverage unknown and alerts its owner.
7. Stop the reconciliation job; the missing completion signal is noticed within the agreed review period.

Run these checks alongside the pilot release gate. A perfect result on the cases that arrived does not establish intake coverage.

Report the work the customer is still waiting for

For the hypothetical morning above, report 40 eligible source requests, 38 matched cases and two missing cases. Keep the missing requests' age and assigned owner visible. If one is recovered later, update its status without rewriting the earlier observation as though nothing was missed.

For an operating review, separate three measures: intake coverage, processing quality and final resolution. A matched case can still contain a bad brief; an accurate brief can still wait too long for dispatch. Each gap has a different owner and corrective action.

Include investigation and recovery effort in the automation ROI review. A high run success rate cannot tell you how much work staff spend finding customers who fell outside the queue.

For a workflow review with SolvTree, bring a sanitised source request list and the matching case list for one bounded period. The first useful deliverable is simple: every eligible request accounted for, and every unexplained gap assigned to someone who can resolve it.