Stalled-Client-Approval Cross-Surface Detection Automation: 33 Delivered Pieces the Nudge Routine Never Saw
A nudge routine watching only half of where work actually lives looks fine right up until someone checks the other half
A detector that scans one system correctly, on schedule, every day, produces real, believable output for exactly the subset of cases that still happen to pass through that one system. Nothing about a clean run and a sensible-looking result reveals that an entire second category of the same underlying problem exists somewhere the detector was never told to look.
How the underlying problem shows up before you fix it
A detection routine, built against one system's own status field, keeps running correctly and producing real output for the subset of cases that still pass through that one system.
A second delivery surface for the identical kind of work is added to the platform over time, with its own separate timestamp and decision fields, and nothing updates the existing detector to look there too.
The absence of alerts about a category of stalled work gets read as "everything in that category is fine," rather than "the routine watching for it cannot see this category at all."
Two branches meant to detect the same underlying business condition from two different sources would double-notify the same person about the same client on the same day, if they aren't coordinated through one shared deduplication key.
A stalled-item count of zero from an automated routine is trusted without anyone independently counting, by hand, how many items are actually stalled in a system the routine never queries.
How the blind spot was measured, and how the second detector branch closes it without duplicating alerts
The existing routine, run per client-service agent, scans the general task board for anything sitting in the "Client Approval" stage past a configured number of business days, and produces one nudge per client per day naming how many pieces and how long they've waited. As Atlas grew its own, separate client-approval flow — a delivered piece gets a "sent to client" timestamp and, independently, an approval-decision field the client eventually resolves — that entire flow sat outside anything the task-board-based routine could query, because it isn't a task-board record at all.
The measured gap: thirty-three pieces delivered through Atlas, sitting three or more business days with no decision, and the routine's own dedup log showed zero nudges triggered by any of them in the prior seven days — not because nothing was stalled, but because the routine, correctly by its own design, never looked there.
The fix adds a second branch to the same detector function, running immediately alongside the first on every scheduled pass, applying the identical configurable business-day threshold against Atlas's own delivery timestamp and decision field — filtered to pieces genuinely still undecided (excluding anything the client has explicitly approved or rejected) and excluding anything already reclassified as scheduled or published. The two branches share the exact same deduplication-key format, built from the client's own conversation identifier and the calendar day, specifically so a client with pieces stalled on both surfaces at once gets one combined nudge for that day rather than two competing messages arriving separately. The new branch's own nudge text additionally carries the actual piece titles, a detail the original branch's message didn't need because task names were already visible on the board it watches — closing the risk of a vague nudge about work that lives on a surface the client-service agent doesn't normally check itself. Verified against real production data at the time of the fix: the new branch alone would have surfaced several distinct real accounts, the most affected already three or more times past the configured threshold.
What is actually built today
The stalled-approval detector now runs two branches on every scheduled pass: one against the general task board's own approval stage, and a new one against Atlas's own delivery-and-decision fields.
Both branches apply the identical configurable business-day threshold and produce the identical nudge structure, regardless of which surface the stalled work actually lives on.
A single shared deduplication key, built from the client's own conversation and the calendar day, prevents the same client from being nudged twice in one day even when stalled work exists on both surfaces at once.
The Atlas-sourced branch names the specific stalled piece titles directly in its output, giving the nudge concrete detail even for work the client-service agent doesn't monitor through the board it's used to.
Confirmed live at the time of the fix: the new branch alone would have triggered real nudges for several accounts, the most severe already three or more times past the threshold.
A stalled piece that lived on the wrong side of the detector (illustrative framing of the actual measured finding)
A piece of artwork is delivered to a client through Atlas on a Monday and sits with no decision through the following Thursday — three full business days. Before the fix, the daily nudge routine has no way to know this piece exists at all, because it never queries Atlas's own delivery records. After the fix, the same routine surfaces it by name in that day's nudge, exactly as it already does for anything stalled on the task board.
What changes operationally
Centriu's client-service nudge routine can no longer be structurally blind to an entire delivery surface — any piece genuinely awaiting a client's decision, whichever system it was actually delivered through, now feeds the identical staleness check and the identical once-a-day nudge, closing a gap that had let 33 real pieces sit stalled with zero automated follow-up.
When this is not the right fit
This detector decides when to nudge a client about something awaiting their decision — it does not chase the decision itself, escalate beyond a daily group message, or change how either surface's own approval workflow works.
Watching one door vs. watching every door the same work can walk through
A detector hard-wired to one system's own schema will always miss the identical business condition the moment a second, equally legitimate delivery path exists for it. Centriu's fix recognizes the actual condition worth detecting — something delivered, awaiting a client decision, past a threshold — and checks for it wherever it can genuinely occur, rather than wherever the detector happened to be built to look first.
Related systems
Main system: Centriu Atlas. Complementary when relevant: Centriu Axis.
What it does NOT do
- Does not chase or escalate a stalled approval beyond the existing once-a-day group nudge — a person still decides what to do if a client stays unresponsive.
- Does not change the underlying approval workflow on either surface — a client still approves or rejects exactly as they did before.
- Does not merge or migrate Atlas-delivered pieces into the task board, or vice versa — each surface keeps its own records; the detector simply reads both.
- Does not nudge twice about the same client on the same day even when both surfaces have stalled work — the shared deduplication key collapses that into one message.
- Does not apply to a piece the client has already approved or rejected, regardless of how long that decision took to arrive.
- Does not guarantee every possible delivery surface across the platform is now covered — this fix closes the specific, measured gap found between the task board and Atlas.
Security and governance
Both detector branches resolve and act strictly within each client's own organization and conversation; no nudge or lookup crosses an organization boundary. Any client or business data referenced remains subject to Brazil's LGPD (Law No. 13,709/2018). Full detail on access control lives at /governanca and /iso.
Pricing and contracting
Available by monthly subscription, with tiered plans. Values and terms come from the official pricing table at /precos (Centriu's central source — never restated here).
Frequently asked questions
Why was the nudge routine blind to artwork delivered through Atlas?
It was built against the general task board's own "Client Approval" stage; Atlas's own delivery-and-decision fields are a separate, later-added flow that the original detector logic never queried.
How many stalled pieces were actually found?
Thirty-three real pieces delivered through Atlas, sitting three or more business days with no client decision, with zero nudges sent about any of them in the prior week.
Does this send duplicate nudges if a client has stalled work on both surfaces?
No — both detector branches share the identical per-client, once-a-day deduplication key, so a client with stalled work on both surfaces still gets one combined nudge for that day.
What does the nudge actually say?
It names the client, how many pieces are stalled, how many business days, and — for pieces sourced from Atlas specifically — the actual piece titles, sent once daily to that client's own group conversation.
Does the detector do anything beyond sending the nudge?
No — it identifies and notifies; a person still follows up if a client remains unresponsive after the nudge.
What does Centriu Atlas cost?
It is sold by subscription with a published starting price — exact current values are on the central pricing page.
See how Centriu keeps stalled client approvals from going unnoticed
Reach our commercial team directly, or leave your details below — we'll follow up with guidance for your case.