Eleven Screens, One Inbox
A failed sync, a till that closed short, a ticket past its deadline and a sign-in from two countries in an hour were each reported on their own screen, to whoever happened to open it. Here is why one exception inbox with an owner, a clock and a closing reason works better than eleven well-built alerts.
On the Monday after month-end, four things were wrong at once. The accounting sync had been failing quietly since Friday. One till had closed 3,200 short on Saturday and nobody had reviewed it. A supplier invoice was stuck in a three-way match. And a support ticket from the biggest customer had passed its deadline on Sunday night. Every one of those had been flagged, correctly, on its own screen. Nobody owned any of them, because nobody owned the screens.
Most operations software gets the detection right and the follow-through wrong. Each module grows its own alert, built by the people who know that module best, and each one is good. Then the alerts sit in eleven places, each with its own idea of urgency, and the question that matters on a Monday morning, which of these is the worst and who is on it, has no screen at all. We wrote about letting a dashboard number raise its hand in threshold alerts. This is the other half: once something has raised its hand, somebody has to own it until it is closed.
What feeds the inbox
| Source | What raises an exception |
|---|---|
| Smart alerts | Stock, late orders, overdue invoices, pricing below cost |
| Security incidents | Anomaly rules and audit-chain checks |
| Workflow exceptions | A step that failed or could not continue |
| Connector dead letters | An outbound event that ran out of retries |
| QuickBooks sync | A record the accounting sync refused |
| Offline conflicts | A queued phone action that no longer fits |
| Procurement matches | An order, receipt and bill that disagree |
| Support SLA | A ticket past its deadline |
| Ledger integrity | A check on the books that failed |
| Till cash variance | A closed session still waiting for review |
| Trash purges | A scheduled purge that failed |
The sources keep their own screens. The inbox does not replace the match queue or the security page; it gives each of their problems the same four things: an owner, a clock, a history and an ending.
A clock that means the same thing everywhere
Severity decides the deadline, and the deadline is the same whichever module raised the problem. Low and information-only exceptions get a week and two weeks. Reopening an exception restarts its clock, so a closure that did not hold is measured again from the start. When the clock runs out, the exception escalates to the people who manage the workspace, and again every day until it reaches the third level.
An ending you have to name
An alert that clears itself tells you the symptom went away. It does not tell you whether someone fixed it, decided to live with it, or found it was never real. Every exception here closes with one of six reasons: fixed, false positive, accepted risk, duplicate, handed off to support, or no action needed. Before closing, triage records whether it was confirmed and a root cause, from data entry through configuration and integration to fraud or misuse. A month of those answers is the most useful operations report you will get, because it says where problems come from rather than where they were noticed.
Tuning without going quiet
A rule that cries wolf gets ignored, so it can be muted, given a different severity or a different deadline. Each of those needs a written reason. A rule that went silent six months ago should be explainable by reading its history, not by asking who was around at the time.
The morning list and the executive view
Each person gets a morning digest of the open exceptions of high severity or above in the modules their role covers, plus anything assigned to them, at most fifteen rows. The executive view shows the same data from further up: a heatmap of severity by module, the age of the backlog, a daily trend of opened, breached and closed, and the exposure behind it, from overdue receivables and payables to stock and the customers and suppliers affected. A background job that leaves a row, as we argued in every background job leaves a row, is what makes most of these sources possible in the first place.
Eleven alerts with no owner are eleven reasons to assume someone else is on it.
Three questions for your operations lead
What is the oldest unresolved problem in the system right now?
What you will probably hear
It depends which screen.
How to read it
Then nobody can answer the question an owner or auditor asks first.
Who decided the last false alarm was a false alarm?
What you will probably hear
It cleared itself.
How to read it
A cleared alert and a dismissed one look identical later. A closing reason keeps them apart.
When a till closes short, how long until someone reviews it?
What you will probably hear
Whenever the manager next checks.
How to read it
A variance with no deadline competes with everything else on a busy day, and loses.
Our position
Keep the detection where it is: each module knows its own problems best. Put the follow-through in one place, with one clock by severity, an owner on every item, escalation when the clock runs out, and a reason on every closure. Then the Monday-morning question has an answer, and so does the one an auditor asks six months later. If noise is the worry, tune the rule with a reason rather than muting the channel, the same argument as mute the email, keep the alert.
What AWRA OpsHub does today
- One exception inbox for eleven sources, on the web, over the API and in the mobile app, refreshed hourly and when you open it.
- An owner, an acknowledgement and an SLA clock by severity, with escalation every 24 hours past the deadline, up to three levels.
- Triage with a root cause, evidence up to 10 MB and a required closing reason from six.
- Rule tuning with a written reason, and playbooks per source.
- A support handoff that copies only the module, severity, title, summary, date and reference into the ticket.
- A morning digest by role and an executive view of heatmap, backlog age, SLA trend and exposure.
- Digest subscriptions per person or per role, daily or weekly, by email, in the bell or by push, choosing the modules and the lowest severity, so someone who subscribes leaves the default role digest.
- An impact-score override with a reason, kept on the exception and its timeline, and a redaction preview of exactly what a support handoff will carry before it is sent — both in the mobile app too.
More we can add to your workspace
- Escalation to the owner’s own line manager, alongside the escalation that reaches the people who manage the workspace.
- The anomaly radar and the control tower sections as sources, so their findings get an owner and a clock too.
- Deadlines on your working calendar, so a Friday-evening exception does not breach over the weekend.
Where we point you to a specialist
- We will not close an exception on anyone’s behalf because its source cleared. A cleared symptom and a fixed cause are different findings, and only a person can say which one it was.
Deadlines on the working calendar reuse the calendar the support desk already runs on.
Anything above that you need, we can build for you
Everything listed above as something we can add describes what ships in the standard product today — it is a starting point, not a limit on what AWRA OpsHub can do for your organisation. Kenya's eTIMS integration and its maintained payroll engine are both in the product because clients needed them and commissioned them; neither appeared by itself, and the same door is open for whatever you just read about. One qualification so this is worth what it claims: a small number of things on this blog we deliberately leave to a specialist rather than build — a statutory ledger we will not sign our name to, a rule that would decide a tax question for you, a clinical or member-funds record that belongs in a regulated system — and where that is true the post says so in those words. Everything else is a scope, a timeline and a price.
The operational work, which is what most commissions actually are
An extra approval stage in a chain that does not match the standard one, a custom field set on employees or assets that only your sector needs, an expiry that has to block an order rather than send an email, a report your board asks for in a shape nothing produces, or a scanner or weighbridge feeding the goods-in door. These are the commissions we are asked for most often and the smallest ones we quote — and unlike a revenue-authority pipeline, none of them waits on a regulator.
The module-shaped additions, which are the ones readers ask for most often
A price list with real discount authority, a customer-facing quotation that expires, a bill of materials or recipe costing, a staff advance that is issued, acquitted and chased, a member or unit ledger, a matching rule that holds a payment. Each of these is a build rather than a setting, and each has been quoted before — a bigger piece of work than a custom field, with a written spec and a date instead of a roadmap slide.
The report, document or pack nothing currently produces
The board pack in the shape your board actually asks for, a donor or funder layout, an invoice or receipt template carrying what your regulator or your customer expects, a dataset the report builder cannot reach yet. Usually the fastest thing on this list to deliver, because the data is already in the system.
Systems, rails and hardware you already run
The accounting package, CRM, online store, core banking or custom database you intend to keep — connected through our API so a fact is entered once and appears everywhere it is needed. Plus the physical edge: a scanner, a scale, a weighbridge or a till peripheral feeding the door it belongs to.
How it works: you describe the requirement, we return a written scope, timeline and cost, and once agreed it is built into your environment and maintained as part of the product. Nothing here waits on a regulator or a published specification, which is why operational builds are the ones we quote fastest. Tell us the requirement that would otherwise rule us out — that is a better first conversation than a demo.
Tell us what your operation needsSee the Ops Center
Smart Alerts, the anomaly radar, the approvals hub and one exception inbox with an owner and a clock on every problem.
Explore the Ops CenterFrequently asked questions
What sources feed the exception inbox?
Eleven: smart alerts, security incidents, workflow exceptions, connector dead letters, QuickBooks sync failures, offline conflicts from phones, procurement match exceptions, support tickets past their SLA, ledger integrity checks, till cash variances and trash purge failures.
How long does an exception have before it escalates?
It depends on severity: 4 hours for critical, 24 for high, 72 for medium, a week for low and two weeks for information only. Past that deadline it escalates every 24 hours, up to three levels.
Can an exception be closed without a reason?
No. Every closure needs one of six reasons: fixed, false positive, accepted risk, duplicate, handed off to support or no action needed.
Does handing an exception to support expose internal detail?
Only the module, severity, title, summary, opening date and reference are copied into the ticket, with an optional customer and a summary written for them.
Is the inbox available in the mobile app?
Yes. The inbox, each exception and the executive view are in the AWRA mobile app as well as on the web and over the API.
