← operator playbook
Apr 21, 20266 min read

Building a cashier that doesn't need agents at 3am

Most operators discover their cashier is agent-driven the moment volume spikes at 3am. Here's the architecture that lets you sleep — and the specific decisions that make it work.

engineeringoperationsautomation

Every operator we've onboarded had the same story: the cashier worked during business hours. It fell apart on Saturday night. Either agents were paid overtime to babysit approvals, or transactions queued until Monday and customers churned.

The root cause is never the tooling. It's the decision to route any transaction through a human by default.

What agents should actually do

Automate the happy path completely. Route to a human only when a specific rule fails. Design the ruleset so the failure rate is under 5% at any given hour.

The five rules that cover 95% of transactions:

  1. 01The transaction amount is within a preset band for this customer's tier.
  2. 02The rail matches a rail the customer has used before, or a whitelisted new rail.
  3. 03The verification signal (screenshot cross-verified, or on-chain confirmed) came back green.
  4. 04The customer's session has no fraud flags open.
  5. 05The customer's daily and weekly velocity is under threshold.

Any transaction that passes all five gets credited automatically. Any transaction that fails at least one gets routed to an agent with the specific failing rule highlighted.

Why this works at 3am

At 3am you have low agent coverage and a spike in a specific transaction type — usually new customers making first-time top-ups from a US timezone. The rules that fail most often at 3am are #2 (new rail) and #5 (velocity, when a returning customer scales up). Everything else passes.

Design your first-time customer flow to route through a slower path — an explicit welcome window, a lower first-transaction cap, a warmer verification threshold. First-time customers at 3am get a smooth experience with tighter rails. Returning customers at 3am see no friction at all.

What breaks the model

  • Rules that reference off-system data. If rule #4 requires an agent to check an external system, rule #4 fails at 3am. Either the data comes into the cashier or the rule doesn't run.
  • Rules that trigger on statistical thresholds without a fallback. A '3-sigma velocity anomaly' rule sounds smart until 4% of legitimate transactions trip it at peak hours.
  • Manual overrides that become the default. If agents habitually override rule #2 because it's 'usually fine', the rule is dead and the automation stops working.

Instrumentation

Track two numbers weekly: automatic-approval rate (target: 95%+) and false-decline rate (target: under 0.5%). Both moving in the wrong direction means the ruleset is stale. Both flat means the automation is stable.

The operators who sleep through Saturday night are the ones who put this instrumentation on a dashboard and treat drift as a bug to fix in the next iteration, not a fact of life.

// related reading