Loading
A ticket system can be excellent at holding tickets and still leave a customer waiting a fortnight, because the thing they are waiting for happens somewhere else.
These three follow a request out of support and back again — into engineering, into a contract, onto a van.
Software fails at boundaries. A feature list cannot show you one; a journey has to.
Ticket to fix, breach to credit and request to visit all leave support and come back. Each is a place where a conventional stack drops the thread and the customer notices.
The pattern is the same in all three: the ticket stays owned and open while a real object is created elsewhere — a task, a credit note, a scheduled visit — and joined to it.
Breach to credit is the one that protects the relationship. A remedy decided by contract rather than by persistence is both fairer and cheaper than the alternative.
Not because anyone was careless — because the record stopped at the edge of the tool, and somebody had to carry it across by hand.
Who runs Desk →If your escalations go quiet, read ticket to fix. It is the chain that most changes what support can promise.
If you run engineers, read request to visit — the billing end of it is usually where the money is.
For the work half, yes. Without it a ticket still escalates, but to a person rather than to a tracked task carrying its own history.
About a week, following one real escalation from first reply to resolution and back to the customer.
The boundaries are identical and more painful. The journey is worth tracing precisely because nothing currently records where it crossed.
At entitlement. The first ticket arrives before anyone has recorded what was sold, so the SLA is applied retrospectively or not at all.
Yes, and that is the one people forget. The credit agreed on the call has to reach the invoice, which is the boundary Books reads.
We will run it end to end on your own numbers in half an hour, and tell you honestly which parts Treepie does not improve.