Escalation Assumes There Is Somebody Above You
The breach alarm notifies the agent, then their manager, then the department. In a six-person business the agent is the manager, there is no department to fall back to, and the escalation is an email telling you what you already knew.
Escalation is a word borrowed from organisations with layers. It means handing a problem to somebody with more authority, and it quietly assumes that such a person exists and is not already holding the problem.
The chain
When a ticket breaches, this product builds a list of who to tell, in three steps.
-
The assignee, if they have a login
Straightforward, and the qualifier matters: staff without company accounts are ordinary in the businesses this product was built for, so the chain cannot assume one.
-
The assignee's manager, through the employee record
Deliberately resolved from the employee rather than the user, so it works even when the agent has no login of their own. This is the best-designed part of the chain.
-
Everyone in the department — but only if the first two found nobody
A fallback, not an addition. Telling a whole department every time a named agent runs late is how an alert becomes a mail rule people stop reading.
That is a careful design and each decision in it is right. It is also a design for an organisation with a shape.
What happens when there is no shape
In a small business the assignee often has no manager — either the field is empty or it points at somebody who is also the assignee. And because the department fallback runs only when the first two steps produced nobody, an agent with a login and no manager produces a list of exactly one name: their own.
The escalation is then an email to the person who already knows, about a deadline they already missed, containing no information they did not have.
An escalation that reaches only the person who was already responsible is not an escalation. It is a reminder, and reminders are what people filter.
Who the chain reaches, by organisation shape
| Situation | Assignee | Manager | Department |
|---|---|---|---|
| Agent with a login and a manager | Yes | Yes | No |
| Agent with no login, with a manager | No | Yes | No |
| Agent with a login, no manager | Yes | No | No |
| Agent with no login, no manager | No | No | Yes |
| Unassigned, with a department | No | No | Yes |
| Unassigned, no department | No | No | No |
Built and maintained Configurable by you, not maintained by us Not built
Row three is the small-business case and the one worth planning around: the alarm fires, it is correctly recorded as delivered, and it reached one person who was already looking at the ticket.
The last row, and why it is survivable
A ticket with no assignee and no department has nobody to tell, and the product says so rather than pretending otherwise. This matters because of what it used to do instead.
The alarm used to stamp the ticket as notified whether or not anything had been sent, and its own query skipped tickets already stamped. So a breach nobody heard about was recorded as handled and could never be raised again — the tickets most likely to breach were exactly the ones the alarm was permanently blind to.
Now the notifier returns how many people it actually reached, and the marker is written only when that is not zero. A ticket nobody could be told about stays unmarked and is retried, so the alert fires the day somebody is assigned or joins the department. The command also prints a warning naming how many breached tickets had nobody to tell.
What a small team should actually do
Set the department on every ticket, even when you also assign it. It costs nothing and it is the only link in the chain that does not depend on a hierarchy you do not have.
And accept that in a team of six, the alarm is a record rather than a control. What actually governs a small desk is a person looking at a list once a day — so make the list good: unassigned first, oldest first, and the breached ones visible without a filter.
What AWRA OpsHub does today
- A three-step breach recipient chain: assignee, then their manager through the employee record, then the department as a fallback.
- A manager lookup that works for agents with no login of their own.
- Alarm methods that report how many people were reached, so a breach nobody heard about is retried rather than recorded as handled.
- A warning printed by the scheduled check naming how many breached tickets had no recipient.
- Two independent deadlines with separate markers, so neither silences the other.
What it does not do
- Any escalation that changes the ticket — no reassignment, no priority change, no re-queueing.
- Any alert before a deadline passes.
- A named escalation contact per department or per category, independent of the reporting hierarchy.
- Round-robin or load-based assignment.
- Any awareness that the assignee and the manager are the same person.
Not ours, by choice
- The chain is well built for an organisation with a hierarchy, and this page is about the case it does not fit rather than a criticism of the design.
- For a very small desk, an alarm is a record and a daily look at a list is the control. We would rather say that than imply the software is managing the queue.
- Nothing here is Caribbean-specific in a legal sense. The region is here because small teams are the norm, which is exactly the shape a hierarchy-based escalation chain has nothing to escalate to.
What is not built for Jamaica today can still be built for you
Anything described above as not built is a statement about what ships in the standard product today — not a limit on what AWRA OpsHub can do in Jamaica. Kenya's eTIMS integration and its maintained payroll engine exist because Kenyan clients needed them and commissioned them; neither appeared by itself. The same door is open here. If a tax rate that follows the class of supply, dated rate changes, a Jamaican payroll engine, a bank or mobile money feed, a statutory return format, a rule your own operation needs that the standard one does not have, or a link to a system you already run is what stands between you and a decision, tell us and we will scope it as a build — written spec, timeline and price — before you commit to anything.
A rate that knows what you are selling
The General Consumption Tax has a standard rate, a higher rate on telephone services and handsets, and a reduced effective rate in tourism. Our per-organization rate table can express a country, a region and a city — three columns of geography — and nothing about the class of supply, so a business outside the standard rate carries one correct default and sets the rest by hand on each line. The build is a dimension this data model does not have, and it is worth knowing it is not a Jamaican special case: the same missing column is what sub-national rates would need elsewhere, so it gets built once. Alongside it, rates that start on a date, for the tourism change announced for April 2027 and every one after it.
Banks, payments and counters that share a ledger
Statement feeds and local payment rails into the Payments Register, with retail counters, contract sales and invoicing posting to one set of books rather than three that get reconciled monthly.
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.
Payroll and statutory returns
A Jamaican payroll engine with income tax tables, NIS and NHT computed on live employee records, producing the schedules in the layout the authority expects.
Systems you already run
The accounting package, CRM, online store or custom database you intend to keep — connected through our API so a fact is entered once and appears everywhere it is needed.
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. No roadmap slide, and no pretending in a demo that something exists when it does not.
Tell us what you need integratedFour questions about escalation in a small team
Who is told if the assignee has no manager?
A good answer sounds like
A named fallback contact.
What it actually means
Ours tells the assignee only, because the department step runs only when the first two found nobody.
Can I nominate an escalation contact directly?
A good answer sounds like
Yes, per queue.
What it actually means
Reporting lines and escalation paths are different things, and most systems conflate them. Ours does.
What is recorded when nobody could be told?
A good answer sounds like
Nothing, and it retries.
What it actually means
The alternative is a false record of an alert, and that was our own defect.
Does escalation move the ticket, or just the news?
A good answer sounds like
They are clear either way.
What it actually means
Ours moves the news. Knowing that stops you building a process that assumes otherwise.
Our position
Put a department on every ticket — it is the one link in the chain that does not need a hierarchy — and treat the breach alarm as a record rather than as the thing that runs your desk. If you want an escalation contact that is not somebody's line manager, that is a small build and a sensible one for any organisation flatter than three layers.
Ask who the second recipient is
Every escalation chain has one, and in most products it is a reporting line rather than a choice. Find out which before you rely on it.
Talk about support escalationFrequently asked questions
Why is the department a fallback and not always notified?
Because telling a whole department every time a named agent runs late trains everybody to filter the message, and then it does not work on the day it matters. It is the right call and it is the reason the small-team case falls through.
Can an agent without a login still own tickets?
Yes — the ticket carries both an employee assignee and a user assignee, because in many organisations a large share of staff have no company account. That design is why the manager lookup goes through the employee record.
Does the manager get told for every breach?
Where one is recorded, yes, in the same alert as the assignee. There is no delay or tiering between them — both are notified at breach, which is simpler than a ladder and means the manager hears about it at the same moment as the agent.
