Who to call back first, and why a ticket reached nobody

The customer-facing end of a business asks questions with somebody waiting on the answer: a customer on the phone, a queue at the till, a complaint that is about to become a review. Those are the questions where “let me pull a report and get back to you” loses the moment. Here are three, with what Rutba Assistant reads to answer them while the person is still there.

“Who should I call back first?”

A salesperson with an hour before lunch. The assistant reads the follow-up queue, most overdue first, then the full timeline of the top contact — every call, email and note, with comments beside them — and that customer’s account position:

GET /crm-activities/followups
GET /crm-activities/timeline?contact={contact}
GET /acc-invoices/statement/customer/{customer}

The last call is the one a CRM usually cannot make. The customer statement lives in Books, and CRM reads it rather than keeping a copy — which is why the answer can say “call this one first, but know that they are sixty days behind on two invoices” before the salesperson rings about a renewal. If the salesperson holds no role that reaches the statement, the assistant says that part is outside what they can see, rather than leaving it out silently.

The same thinking reaches the till. Before a large order on account, one call asks the forward-looking question — would this sale put the customer over their credit limit — rather than only reporting where they stand:

GET /customers/{customer}/credit?adding={orderTotal}

“Why did this ticket reach nobody?”

A support lead, the morning after a customer complained that nobody answered for a day. The assistant reads why routing found nobody available, the ticket’s service-level clock, and the load across the desks:

GET /helpdesk/routing/availability
GET /helpdesk/tickets/{ticket}/sla
GET /helpdesk/tickets/summary

The first call is the one that turns “routing did nothing” into an answer. It runs the same checks the router runs — and reports them instead of applying them. So the answer is not a guess about staffing; it is the router’s own reasons for passing over each person it could have chosen. The service-level call adds when the ticket was due, when its clock was paused and why, and whether it has breached.

One detail in Helpdesk shows why the assistant is built to read through the product rather than beside it. An employee who raised an internal request reads its thread through a self-service call that returns the public thread only, with internal notes stripped in the database — not hidden by the screen. The assistant, asking as that employee, reads the same call. It cannot repeat a note it was never sent.

“Why was till two short at close?”

A shop manager cashing up. The assistant reads everything that went through that till during the shift — sales, refunds, payouts and cash drops — the payments taken on it, the returns, and the audit trail on the sales in question:

GET /cash-register-transactions
GET /payments
GET /sale-returns
GET /sale-audit-logs

The audit trail is readable by managers and administrators only, so the cashier who asks the same question gets the shift’s transactions and is told the audit trail needs a manager’s access. The manager gets the lot, and an answer that points at the entries that explain the difference — a refund with no return against it, a payout nobody recorded a reason for — each with its source.

Where it hands back to a person

• Anything that reaches a customer. A reply, a reminder, a message about their order — what goes out in your name is yours to send. It is on the short list of things Rutba Assistant will never be allowed to do.
• Refunds, credit notes and write-offs. Each is a change to what a customer owes, so each is a plan a person approves, never a side effect of asking.
• Reassigning tickets. The assistant can tell the lead why routing failed. Moving the ticket is a click the lead makes — or a plan they approve.