Customer ticket management, from the responder’s side
The life cycle of a support request in six steps, from arrival to closure. None requires configuration, a rule to write or a field to invent: this is how the software works as soon as the workspace is created.
-
The request arrives
Through one of two channels: the portal for people with access, or a public form at your dedicated address, open to anyone.
-
It receives a code
Readable and different for every project: SUP-A-1, ASS-B-42. It is the reference people quote on the phone.
-
It is assigned and prioritised
One owner, always. Priority remains readable in black and white: the bar grows with urgency.
Low Medium High Critical -
Work continues in one conversation
Customer-visible messages and internal notes the customer never sees live in the same thread. Attach files up to 20 MB and preview images and PDFs directly in the browser.
Elena Rossi customerThe delivery note prints without item rows.Marco Bianchi agentI’ll look at it now. Can you confirm the document number?Internal note — not visible to the customerCustom print template since 2024. Fix the template, not the data.Status changed to In progress —A ticket interface with a customer message, an agent reply, an internal note and a status change.
-
It moves through statuses and records an outcome when closed
New, in progress, waiting for the customer, waiting internally, closed. The outcome is resolved or cancelled. A closed request can be reopened. If your team says “Being handled”, call it that: statuses and labels use your words.
Open In progress Waiting Closed -
Search finds it again
Search requests, messages and attachment names. Results only include what the person searching is allowed to see.
Interface representation built with the same statuses, counters and criteria as the product dashboard.
You decide how long a request may wait
For every status, you can define how long is too long: time to first reply and time in progress. When time is nearly up or has expired, the person who must reply is notified.
- Enable targets project by project. Where you do not need them, they do not exist. New projects start without response targets.
- Different times by status and priority: an urgent request does not wait as long as a normal one.
- A warning before expiry, not only afterwards: in the portal and by email, to the ticket owner — or administrators when nobody has taken it yet.
- Waiting for a customer reply has its own separate time and is normally left unset: a slow customer does not become your delay. Customers never see that a target was missed.
Hours are continuous, not business hours: twelve hours starting on Friday evening expire on Saturday morning. Alerts remain alerts — the software does not close, reassign or change priority for you.
Practical questions about ticket management
- Does the customer need to register?
- No. They can submit a request from the public form, verify their email and continue from the protected link they receive.
- Can every agent see every ticket?
- No. Projects, departments and assignments determine what each person can see; search applies the same limits.
- Are response targets mandatory?
- No. Enable them only for projects that need them. They remain alerts: the software does not close or reassign requests for you.
- Can a closed request be reopened?
- Yes. Closing also records an outcome, but the ticket and conversation remain available and the request can return to progress.
Try it at your own address for three months.
No credit card.