Cases
A customer problem is more than a ticket.
A case has a type, an owner, a customer, a related invoice or order, a commitment, a target and a timeline — including the part of the work that happens in Finance, Engineering or somebody's approval queue.
Half of support is not done by support
Refunds need Finance. Bugs need Engineering. Contract changes need an approval. A ticket system that only models the conversation loses that half into private messages.
Five types, not one
A question, a problem, a request, a complaint and an incident-related case need genuinely different handling. One generic ticket type hides that difference and the handling gets improvised.
Resolution is a record, not a status
What was actually done, by whom, with what evidence. That record is what makes the next identical case faster and what makes an article possible.
In this area
7 pages under Cases.
Each one is its own surface in the product, and each one is here because it does something the others do not.
What a case holds
Customer, contact, category, owner, related records, commitment, target.
ReadThe five types
Question, problem, request, complaint, incident-related.
ReadThe timeline
One readable account of everything that happened, internal work included.
ReadPriority
Urgency from the customer's situation, not from the tone of the message.
ReadInternal actions
The work support cannot do alone, tracked on the case.
ReadApprovals
Who may authorise what, before the customer is told.
ReadResolution
What was actually done — the record the next case reads.
ReadThe rest of Resolivo
This is one part of one loop.
Take better care of every customer.
Give your team the context, knowledge and AI they need to resolve problems properly — and know who needs attention before they ask.
Keep the mailbox you already use · The AI is never metered · [email protected]