Basic and Professional in detail. Professional includes everything in Basic – without limits. The table below lays out every feature for both licenses at a glance.
Feature
Basic
Professional
Customization & administration
Multilingual: 30 languages can be enabled; translations run through export and import of a JSON file – so you get exactly the wording your house understandsManual
Date and time format of your installation is yours to choose – order, separator and a 24- or 12-hour clockManual
Maintenance and outage notice for everyone – on the login page, optionally by e-mail as wellManual
login page only
login page + e-mail
Early warning before the disk fills up: a notice from 90%, a warning from 95% – whoever manages updates sees the figures and what to do, signed-in users get a short sentence; nothing of it appears on the login pageManual
Archiving of closed tickets (incl. restore) – keeps the working set small, e.g. by moving an old year into the archiveManual
Update at the press of a button – the system takes a backup first (data, attachments, archives) and checks that there is enough free disk space; if there is not, it refuses the update with a reason instead of failing halfway throughManual
Export and import your master-data lists as JSON – departments, positions, sites and categories; fill them in one go instead of typing line by lineManual
Local login (username/password) + JWT; two-factor sign-in (TOTP with recovery codes) is optional – off, mandatory for staff only, or mandatory for everyoneManual
SSO via OIDC (OpenID Connect) / OAuth2 and SAML 2.0 – connecting providers such as Google Workspace, Microsoft Entra ID, Okta, Keycloak, Auth0 or ADFS – plus LDAP / Active Directory and LINE, Kakao, Naver, WeChat, WeCom and DingTalkManual
On the first SSO sign-in the account is created automatically (as a customer, using no staff seat); every SSO sign-in is loggedManual
Ticket management
Create and edit tickets; deletion happens only through the archiveManual
Rich-text editor: renders inline images and links (description & comments)Manual
File attachments with preview (PDF viewer, image zoom, up to 50 MB per file)Manual
Status workflow with configurable statuses & transitionsManual
Priorities, statuses, roles, sites, positions and departments are configurableManual
Main and sub categories are freely configurable per teamManual
How the ticket came in: the system detects the customer portal and e-mail by itself (e-mail requires Professional). Phone and created by an agent are entered by the agentManual
Applies to tickets from the e-mail inbox as well; tickets assigned by a person are never touched, and every automatic assignment is recorded in the ticket historyManual
Report: who received how many tickets – and how often nobody was availableManual
Requests with tasks & approval
A request is a ticket that creates its own tasks – one ticket per item, in the team that handles it; approvals are possible, but not requiredManual
The requester ticks what they need while creating the requestManual
Progress on the request: “3 of 5 done” – each task with its team, assignee and a click into its ticketManual
One approval for the whole request – one e-mail instead of many partial approvalsManual
An extra approval stage for single, sensitive tasksManual
Approvers decide through a time-limited link sent by e-mail. They need no account in the ticket systemManual
Reminders for open approvals – never an approval by timeoutManual
A rejection reaches the requester, with the reason givenManual
Audit trail on the ticket: who decided when, with which commentManual
Approver on holiday? An admin reassigns the request – every change is recordedManual
Reply & ticket templates
Reply templates: text + field actions (status, assignment, priority …) in one pickManual
Suggested actions individually deselectable before sendingManual
Placeholders (requester, ticket number, title …) – inserting the template puts the real values into the text, before anything is sentManual
Reply optionally sent as email to the requester – only the sending needs the mail channel; the template’s attachments are added to the ticket in every editionManual
Create a template straight from an existing ticketManual
Drafts stay private until published; scoped per team or globalManual
Ticket templates: new-ticket form prefilled (title, description, category, priority, team)Manual
Ticket templates can be released to customers per template — a ticket that arrives already qualified can shorten the handling timeManual
Follow-up on a ticket by hand (date + note, filters Today/This week/Overdue)Manual
Time-based rules – reacting to the ABSENCE of an actionManual
WHEN/IF/THEN rule builder with a live plain-English sentenceManual
Four example rules included (switched off on installation, enable whichever you like)Manual
Preview before you switch it on: shows which tickets the rule would affect right now – without changing anythingManual
Actions: e-mail, status, priority, assign, hand over to another team, set a follow-upManual
Time spans selectable per condition: in business hours and business days from the team calendar – or running around the clockManual
Log per rule + the rule name as the author in the ticket historyManual
Monthly run quota
unlimited
unlimited
Bulk actions on the ticket list
Change the status of several tickets at once – further fields via a reply templateManual
Several tickets can be assigned to one agent at onceManual
Reply templates can be applied to several tickets at once – placeholders are resolved per ticketManual
Preview before running and a result afterwards: how many of the selected tickets the action applies to and why individual ones were skipped – skipped tickets stay selectedManual
The e-mail to requesters is off by default; switch it on and the dialog states how many recipients it would reachManual
Every bulk change appears in the individual ticket history – naming the agent who triggered itManual
Multiple reports & outages
Merge two reports from the same person into one ticket – comments, attachments and the description move along, nothing is deletedManual
If someone replies by e-mail to the old ticket number, the reply lands in the merged ticketManual
Guard: tickets from different people cannot be mergedManual
Bundle many reports about one outage under a single incident – every report keeps its requester, status and deadline, and one answer reaches everyone affected with their own e-mailManual
Incident shown as a banner and noted in the automatic reply – the banner disappears by itself once the incident is resolvedManual
SLA, calendar & escalations
SLA policies with deadlines for first response and resolutionManual
Business-hours calendar per team (own time zone, several windows per day)Manual
Public holidays via .ics import or entered manuallyManual
Clock pauses while waiting for the requester (configurable per deadline)Manual
Time remaining in the ticket list – sortable, with a filter for breached deadlinesManual
On breach: notify, or hand the ticket over to another team automaticallyManual
SLA metrics in reporting (achieved rate, breaches, average time used)Manual
Time tracking per ticket
Can be switched on or off per team; off by defaultManual
Log effort per ticket – configurable quick buttons (e.g. 15m, 30m, 1.5h) or free input (rounded by the rounding rule where one is switched on)Manual
Stopwatch on the ticket – it proposes the elapsed time and the entry is only created once a human confirms it; opening another ticket pauses itManual
Several agents can log time on the same ticket – every entry carries its date, note and the name of the agentManual
Billable / non-billable per entry – time is logged once; the ticket shows both totals: everything logged and the billable sum (ticked entries only, after rounding)Manual
Bill to the minute or round up – configurable (increment and minimum per entry, e.g. 15-minute blocks), to the minute by defaultManual
Logged and billed time stay separate – changing the rounding never falsifies past dataManual
Require a time entry before closing – off by default; it applies only when a person changes the status, never to auto-close, merging or bulk actionsManual
A “Time” column in the ticket list – it appears as soon as time has been logged on a ticket in the listManual
Report by requester, team, category and custom field – bill by company or cost centreManual
Export of individual entries: CSV and Excel for accounting (both complete) and PDF to hand over, e.g. to the customerManual
Customers never see logged time – the record travels with the invoice as an export (PDF recommended), not onto the ticket in the customer portalManual
Per-agent breakdown can be switched off – off by default, enforced on the server instead of merely hiddenManual
Reporting & dashboards
Dashboard with the current picture: tickets per status, the three oldest open cases, distribution per agent and per categoryManual
A dashboard of its own per team – each team sees its own picture, with its own permissionManual
Freely filtered report – period, team, status, agent, requester, site, priority, main and sub category, channel, full text; filters combineManual
Filter and group by your own fields as well – company, cost centre, contractManual
Which columns the report shows is configurable per role – a customer gets a different view than an agentManual
Customers can pull their own report – limited to their own ticketsManual
Export as CSV, Excel and PDF – Excel with two sheets (key figures and tickets), charts are in the PDFManual
The PDF prints the figures next to the charts – a picture alone cannot be checkedManual
CSV and Excel are complete; the PDF stops at 20,000 rows and shows this in the documentManual
Satisfaction surveys (CSAT)
After the ticket is closed: an e-mail with a star rating, one click is the whole answerManual
No customer account needed – the link works without signing in, a comment is optional, and the rating appears on the ticket for the team that handled itManual
Report: average, satisfaction rate and response rate – including the closed tickets that were never askedManual
The per-agent breakdown of ratings can be switched off and is off by default – the individual rating on the ticket is always visible to the teamManual
Configurable limit – from every ticket down to at most once a weekManual
A poor rating can trigger an automation ruleManual
Knowledge base
Topic tiles with rich-text articles and file attachmentsManual
Visibility per topic: internal only or customer-facingManual
Suggested solutions while a ticket is being createdManual
Turn a ticket into an article at the press of a buttonManual
Entries by an agent wait for the admin’s approvalManual
Change history across entries and topics (for admins)Manual
Backup & restore
The installation sets up the daily backup itself (23:00) – kept are 14 days, 4 weeks, 12 months, 4 quarters and 5 years, and backups you created by hand are kept for good; your changes to the schedule survive an updateManual
Scheduling through the operating system itself – Task Scheduler on Windows, cron on Linux; no extra serviceManual
The backup runs without anyone logged on – cron on Linux, and on Windows a service that also starts on a signed-out machine; no Windows password is ever requestedManual
The backup covers everything that makes the state: the database, file attachments, the archive and the keys that decrypt stored credentialsManual
A restore therefore brings everything back. As a rule the system is ready to work again shortly afterwardsManual
A dedicated application for backup and restore, for Windows and Linux, with a desktop shortcut – create a backup, browse the list, restoreManual
On a server without a desktop the same functions as commands – back up, list, restore, set the scheduleManual
Backups sit on the same machine – they protect against mistakes and other trouble, not against a disk failure; for the worst case please keep the backup files somewhere else as wellManual
Before every update the system takes an additional backup of its own – independent of the scheduleManual
includednot includedAll information refers to the current version 1.x.
A closer look
Features where a single table row does not say enough.
Requests with tasks & approval
Professional
Some requests are not one request but half a dozen. “New colleague starts on Monday” means: Windows account, mailbox, ERP access, phone, badge — each handled by a different team, each with its own owner, and the line manager has to say yes first. Today somebody types that in five times and then chases it by walking around. Here you set the flow up once: the requester fills in one form, the system creates the individual tickets in the right teams, collects the approval, and shows you in one place what is already done.
One request, many tasks
Each item becomes its own ticket — in the team that handles it, with its own owner, its own running time and its own instructions. Two tasks may go to the same team: a service desk that looks after three applications gets three tickets, not one with three bullet points. The request itself shows “3 of 5 done”, every line jumps into its ticket, and the request closes last.
The requester picks WHAT they need – not who does it
For each task you decide whether it always runs, comes pre-ticked, or has to be ticked on purpose. In the form the requester simply sees a list of what can be ordered — your team structure stays out of it. And “which application belongs to which team” needs no second set of master data to maintain: it sits on the task itself.
One approval, not eight
The approval belongs to the request, not to the individual task. Eight requested accounts therefore trigger one e-mail to the line manager instead of eight — that is the point where flows like this usually die in daily use. If one sensitive task also needs a yes from a specialist department, you attach a second stage to that task alone. Both are asked at the same time, and if the department says no, only its own task is affected; the rest carries on.
The line manager needs no account
They get an e-mail with a link, see who asked and which tasks are covered, and decide with one click — no sign-in, and without taking up an agent seat. The e-mail deliberately carries only that one link and no ready-made “approve” address: virus scanners and preview services open every URL in a message, and an approval created that way would be indistinguishable from a real one. Rejecting requires a reason — and the requester is told what it was.
Nothing happens before the release
The tasks appear immediately so the specialist teams can see what is coming — but they are locked, nobody is assigned to them, and they cannot be moved while the approval is missing. That is enforced on the server, not just greyed out: bulk actions and automation rules get no way around it either. If nobody reacts, a reminder goes out — there is no approval by timeout, because that is exactly what an auditor takes issue with later.
Who decided when stays on the record
Every stage is listed on the request with approver, timestamp and comment — the audit trail such flows are introduced for in the first place. Nobody can approve on somebody else’s behalf, not even an administrator. For holidays there is reassignment instead: an administrator sends the open request to a stand-in, the old link dies immediately, and the history records who moved it from whom to whom, and when.
The tenth password reset of the week does not need a freshly written answer — it needs the good answer your team already wrote, sent in seconds and without the typos that creep in at 4 pm. A reply template fills in the text AND the routine that goes with it: set the status, assign it to me, put a follow-up on it. You stay in charge of the send button.
Text and the routine around it, in one pick
A template does not just paste text. It suggests the field changes that always go with that answer: status to Resolved, priority down, assign to me, follow-up in three days. Each suggestion is shown as its own chip and can be struck out individually — this ticket is almost the standard case, except this time you do not want to close it yet.
Nothing is sent until you send it
Picking a template only fills the editor. The text sits in front of you, you edit it, and you send it with the same button as always. A macro that fires immediately sends the wrong answer to a real customer the moment you misclick — and an email cannot be unsent. This one extra second is deliberate.
Placeholders you can trust
Write "Hello {requesterName}" once, and every application fills in the right person, the ticket number, the title, your name. Resolved the moment you pick the template — so the finished text is what you see in the editor, not a surprise in the customer's inbox. A mistyped placeholder is rejected when the template is saved, not discovered by the customer.
The answer reaches the requester by email
One tick and your comment goes out as an email — to the person behind the ticket, which the system works out for you. Attachments stored on the template are added to the ticket at the same time: put the how-to PDF there once instead of hunting for it in your downloads folder every time.
Good templates come from real answers
The best template is the answer you just wrote. One click on a comment turns it into a draft template — with the text prefilled and the customer's name, address and files deliberately left behind. You name it, read it once with fresh eyes, and only then does it exist. Until you publish it, nobody else sees it.
Ticket templates: recurring tickets without the typing
Onboarding a new employee, decommissioning a device, the caller on the phone — some tickets are created again and again with the same shape. A ticket template prefills the form: title, description, category, priority, responsible team. The agent adds what is specific and submits. Nothing is created until they do.
Team knowledge, not a private stash
Templates belong to a team or to everyone — not to one person's drawer. When someone leaves, their best answers stay. And every application is recorded in the ticket history: weeks later you can still see that a ticket was resolved with the standard reply, and which one.
Included in both editions
Templates are fully included in Basic — no cap on how many, no feature behind the higher edition. The tools that save your team the most everyday time should not sit behind a paywall.
Most things go wrong in a helpdesk not because somebody did the wrong thing, but because nobody did anything. A ticket waits for an answer that never comes; a request sits unassigned over lunch; a case is resolved and then simply forgotten. Automation reacts to exactly that — to the absence of an action. It checks every minute and does what you would have done yourself, if you had noticed.
Four rules are already there — switched off
You do not start with an empty screen. The system ships with four examples that cover the everyday cases: remind the requester after three business days of silence; close a ticket after ten days without any reply; raise the priority of a ticket nobody has picked up within four working hours; and put a follow-up on anything that has seen no activity for a week. All four are switched off. Turn one on, adjust the numbers, or use it as the starting point for your own.
You pick, you do not write
Every value comes from your own data: your statuses, your priorities, your teams, your categories — chosen from a list. There is no field where you type a field name, no query language, no cron expression. A rule reads WHEN something has not happened for a while, IF the ticket looks like this, THEN do that.
The rule tells you in plain English what it will do
Above the editor a sentence keeps up with your choices: "When a ticket has the status Waiting for User Response and has had no reply from the requester for more than 3 business days, then send an e-mail to the requester." Read it back before you switch anything on. That one sentence catches the misconfiguration you would otherwise notice on a closed customer ticket.
See who it would hit — before it hits them
Every rule has a "which tickets would this affect right now?" button. You get the list, and nothing else happens: no e-mail, no status change, not even a log entry. This is the step that makes the difference between trying it and never daring to.
A reminder does not turn into a flood
"No answer for 24 hours" is true again every single minute from hour 24 onwards — built naively, that is 1,440 e-mails a day. A rule therefore fires once per situation and then holds still. It fires again only after the condition has cleared and occurred again: the customer replies, it goes quiet once more, and only then does the next reminder go out.
Working hours count, not calendar days
"Three business days" uses the same business-hours calendar as your deadlines, per team — a ticket from Friday evening is not overdue on Monday morning. If you would rather count plain elapsed time, minutes, hours and days are there too. It is your choice per condition, not a global setting.
No run quota, ever
Some systems bill automation by the run: a monthly allowance, and once it is used up every rule you have stops until the first of the month. There is no such counter here. The only limits are safety catches per ticket so that one rule cannot wake another in a loop — they exist to protect your tickets, not to meter you.
Nothing happens invisibly
Every action is written into the ticket history with the name of the rule that caused it, so nobody has to wonder why a ticket closed itself. Each rule also keeps its own log: which ticket, when, and what the result was — including the failures. And if a licence lapses, the rules stay exactly where they are and simply stop running; the page says so instead of going quiet.
Follow-ups by hand are in every edition
Setting a date and a short note on a ticket to bring it back later — "call again on Thursday" — is part of Basic, including the Today / This week / Overdue filters in the ticket list. Requesters never see it. Professional is the step from your agents setting follow-ups to the system setting them for you.
Two situations that look identical in the inbox and have to be handled in completely different ways. One: the same person reports the same problem twice — once by e-mail and once by phone, because they were not sure the e-mail had arrived. The other: a switch fails, and within fifteen minutes there are thirty reports from thirty different people. There is a way for each, and they are deliberately two different ways.
The same person, two tickets
You tick both rows and decide which ticket stays — the older one is preselected, so the deadline runs from the first contact instead of the second attempt. Comments, attachments and the description of the second one move into the first; nothing is lost. Before you confirm, it is spelled out for you: "#124 will be closed and moved into #122."
One outage, thirty reports
You group the thirty tickets under a single incident ticket. Every one of them keeps its requester, its status and its own deadline — none of them disappears. Latecomers can be added one by one, and anyone opening a new ticket while the incident is running is offered the link instead of having to look for it.
Why these are not the same thing
If you simply merged those thirty reports, twenty-nine people would lose their ticket and never hear anything again. And because twenty-nine cases would be closed without ever receiving an answer, your figures would afterwards look better than reality. So the system checks who is behind each ticket: if they are different people, it does not offer merging at all and points you to the incident instead.
Answer once instead of thirty times
Once the cause is fixed you write the resolution a single time. Every linked ticket gets it as a comment and is closed, and every affected person receives their own e-mail — no distribution list, nobody sees anybody else's address. If someone still replies afterwards, their ticket is reopened, not the whole incident.
Nobody loses their ticket number
A merged report is never deleted. If the requester replies to the old e-mail weeks later, their answer still finds the right ticket — whether they reply to the message, leave the old number in the subject, or both. Otherwise they would believe their reply had been delivered while it sat in a closed case nobody looks at.
The banner clears itself
An incident can be announced with one tick: it then appears for everyone as a banner and as a note in the automatic reply — someone reporting by e-mail never sees a sign-in page. When you resolve it, the banner disappears by itself. A maintenance window announced for Saturday stays visible next to it instead of being pushed aside.
An SLA is a promise: "we reply to a request within two hours, and we resolve it within eight". The ticket system takes that promise apart, puts a clock on every matching ticket and tells you how much time is left — before the deadline passes, not afterwards.
Deadlines only run during your working hours
An eight-hour deadline that starts on Friday afternoon must not expire on Saturday morning. That is why every deadline is tied to a business-hours calendar: opening hours per weekday, its own time zone, several windows per day for lunch breaks or split shifts — including night shifts that run past midnight. Every team can have its own calendar; nights, weekends and public holidays do not count.
You decide the public holidays, not we
Public holidays depend on where you are, not on the language you use — 16 German states, 26 Swiss cantons, 50 US states. Instead of shipping a list that will eventually be wrong for your region, you import the official .ics file for your location or enter days by hand. The import then tells you how many days were taken over and how many were skipped. If a calendar has no closed day at all for the next twelve months, the settings page says so — otherwise the system would quietly calculate straight through every holiday.
What counts as a reply — and what does not
This is where the metric either means something or does not. The first-response clock stops only on a public comment written by an agent. The automatic acknowledgement does not count, internal notes do not count, and the incoming customer email certainly does not. Built any other way, every deadline would be "met" within seconds and your reporting would show a permanent 100% while in fact nobody had answered.
Waiting for the customer pauses the clock
When you ask a question back and wait for the requester, the deadline stops running — you are not charged for waiting time you do not control. Whether a deadline pauses is set per target, because the answer is not necessarily the same for "first response" and "resolution". If a resolved ticket is reopened, a new cycle starts; the old one stays on record for reporting instead of marking the ticket as breached straight away.
When a deadline is breached
You decide per deadline what happens: just record it, notify the assignee and the watchers, or hand the ticket over to another team automatically — the classic escalation from 1st to 2nd level. Handing over is deliberately not the default, because it moves responsibility and releases the assignee; that should not take anyone by surprise on the first breach. Whatever you choose runs exactly once, even across a restart.
Which deadline applies to which ticket
You create policies and put them in order; the first matching one wins. Conditions are team, priority and category — dropdowns, not a query language you have to learn first. An empty field means "any", not "none": a policy without a team applies to every team.
What you see afterwards
Remaining time right in the ticket list, sortable by "expires first" and filterable to "breached", plus the deadline on the ticket itself. Reporting shows the compliance rate, the number of breaches and the average time used per deadline. The rate counts decided deadlines only — still-running ones do not dilute it, otherwise every newly introduced promise would look disastrous at first and improve all by itself.
Until you create a policy, nothing changes
With no active policy there is no clock, no extra column appears, and your existing tickets stay exactly as they are. No preset target, no old cases breached overnight. Tickets without a deadline show a neutral dash — not "breached".
Anyone who bills for effort needs to capture it where it happens: on the case. An agent types "20" or hits a preset, and at the end of the month the totals are ready by customer, cost centre or contract — as a table on screen and as CSV for the invoice. What this deliberately is NOT: a clock-in system. It records effort on a case, never the attendance of a person.
Typing beats any stopwatch
The main route is quick entry: four freely configurable buttons and a field that understands "90", "1.5h" and "1h 30m" alike. On a three-minute case, two clicks on a stopwatch cost more than the number itself. If your sessions run long, switch the timer on as well — it proposes, and nothing is stored until a human confirms it.
Logged and billed stay separate
You set the rounding increment and the minimum freely — in 15-minute blocks, 17 minutes become 30. But only the billed value is rounded, always per entry, never across the total. What was actually worked stays untouched, so you can change the rounding later without past months shifting retroactively.
Bill by company, cost centre or contract
The report groups time by requester, team, day — and by any custom field you have created. That way you bill by exactly the term your organisation uses instead of one we invented. The page shows the largest groups and says so when it truncates; the CSV export of individual entries is never truncated, because an invoice total taken from a shortened list is not incomplete, it is wrong.
The period means the work, not the ticket
A ticket from June that was worked on in July belongs in the July invoice with those hours. That is exactly how the report cuts it — by the date of the entry, not by when the ticket was created. It sounds obvious, and it is the very point where a monthly invoice otherwise quietly goes wrong.
Several agents, fully traceable
Every entry carries a date, an author, a note and the billable flag. Who may change other people's entries, and who may still correct them after closing, are separate rights — because whoever changes other people's time changes other people's invoices. When two tickets are merged the time moves with them; it should not be left behind on the closed twin.
Per-agent evaluation can be switched off
Time per person is performance and behaviour data. That is why the per-agent breakdown is its own switch, off by default — and the block sits in the server, not just in the display. With the cloud vendors this evaluation cannot be switched off at all; for an organisation with a works council that is the difference between rolling it out and negotiating first.
Your customers do not see the time
By default the logged effort stays internal. "Five minutes — for that?" is a discussion nobody wants, and it only starts because the number was visible. If you want it otherwise, release the field deliberately; the default does not make that decision for you.
Switchable, per team as well
Time tracking is off by default — if you do not need it, you see no field, no column, no tile. Once enabled every team takes part and you exclude individual ones: the internal IT team need not log, the customer-facing service team does. If you want, make a time entry mandatory before closing; automatic closures stay unaffected, otherwise tickets would exist that nobody can close.
In the end only one person knows whether your helpdesk did a good job: the one who was helped. After a ticket is closed they get an e-mail with five stars — one click and it is done. The rating then goes where it belongs: onto the ticket, in front of the person who did the work, and into the report as a number. Surveys are off until you switch them on; you decide whether and when anyone is asked.
One click, nothing more is asked
The e-mail carries five stars as links. Clicking the third one is the whole answer — no account, no sign-in, no form spread over two screens. Anyone who wants to can add a sentence on the page that follows, and those sentences are usually the most interesting part of the whole report. A mis-click on the wrong star can be corrected while the link is valid.
The response rate sits next to the average
A 4.6 means nothing until someone writes next to it that it rests on twelve answers out of four hundred. So the report shows both — and alongside them the number of closed tickets that were never asked at all. A figure that hides its own sample is worth less than no figure.
Measure without monitoring your staff
Ratings per person are performance and behaviour data — in many companies a matter for the works council. Here, evaluating by agent is a separate switch, off by default, and it is enforced on the server: off means off, in the export too. The rating on the individual ticket stays visible regardless, because the colleague who handled the case is the first person who can learn from it.
Nobody gets buried
Each ticket is surveyed at most once. How often the same person may be asked is up to you – by default at most once within seven days: someone who reports five things in one morning then gets one e-mail instead of five. A customer desk with many different senders sets the limit to zero and asks on every ticket. If a ticket is reopened shortly after closing, none goes out at all — the question comes only once the case is really over.
An outage does not distort the number
Reports attached to a group incident are deliberately not surveyed. One click on "incident resolved" would otherwise fire two hundred surveys about a single piece of work, and the month would end up describing the outage rather than your service. The incident itself is asked; the two hundred affected people are not.
A bad rating is a case, not a data point
One star does not belong in next week's summary — it belongs on the desk the same day. An automation rule can react the moment the rating arrives: raise the priority, assign it to the team lead, send a mail. Same rule engine, same handling; the rating is simply one more condition.
The link grants a rating, not a reading
The survey page shows the ticket number and title and nothing else — no description, no comments, no attachments. Links like this get forwarded or land in a shared mailbox; whoever holds it may rate, not read along. After 30 days it expires, and from the outside expired and unknown look exactly the same.
Virus scanners do not rate either
A star link that counts on mere retrieval gets clicked automatically by the link checkers of the large mail providers — the score would then be pure invention and indistinguishable in the database from real answers. Here, opening the link only displays the page; nothing is stored until a human is sitting in front of it. For them it is still just one click.
