Service is working with requests: tickets, deadlines, queues, the knowledge base, the client portal. Here it matters above all to lose nothing and not to lie in the report: the client is waiting for an answer, and the manager needs to see where the service stalls. The product runs this work strictly and honestly, and you watch and give commands.
One ticket model
A ticket is a request that needs work: fix, configure, answer, sort out. As in communications, the channel here is merely a property: an email, a form on the site, a chat, a call, the portal — everything turns into a ticket of one kind. And the “door” through which an approach enters the service is a setting: you can say that emails to this address become tickets, and emails to another stay ordinary correspondence.
A ticket has a clear life path: new, in progress, waiting for the client, waiting inside, resolved, closed. A closed one can be reopened if the problem returned — and that will be visible.
The ticket and the conversation
The ticket and the correspondence are linked but do not duplicate each other. The approach stays a conversation, while the work on it becomes a ticket with deadlines and an owner. The ticket card shows the correspondence itself, and the conversation shows that a ticket was opened for it. Thanks to this the client does not have to repeat the story, and the employee does not have to reconcile two lists.
Queues, routing and assignment
Tickets are laid out into queues — by topic, by client, by urgency. The routing rules are configured as data: “tickets about hardware — to this group”, “urgent — to the person on duty”. There is always one owner and one queue — this rule is not broken, so there are no tickets “between everybody”. If a ticket was redirected or handed over, a record stays: who, when, from which queue to which and why. The routing rules can be tested “dry”: the product will say who a ticket goes to and show why exactly them.
Classification
A ticket can be given a type and a category — this helps both in reports and in the work. But an important rule holds here: an unclassified ticket is normal. No need to invent a category at random to “close the field”: the unknown stays unknown, and hints can be added later. The type and category lists are protected from accidental deletion — statistics are computed over them.
There is a hint for the employee too: the product proposes a possible category and priority, explaining what the proposal is based on. The decision is still the human’s — the hint only saves time.
Internal and public messages
A ticket has two kinds of messages: those only employees will see (an internal note) and those that go to the client. The split works on the server side, not “on trust”: an internal note physically cannot get into an email to the client or onto their portal page. This kills the most unpleasant service mistake — the client accidentally receiving the internal discussion.
Deadlines and terms (SLA)
Service deadlines are a rule: how much time is given for the first answer and for the resolution, depending on the client and the type of approach. It is arranged honestly:
- The rule is fixed at intake. Whichever rule fit the ticket at the moment it arrived is the one that holds to the end — it cannot be swapped after the fact.
- Working hours count. Nights, weekends and holidays do not “eat” your term: a work calendar is set, and the countdown follows it.
- Pauses only by state. When we are waiting for the client, the counter stops; an automatic service message does not count as a pause.
- A breached deadline is a fact. It is recorded in the ticket’s history, not hidden in an average indicator.
- There is a warning ladder. The term is near — a signal; breached — a signal to management; with sensible pauses between steps, so the notifications do not turn into noise.
Macros and bulk actions
Frequent answers are saved as drafts: one press — the text is inserted, only the details remain to add. For groups of tickets there are bulk actions: assign, change status, apply a draft. It is built with mistake protection: before applying, it is visible what exactly will happen and to which tickets, and failed lines do not cancel the whole job — they land in the report while the rest are processed.
Working together
A hard ticket is worked together: you can call a colleague by mention, subscribe observers, hand the ticket over or split it into parts when two different problems sit inside. All of it is recorded in the history, so it is clear who did what.
The knowledge base
Answers that repeat are worth writing down once. Knowledge-base articles are gathered into categories; they have a state (draft, under review, published, archived), a revision term and a readership. The product hints the fitting article to the employee by the ticket’s topic, helps insert its text into the reply, and shows whether the article really helps — whether people read it and whether the approaches get resolved afterwards. This way the knowledge base does not turn into a dump of non-working instructions.
The client portal
The client has their own entrance into the service — separate pages with their own access. There they see their tickets and correspondence, can leave a new request by form, look through the service catalogue, receive reports and exchange documents. Access is strictly bounded: the portal never shows anything from the internal work or other people’s data — all of it is restricted before the page opens.
The portal is a separate world, not a cut-down office: the client does not see the internal screens and cannot get into them. This is built apart and deliberately, so nobody has to hope they “won’t click”.
Client surveys
After a ticket is resolved you can ask the client about the service — a short survey. What matters is that the score has consequences: a dissatisfied client does not remain a line in a report; it is visible what exactly went wrong, and they can be contacted. This way you collect feedback that actually gets used.
Service metrics
The service indicators — first-response time, resolution time, the share of met deadlines, reopened approaches — are computed by published formulas. Next to every number it is visible what it is made of: which denominator, which tickets went in. And there is a matter-of-principle decision: the product does not build employee ratings. The metrics exist to understand where the process bottleneck is, not to punish people for hard tickets.
Client health
A separate screen shows clients who have piled up warning signs: many approaches, dissatisfied scores, payment delays, a lull in communication. Every “red” sign has an owner — it is clear who should take it on. It is a way to notice a leaving client before they leave, instead of learning about it from a churn report.
Shift planning
Service is people, and people have schedules. The product shows the current load, a forecast by weekday (when approaches are traditionally more numerous) and lets you lay out the shifts. This is needed so that on Monday morning it does not turn out that all the approaches are waiting for one person.
Major outages, problems and changes
When something breaks not for one client but for everybody at once, it is convenient to open one incident and link all the tickets to it. Then the scale is visible, and the deadlines on such tickets are not counted as overdue for each employee separately — honestly, since the outage is shared. Repeating outages grow into “problems” and “known errors”: the written-down solution becomes a knowledge-base article. And planned work is run as changes with approval stages — so a fix is never a surprise.
Client equipment records
A client can keep a list of equipment and other service objects: what is installed, when it was bought, where it sits. Then the ticket shows what exactly it is about, and the service engineer knows in advance what they are dealing with. The list uploads from a spreadsheet and is kept together with the history of approaches per unit.
Service contracts
If the client is under a service contract, the product checks the right to service before counting deadlines: by the contract, its validity term and the included services. Hours are tracked separately: how many the contract grants and how many are already spent, with the option to buy an extra pack. If the hours run out, the product says so instead of silently counting for free.
Field service
Site visits are handled separately: a visit has an object, a time, a scope of work and three separate time counters (for example, travel, work, paperwork) — so it is visible where the time goes. Scheduled inspections can be put on a timetable, and they turn into tasks by themselves.
Partners
Partners can be given their own entrance: they register clients and tickets, while the product makes sure two partners do not bring in the same client, and passes the tickets into the shared work. This way a partner network runs on the same data as your own department, without separate spreadsheets.
Add-ons
Service is eight independently switchable add-ons: the service itself, deadlines, the knowledge base, the client portal, surveys, equipment records, service contracts and the partner portal. You can start with tickets and deadlines and switch the rest on later. Without any one of them the others keep working instead of falling over entirely.