AcuityQ™ measures response, update and resolution as separate SLA clocks. Each has its own target per priority and its own pause conditions, counted on the working calendar of the desk that owns the case. Cases land on a desk before they land on a person, and an escalation is a rule with a recorded action — not a reminder somebody can ignore.
Screens in this module: My queue · Desks & departments · SLA, clocks & escalation · Routing engine · Customer portal · Bots · Social & omnichannel · Knowledge base · AI assist & guardrails · QA & evaluation · Service analytics
Or open the demonstration estate — seeded desks, live clocks, no form.
My queue
L2 contact centre · 28 openThe panel above is a drawing of the interface and says so on its own face. This frame is for a photograph of the running product, and we would rather leave it empty than fill it with a capture that is out of date or still carries somebody’s name. Everything described on this page can be opened in the demonstration estate today.
What the module does
Nothing here needs a plug-in, a partner or a second licence. It is the module as it ships.
Response is the first human reply. Update is how long a customer may go without hearing anything. Resolution is the work. Each carries its own target per priority. The resolution clock pauses when a case is waiting on the customer; the update clock does not, because you still owe them a status.
A four-hour target is four working hours, not four hours of wall clock. Each desk carries its own calendar — shift patterns, weekly off, and Indian public holidays, including the regional ones a single national list gets wrong. A desk that runs round the clock is given a calendar with no closed hours.
First the desk, on the case category, the channel it arrived by and the customer segment. Then the agent within that desk, scored on skill match, current open load and whether they are on shift. Where scoring is not wanted — a small desk, a deliberately flat rota — round-robin is available instead.
A breach, or a breach that is coming, triggers a defined action: reassign to a named agent, notify a named role, raise the priority. The action happens and is written to the case trail. Nothing depends on a person reading an e-mail in time.
E-mail threads onto a case by reference, so replies join the case they belong to instead of opening a second one. Phone calls are logged against a case by the agent who took them. The portal, WhatsApp and the social inboxes write to the same record. Every inbound either becomes a case or attaches to one.
Every field change, assignment, clock pause and reply is recorded with who, what, from, to and when. Duplicate cases merge and both trails are kept. Cases that are related but not the same are linked without merging, so neither loses its own clocks.
Templates and canned replies are scoped per desk. The collections desk does not have to scroll past the network operations replies to find its own, and an approved wording cannot be edited into something else by one agent for everybody.
How it actually behaves
This is the difference that matters, so here it is as a worked example rather than a claim. One case, one desk, three clocks, and one of them paused.
Worked example — P2 on an operations desk
Example Securities Pvt Ltd · Desk: Operations · Calendar 09:00–18:00, Mon–Fri
The case above cannot move. The customer has been asked for the rejected file and has not sent it. That is a fair reason to stop counting the work — so the resolution clock pauses, and the desk is not penalised for a wait it does not control.
It is not a reason to stop counting the silence. The update clock keeps running, because a customer who has heard nothing since 10:03 does not care whose turn it is. At 14:03 it breaches, and the escalation rule on this desk raises the case to P1 and notifies the desk lead. Both actions are written to the trail with a timestamp.
A tool with one clock has to choose. Pause it while you wait and the case can sit silent for a week inside its SLA; leave it running and every queue looks like a failure. Three clocks is the only way to be fair to both sides of that.
Targets shown are an example. Yours are whatever the contract says, set per priority and per desk.
| Event on the case | Response | Update | Resolution |
|---|---|---|---|
| Agent sends the first reply | Stops — met or breached | Restarts from that reply | Runs |
| Agent sends any later reply | Already stopped | Restarts from that reply | Runs |
| Status set to “Awaiting customer” | Already stopped | Runs | Pauses |
| Customer replies | Already stopped | Runs — only an outbound reply resets it | Resumes |
| Outside the desk’s shift | Paused | Paused | Paused |
| Public holiday on the desk calendar | Paused | Paused | Paused |
| Case reassigned to another agent | Runs | Runs | Runs |
| Case resolved | Already stopped | Stops | Stops — met or breached |
This table is the default, not a fixed rule. Every case status is marked running or pausing, separately for each of the three clocks. If your contract says the resolution clock keeps running while a customer is silent, you can say so — and the page that says so is the same page an auditor reads.
Desks and departments
Every clock above is counted against a desk, so a desk has to be a defined thing — an address, a calendar, a shift pattern, a capacity and a list of names. Without that, the targets are guesses with a stopwatch attached.
Its own inbound address, so mail sent to the desk becomes a case on the desk without a rule having to work out where it belongs. Its own working calendar and shift pattern, which is what the three clocks are counted against. And a concurrent capacity per agent, so routing stops handing work to somebody already holding as much as they are meant to hold.
Agents are mapped to a desk at L1, L2 or L3, and a case climbs the levels of the desk it is already on rather than moving sideways into somebody else’s queue. Each desk names a team leader and a supervisor, and those two are who the escalation rules address — a person holding a role, not a distribution list nobody reads.
Anything matching no desk rule goes to a central unassigned pool that every desk can see, rather than sitting where one team can ignore it. It is a waiting room and not a desk of its own — it holds no targets — and the age of everything in it is on screen. Picking a case out of the pool assigns it. That does not start the clocks; they have been running since the case arrived.
Re-mapping a floor is an upload, not a fortnight of clicking. Agent-to-desk mapping is loaded in bulk when a desk is created, a department is merged or a shift pattern changes across a contact centre. Every row is validated before anything is applied, and the rows that fail come back with the reason rather than being silently skipped. The change is written to the trail like any other.
The routing engine
Routing is the part a buyer is usually asked to take on trust. These are rules the engine runs, close to the words they are written in, because the specificity is the thing worth buying — a rule you cannot read is a rule you cannot audit.
| When this is true of a case | The engine does this | Why |
|---|---|---|
| The destination address is the grievance mailbox or the managing director’s office | Opens at L3 at creation, skipping the ladder. Compliance and the principal officer are copied from the first message. | A complaint addressed to the grievance officer is already an escalation. Making it climb from L1 spends the days that matter. |
| The sender’s domain belongs to a partner bank | The bank’s relationship manager is copied on every reply sent on the case. | The partner reads the same answer at the same time as the customer, so nobody has to be briefed about it afterwards. |
| The customer segment is UHNI | Routed to the privilege pod, and the pod lead is notified at half the resolution target rather than at the breach. | On a committed response time, being told at the breach is being told too late to do anything with it. |
| The case came in from the customer portal or the mobile app | Standard ladder — desk on category and segment, then agent on skill, load and shift. | Arriving through self-service is not by itself a reason to treat a case as more urgent, or less, than one that arrived by mail. |
| The same complaint category, from the same customer, three times in thirty days | Opens at L2 rather than L1. | The third time is evidence that the first level did not fix it. Sending it back there wastes a cycle everybody can see coming. |
| The same customer writes again within six hours on the same subject | Merged into the case already open. No new case ID, no second set of clocks, and the agent holding it is notified. | A chasing message is not a new problem. Counting it as one flatters the volume figures and splits the trail in half. |
| One customer writes from two addresses registered to them | Both are recognised as the same customer, and the case inherits the stronger of the two SLA targets. | Which of their own mailboxes somebody happened to use should not decide what they are owed. |
| A bot’s confidence is under the threshold set for that intent | Handed to an agent with the whole transcript attached, and QA is notified that the intent fell through. | A bot that is not sure should not be guessing — and an intent that keeps failing is a training item, not an incident. |
| An outage parent case is open on the affected service | New cases attach to it as children. The incident commander owns the parent, and the children carry its updates. | One fix, one communication, and a count at the end of who was actually affected — rather than forty separate investigations. |
A rule is simulated before it is switched on. Run it against a sample case and the engine answers with the desk, the level, everybody who would be copied and the rule that decided it — before a single live case is touched. Category and sub-category matching is driven by a keyword master an administrator maintains, so teaching the engine a new phrase is an entry in a list rather than a release.
Bots
Four bots ship with the module and they share one intent library. Each is configured on its own — which intents it may answer, and how sure it has to be before it is allowed to send anything. That threshold is a number you set, per bot and per intent, and it is the whole safety model.
The bot sends the reply itself and the case carries on. QA samples five in every hundred of these after the fact and scores them on the scorecard an agent is scored on, so a confident bot is still a checked one.
The draft goes to a quality-control bucket, and a person approves it, edits it or throws it away before the customer sees anything. The customer is never told a machine hesitated. They are answered a little later, by somebody who read it first.
The conversation is handed to an agent with the transcript carried across, so nobody is asked to type again what they have already typed. QA is told which intent fell through, because that list is the one worth working on.
Those bands are the shipped default, not a fixed rule. A balance enquiry and a complaint about a charge do not deserve the same confidence before a machine speaks, which is why the threshold is set per intent rather than once for the estate. Every handover, every quality-control approval and every discarded draft sits on the case trail with the confidence score that produced it.
AI assist and guardrails
Draft replies are generated from the case, its history and the knowledge base — and then they sit still until somebody sends them. Maker–checker here is not a setting that can be turned off for a busy afternoon. It is the shape of the feature.
Grounded generation only: the draft is written from the case, the customer’s history on it and the knowledge base, and it cannot offer a date, a waiver or a refund the policy does not support. The prompt is assembled from a tokenised copy — account numbers, PAN and the rest of the identifiers are replaced first, so they are never in the model’s context.
AutomaticThe draft is checked before an agent ever sees it: commitments outside policy, wording outside the approved set, answers to a question the case did not ask. A draft that fails is not shown, and the failure is counted rather than discarded.
GuardrailsNothing sends itself. The draft opens in the agent’s editor and stays there until a person sends it, changes it or rejects it. There is no queue depth at which this step is skipped.
GateWhich of the three happened is recorded against the draft, along with what the agent changed. A rejection asks for a reason from a list rather than a free-text box, because reasons on a list can be counted.
Service agentThe edits and the rejection reasons are the input to the next retraining round. A prompt that keeps producing the same correction shows up as a pattern instead of as a hundred separate irritations nobody wrote down.
AutomaticThe value of a drafting assistant is handle time saved per case, so that is what is reported. Beside it sits the edit rate — how often an agent had to rewrite the draft before sending it — and it is shown rather than buried. A model whose drafts are rewritten four times in five is saving nobody anything, and the person paying for it should be able to see that on the same screen as the saving.
There is no figure on this page for what it will save on your desks. It depends on your case mix, your approved wording and the state of your knowledge base, and any number we printed here would be somebody else’s.
Every model in use is listed: version, what it is used for, what it was given, who approved it and when. A model nobody can name is a model nobody can withdraw.
Output is monitored against the same measures over time — acceptance, edit rate, guardrail failures — so a model that quietly gets worse is caught by a measurement rather than by a complaint six weeks later.
Tokenisation happens before the prompt is built, not after the reply comes back. An identifier the model was never shown is one it cannot leak.
Knowledge and quality
Two things usually sold as separate products, which are really the same question: what a good answer looks like, and whether the desk is giving one.
Indexed from two sources: the documents an administrator uploads, and the cases the desk has actually resolved inside a rolling window. The second source is the one that matters — the answer that worked last month is usually better than the manual written two years ago, and it is the one nobody thinks to write down.
Index freshness is reported in minutes: how long ago the index last caught up with what the desk knows. A knowledge base whose freshness nobody measures is one nobody trusts, and an agent given one stale answer stops opening it at all.
Suggestions are reported on acceptance — what share of the articles put in front of an agent were actually used in the reply. It is the only honest measure of whether the suggestion was any good, and it is a number the desk can act on.
Scorecards are built from named, weighted parameters rather than one mark out of ten, so a score can be explained to the person who was given it. Calibration sessions put the same interaction in front of several reviewers and work through the spread, because a score that means one thing on Monday and another on Thursday is not a score.
Accuracy failures — a resolution that was wrong, or one that answered half the question — are counted separately from guardrail flags. They are different problems with different fixes: one is coaching and knowledge, the other is policy and wording. A single quality figure that mixes them tells you to do nothing in particular.
Bot replies are marked on the same scorecard as a human’s — the sampled ones a bot sent on its own, and the ones that fell under the threshold and had to be reviewed. A bot marked on its own scale always looks excellent.
Omnichannel
Somebody who writes in the morning and messages in the afternoon has one problem, so they have one case. The channel is an attribute of a message. It is not the identity of the case.
A case that arrives by e-mail and continues on WhatsApp keeps its case ID, its trail and its three clocks. Switching channel does not reset the response clock and does not restart the update clock — only an outbound reply does that, whichever channel it leaves by. The alternative is a desk that looks faster every time a customer gives up on one channel and tries another.
A direct message is a private conversation and is worked like any other case. A reply to a public post is published where everybody can read it, so it takes the longer road: approved wording, an approver named on the desk, and the whole thread kept with the case. One inbox with one set of rules is how a desk ends up answering a public complaint the way it would answer a private question.
Social items scored as negative are routed to a brand desk rather than into the general queue, on the plain grounds that a public complaint and a public question need different people and different wording. Sentiment decides the routing. It does not decide the answer, and it never closes anything.
Queue depth, the longest wait in the queue at this moment, abandon rate on the channels that report one, and the digital backlog — cast to the display above the floor. It reads the same records the reports read, so the number on the wall and the number in the month-end pack cannot disagree with each other.
Honest limits
Six things buyers ask for that this module does not provide. If one of them is the reason you are looking, we would rather you knew now than in week six of a deployment.
AcuityQ logs a call against a case and links the record your telephony system holds. It does not run the switch, queue the call, record the audio or hold the IVR. Bring your own; the desk keeps the case, not the conversation.
There is no configuration management database, no change management workflow, no asset discovery, and no release or problem record in the ITIL sense. If you need a CMDB with dependency mapping, this is not that product and we will say so on the first call.
Nothing to embed on your website today. The channels that exist are e-mail, phone logged by an agent, the customer portal, WhatsApp and the social inboxes. A transcript from a chat tool you already run can be attached to a case; it cannot be held in one.
Engineer rosters, travel time, route planning, parts on a van, a job card signed at the customer’s site — none of that is here. A case can record that a site visit happened. It cannot schedule one.
There is no unattended mode, and no setting that grants one for a busy afternoon. Every AI-drafted reply waits for a person to send it. If what you are buying is a desk that answers customers without staff, this is not that either.
Edits and rejection reasons are collected, and they are the input to a retraining round somebody decides to run. A model does not change under your desks between Tuesday and Wednesday, and a new version is entered in the register before it is used.
Questions
An agent marked unavailable on the desk shift calendar stops being a candidate for routing, so nothing new lands on them. Cases already assigned are not moved silently — a queue that reshuffles itself overnight is worse than one that does not. A desk manager reassigns them, or an escalation rule does it on a pending breach, which is the case for writing that rule before you need it.
Reassignment never resets a clock. The customer’s response, update and resolution targets are measured from the case, not from whoever is holding it this week.
No — and the reason is worth saying. A desk is the unit that owns a calendar, a set of targets, a routing rule and an escalation path. Two desks sharing one queue means two answers to the question “what was the target on this case”, which is exactly the ambiguity the module exists to remove.
What you can do instead: put an agent on more than one desk, so one person works both queues; and move a case between desks, with its trail intact and the move recorded. If two teams genuinely answer the same work against the same targets, that is one desk with two shift patterns.
From the case trail. Every clock event is a record: started, paused, resumed, stopped, by which status change or which rule, at what time, under which target. Pauses are not a recalculation done at report time — they are events, kept for the life of the case.
Reports read those same records, and an export matches what is on screen rather than being a second calculation that can disagree with it. Because the target in force is recorded on the case when it is raised, a target changed next quarter does not retrospectively turn a met case into a breach.
Nothing advances. The holiday sits on the desk’s working calendar, the calendar is what the clocks count against, and a non-working day contributes no working hours to any of the three.
Calendars are per desk, so a desk in one state can observe a regional holiday that a desk in another does not — the case most national holiday lists get wrong. A desk that is contracted to run on holidays is given a calendar that says so, and its clocks keep counting.
Yes. Targets are configuration, not a build. Someone holding the capability changes them, and the change is recorded with who and when, like every other governed change.
New targets apply to cases raised after the change. Cases already open keep the target they were raised under. That is deliberate: a target tightened on a Tuesday should not breach forty cases that were inside their SLA on Monday, and a target relaxed should not quietly rescue the ones that had already failed.
No. Account numbers, PAN and the rest of the identifier set are replaced with tokens before the prompt is assembled, so they are not in the context the model is given. The agent reading the draft sees the real values, because they are entitled to them and the case is open in front of them anyway.
What each model is given, for what purpose, and who approved that, is what the model register holds. It is the document to hand somebody who asks this question in an audit rather than in a meeting.
Yes, and some desks should. Cases, the three clocks, routing, escalation and the trail do not depend on any of it. A bot is a channel handler you enable per intent; AI assist is a draft button an agent is under no obligation to press.
The reverse is not available. There is no configuration in which a bot reply or a drafted reply reaches a customer without either clearing a confidence threshold you set or being sent by a person.
Tell us the target you cannot currently evidence. We will set it up on a desk and show you the trail it produces. A person replies within one working day.
How QuoteDesk behaves Roles, capabilities and the change trail