The Alert That Waits in the Bell
Half the people an operations system needs to reach do not read email at work. The storekeeper, the driver, the clerk on a shared login. Why every alert email in AWRA OpsHub now has a twin in the bell, and why the twin is addressed to a person rather than to the room.
Email was designed for managers. It assumes a desk, a personal inbox and an afternoon to work through it. A great deal of operational work happens nowhere near any of those: at a stockroom counter, on a delivery, at a till, on a phone that is opened for one task and closed again. An alert that only exists as an email has already chosen who it will reach.
The people email misses
| Who | Where they actually look | What email does to them |
|---|---|---|
| Storekeeper | The app, at the counter | Nothing — they never open the inbox at work |
| Field officer | The phone app, between visits | A notification lost among personal mail |
| Branch supervisor | The dashboard, first thing | Yesterday’s alert, read after the stock-out |
| Shared mailbox | Whoever checks it, sometimes | Read by one person, acted on by none |
One email, one twin
Every email AWRA OpsHub sends to your own people now also lands in the notification bell of the same people: low stock and batch expiry, approvals waiting, purchase orders overdue for delivery, quotations about to expire, the overdue invoice digest, the HR reminders, scheduled reports and the rest. The twin carries the same fact in one line, with a link to the record, under the same row in the notification settings.
The alert should meet people where they already are, not where the system finds it convenient to put it.
Addressed to a person, not the room
A workspace-wide feed is a noticeboard: everybody can see it, so nobody owns it. Each twin is written to each recipient individually, so “3 items are at or below their reorder level” sits in the bell of the people responsible for reordering and nobody else’s. When an email goes to your organization’s contact address rather than to a person — a sync result, a subscription receipt — the twin goes to the member who signs in with that address, or to your admins if nobody does, so it is never lost because a shared mailbox is not anyone’s login.
Two switches, one row
Because the email and its twin share a settings row, they also share a home for decisions, but they switch independently. A workspace that is drowning in email can switch the email off and keep the bell; one whose team lives in email can do the opposite. Mute the email, keep the alert walks through the combinations, and each person can still choose which categories show in their own bell.
Verdict
If an alert matters, it should reach the people who act on it in the place they already look. For most operational teams that is the app, not the inbox — so every alert needs a twin there, addressed to a person.
What AWRA OpsHub does today
- An in-app twin of every email sent to your own people, for the same people
- Each twin addressed to one person rather than posted to a workspace-wide feed
- Emails to your contact address mirrored to the member who signs in with it, or to your admins
- Email and twin switched independently on the same settings row
- Each person choosing which categories appear in their own bell
More we can add to your workspace
- A daily summary of unread bell notifications sent to the people who missed them
- Bell notifications grouped into one line when the same alert repeats
Where we point you to a specialist
- Emails to suppliers, customers and website visitors have no bell twin: they are people outside your workspace, with no bell to put it in.
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 needsWho is your email missing?
Who acts on stock and delivery alerts?
Ask
Usually not the person who reads the email.
Then
Make sure the bell is on for those rows.
Which alerts go to a shared mailbox?
Ask
The organization’s contact address.
Then
Check that an admin sees the twin.
Does anyone open the app but not email at work?
Ask
Storekeepers, drivers, field staff.
Then
For them the bell is the alert.
Put every alert where your team looks
Every alert email in AWRA OpsHub has a twin in the bell, addressed to the person who acts on it.
Talk to usFrequently asked questions
Does every AWRA OpsHub email also show in the app?
Every email sent to your own people also arrives as a notification in the bell of the same people, with a link to the record. Emails to suppliers, customers and website visitors do not, because those people have no bell in your workspace.
Who sees an in-app notification for an email sent to our general address?
The member who signs in with that address. If nobody does, your workspace admins receive it instead.
Can I keep the in-app notification and stop the email?
Yes. The email and its in-app twin share a row in the notification settings, and each switches on and off independently.
Can everyone in the workspace see each other’s notifications?
No. Each in-app twin is addressed to one person, so it appears only in the bell of the people the email went to.
