Manual

You create a new ticket with “New Ticket” in the left-hand bar. The form is called “Create new ticket”. As an agent you also record other people’s requests with it — that is what the “User” field is for: it says who the case is for, not who is typing it in.

Everything with a star is mandatory: “Title”, “User”, “Main category” and “Description”. One more that is easy to miss: the form will not save without a subcategory, even though “Subcategory” carries no star — a main and a sub category belong together and are always set as a pair.

Which fields are mandatory is set under “Settings → Ticket Settings”. The “Admin / Agent Field Settings” card only has the “Field is mandatory” switch for this. The “Customer Field Settings” card also has “Is hidden for Customer” and “Is not editable”. That is why a customer can see a shorter form than you do, without anyone having to maintain two forms. “Title” and “Description” are always mandatory. That cannot be switched off.

Afterwards you can change nearly everything: on the right of the ticket sits the “Details” card with requester, phone, e-mail, location, category and reference number; you change the field itself and confirm with the “Save” below it. Status, assignment, priority, channel and observers sit one card higher under “Actions”. Status and assignment take effect immediately. Priority, channel and observers are only saved with the “Save” in the “Details” card.

Only agents and administrators may change this. The requester can read the case, comment on it and attach files — but not change the classification your reporting is built on.

One side effect worth knowing once: if you edit a ticket that belongs to nobody yet, it belongs to you afterwards. The system enters you as the agent and moves the status from “Open” to “Assigned” — both end up in the history. If you did not want that, assign it to somebody else afterwards.

Every one of these changes lands in the ticket’s history, with name, time, old value and new value. You do not have to switch anything on for that.

That leaves the question of how to get rid of tickets again. Under “Settings → Archive” you pick a date range, see with “Preview” how many closed tickets it contains, and create a ZIP file with “Create archive”: tickets, comments, history, custom fields and attachments, all in one file. Creating it removes nothing. The tickets only leave the live database with the separate step “Delete from live DB” in the “Existing archives” list — and they can be restored from that same file.

The description and the comments are not bare text boxes. Each has a toolbar above it, and the buttons say what they do when you point at them: “Bold”, “Italic”, “Underline”, “Strikethrough”, “Text color”, “Highlight color”, “Bullet list”, “Numbered list”, “Quote”, “Link” and “Clear formatting”.

This is how a link is made: select the text, click “Link”, type the address into the small prompt. An empty entry removes the link again. Web and mail addresses are allowed (http, https, mailto) — everything else is thrown away when saving, so that a comment cannot slip anything past anyone.

Images come in through the clipboard: take a screenshot and paste it straight into the editor with Ctrl+V. At first the text only shows a marker such as “[inline-image:1]”. When you save, the system uploads the image and displays it exactly there — and it also lands in the “Attachments” tab, where all files of the case live. Pasting images works in the description of an existing ticket and in a new comment. It does not work in the “Create new ticket” form or while you edit a comment.

What you see is what the others see: formatting, lists and links are kept in the ticket, and in the mail to the requester as well. Foreign markup — from a copied web page or an incoming e-mail, say — is trimmed back to this allowed set. None of your text is lost in the process, only the wrapping.

A comment can be marked internal with “Internal note (not visible to the customer)”. It then carries the “Internal” badge and is invisible to the requester — not even the search will surface it.

Everyone can change and delete their own comments. What a customer wrote can only be changed or deleted by that customer or by an administrator. That includes their mails. Comments by colleagues can be changed and deleted by every agent who may work on the ticket. That includes a team that had the ticket earlier.

Files belong to the case, not to a single comment. On the ticket the “Attachments” tab leads to the list: “Upload file” adds one, every row names the file, its size and its date. Anyone involved in the ticket may attach something — the requester included; so nobody has to mail you their screenshot. A customer can only delete attachments they uploaded themselves. When a child ticket is closed, its attachments are copied into the parent ticket, where they carry the “Internal” badge. Agents see them; customers neither see nor download them.

A click on the name opens the preview, without you having to download the file. For images you can zoom in, zoom out and rotate in there — useful for a display that was photographed at an angle. A PDF is displayed in the same window, with page overview, zoom and print. Text files are shown as text. With “Open in new tab” you open the file in a window of its own.

An attachment belongs to the case and travels with it: it appears in the history (“File uploaded: …”), survives a handover to another team, and ends up inside the archive file when the ticket is archived.

The “History” tab on the ticket answers the question behind every follow-up: who changed what, and when? Every row names the person, the field, the old value struck through, the new one behind it and the time down to the second. The newest entry is on top.

Entries are written without your doing — on status changes, priority, assignment, category, location, observers, title and description, as well as on creation (“Ticket opened”), on every comment and on every uploaded file. The number on the tab tells you in advance how much movement there was in the case.

The history cannot be edited and cannot be switched off. That is exactly what makes it useful: it is the reason a ticket cannot be deleted one by one, and it travels into the archive file when the ticket is archived.

For a comment, the history only records that it was added, edited or deleted. The wording lives in the “Comments” tab. An internal comment shows up in the history as well, but only for agents and administrators.

The status says where a ticket currently stands. Twelve statuses ship with the system — Open, Assigned, In Progress, Waiting for User Response, Resolved, Closed and more. You find them under “Settings → General Settings” in the “Drop-down lists” section behind the “Status” tab; “+ Add status” creates one of your own, “Edit status” opens an existing one.

The important part is the difference between the name and the meaning. In the editor of a status, under “Meaning of this status”, there are three switches: “Counts as resolved”, “Counts as closed” and “Waiting for the requester”. Only these switches tell the system how to treat a status.

You may rename every status, including the ones that ship with the system: at the bottom of the editor, under “Translations”, there is a “Name” field per language — put in there what your people should read. The technical name behind it stays untouched, and that is exactly why nothing breaks: automation, reporting and the switches above hang on that name, not on your label. So “Resolved” can become “Done”.

Deleting, however, does not work for all of them. Eight statuses carry the “Mandatory” badge in the list — Open, Assigned, In Progress, Resolved, Closed, Reopened, Waiting for approval and Rejected. They can be renamed and reordered, but not removed; trying it ends with a clear message. That is not there to annoy you: processes hang on them that would otherwise quit without a word — for example the automatic closing, which needs a “resolved” status as its starting point.

Two statuses belong to the system itself: “Waiting for approval” and “Rejected” carry the “System only” badge. They come out of an approval process, and nobody should be able to claim by hand that something was rejected which never went up for decision.

What the three do: a status that counts as resolved closes the ticket by itself after 24 hours. A status that counts as closed is the final state the ticket is moved into. And “Waiting for the requester” means exactly that: we are waiting for the requester — not for another team and not for a service provider. That is the flag the SLA clock stops on, if you set it up that way.

Below that sits “Allowed transitions to new status”. Here you tick which statuses can be reached from this one. Leave everything empty and nothing is restricted; tick something and every other path is closed. That is how you build a flow that cannot be skipped — for example: from “Open” you can only go to “In Progress” or “Assigned”, but not straight to “Closed”.

The remaining switches in the editor are small things with a large effect: the colour for the list, “Sort order” for the order, “Show status in new ticket form” (should this status be selectable when creating a ticket at all?), “Requires comment in dialog” (force a reason) and “System only” for statuses only the system itself may set.

Up to four statuses appear on the ticket as buttons under “Change Status to:”. You choose them in the editor with the “Set as primary status (max. 4)” switch. As a factory setting these are In Progress, Waiting for User Response, Waiting for Service Provider Response and Resolved. All other statuses are under “More statuses”.

Everything that shows up as a drop-down in a ticket belongs to you. Under “Settings → General Settings” sits the “Drop-down lists” card with six tabs: “Department”, “Position”, “Location”, “Role”, “Status” and “Priority”. The handling differs from list to list.

One by one: type the English name into the empty field and click the button next to it — it is named after the list, so “+ Add location”, “+ Add department” and so on. The rows below are the existing entries. In “Department”, “Position” and “Location” that is where you change a name and confirm with the “Save” next to it.

For many entries at once “Department”, “Position” and “Location” also offer “Export JSON” and “Import JSON”. On a freshly installed system you download the empty structure with “Export JSON”, fill it in and import it again. It is not a way to rename things — the card says so itself.

Some entries carry the “Mandatory” badge. The three roles “Admin”, “Agent” and “Customer” are among them, eight of the statuses that ship with the system, and one placeholder each in the Location, Position and Department lists (“None selected or available”). None of them can be deleted: permissions and processes hang on them that would otherwise quit without a word. The statuses can still be renamed in their editor. The roles and the placeholders cannot be renamed. What is allowed depends on the list. “Role” is locked: a role can neither be added nor renamed. In “Priority” you add and delete entries, but there is no file and no renaming. “Status” has its own editor and no file either.

You do not translate into the other languages here, but in one go on the translation page. The English name is enough here — it is the anchor the translations attach to later.

The status is the only entry with an editor of its own, because more hangs on it than a name; it has its own card further down.

Categories are what the requester or the agent picks when creating a ticket — and what you group your reports by later. Every team has its own: a helpdesk sorts by different things than a network department, and neither sees the other team’s lists.

You find them under “Settings” as the entry “<team name> Categories”. In the example the team is called “Helpdesk”, so the entry reads “Helpdesk Categories”.

The page has three cards: “Main categories”, “Subcategories” and “Links”. The quickest start: type the English name into the “EN (required)” field and click “+ New main category” or “+ New subcategory”. You translate everything later in one go on the translation page — nothing to prepare for that here.

If you have a lot of categories ahead of you, take the file route: “Export JSON” downloads the structure — on a freshly installed system the file is empty and only shows you the layout. You fill it in (by hand or with the help of an AI), save it and upload it again via “Import JSON”. It is not a way to rename things: you change a name in the field of that category and confirm with the “Save” next to it — the page says so as well.

The third card, “Links”, is where the actual work happens. Pick a main category at the top, tick the subcategories that belong to it below, and save with “Save links”. The trick: one subcategory may hang on several main categories. So you only need “Malfunction” once and re-use it for Printer, Network, Meeting-Room and Notebook.

From then on the categories are available in the ticket. Deleting can fail while tickets are still using a category — that is on purpose, otherwise old tickets would lose their classification. If you remove a link, tickets that use that pair can still be saved. Only a newly chosen category is checked against the links.

If you hand a ticket over to another team, its classification stays — even when the new team does not have those categories at all. It then sits in the field together with its origin, for example “Meeting-Room · from Helpdesk”, and is greyed out: the new team can see what the case ran as so far, but cannot assign that entry itself. To re-sort it you pick from your own list — and the system then wants a main and a sub category together.

Every ticket carries a channel. It sits in the form and later on the “Actions” card under “How the request came in”, and it answers a question that becomes important in reporting quickly: does the work arrive through the portal or over the phone?

You can only choose what a person knows and the system does not: “Phone” and “Entered by an agent”. The other two values are set by the system itself — “Self-service” when the requester created the ticket in the portal, and “E-mail” when it grew out of an incoming mail. When an agent creates a ticket, the form starts with “Entered by an agent”.

A channel the system has set cannot be changed by anyone later on. The field then says “Recorded by the system. It cannot be changed.” Otherwise the field would lose exactly the statement it exists for. The other way round, on a ticket recorded by phone you may still change everything else.

Only an agent or an administrator may set the channel. For the requester it would be a statement about their own case — and the reporting would depend on everybody being honest.

“E-mail” requires a connected mailbox, which is part of the Professional edition. The other three channels exist in both editions.

Above every ticket list there is the “Search tickets…” field. It does not only search titles but the whole case: title, description, the requester’s name, e-mail address and phone number, location, reference ticket number, all comments and the text values of your own custom fields.

The example shows it: “coffee” appears in no title, only in the description of one ticket — and it is still found. So you do not have to remember how a ticket was titled; one word from the case is enough.

Upper and lower case do not matter. The search always applies to the list you are currently in and can be combined with “Filter” next to it; “Reset” clears search and filters again. The list remembers your filters, separately for each team list. They are still set when you come back from a ticket, reload the page or sign in on another computer. The search text is not remembered. For customers there is a limit you cannot see but should know about: they do not search internal comments — otherwise they could infer from the result list what was discussed internally. Nor do they search custom fields that are hidden from customers.

Everyone puts together their own ticket list. For this, the “Columns” button sits next to “Filter”. It opens the “Choose columns” dialog.

In the dialog you tick every column you want to see. The arrows next to it set the order. “#” and “Title” are always included. You change the width of a column in the list itself by dragging the edge of its header.

“Save” stores your choice with your user account. It therefore applies on every computer and stays after you sign out. “Default columns” restores the list to its factory setting.

When there is not enough room for all columns, the ones on the far right drop out first. “#”, “Title” and “Status” always stay. So you move what matters most to you to the front.

With Professional, your custom fields are on offer as well. They appear in the dialog under their own name, here for example “Asset tag”.

Customers can set up their list the same way but are offered fewer columns. “Team”, “Created by”, “Last activity”, “Status changed at”, “Deadline”, “Follow-up” and “Time” are not available to them. Fields you have hidden from customers do not appear as a column either.

On a smartphone the button is not shown. There the list shows the columns that fit.

The ticket offers two buttons side by side for this, and the difference is printed underneath in small type. “Involve another team”: you stay responsible, the other team works alongside you in a linked ticket. “Escalate to another team”: the other team takes over.

When you hand over, responsibility moves without a second ticket coming into being. Your team keeps read access and may still comment, but can no longer change anything — which is exactly what the dialog tells you before you confirm. You pick the target team there and can add a reason.

When you involve a team, your ticket stays in your hands and gets a child ticket in the other team. Yours moves to the status “Waiting for other team”; once the other team closes theirs, yours comes back as “Back from other team”. So you do not have to ask whether anything happened over there. The child ticket’s attachments are copied into your ticket with the “Internal” badge, and the customer does not see them.

As for the classification: the categories of the handing-over team stay on the ticket, even when the new team does not have them at all — they show up there with their origin, greyed out. That way the new team can see what the case ran as so far, and re-sort it into its own list if needed.

Only whoever is responsible right now may hand a ticket on. An earlier station still sees the case but cannot pass it along a second time. It can comment, but it cannot take the ticket back to itself.

In your team’s list the ticket then shows “Waiting for other team” for as long as the other team is working on it. The “Also show tickets this team handed over” tick is on as a factory setting, and each user’s own choice is kept. For the other team the ticket starts as “Open”.

Whoever escalates becomes an observer of the ticket. The dialog says so before you confirm. As an observer you get an e-mail when the status changes, the ticket is closed or someone comments. Like any observer you remove yourself with “Stop observing”.

When a piece of information is missing from your tickets — the asset tag, the end of the warranty, the cost centre — you add it yourself. Under “Settings → Ticket Settings”, at the bottom, sits the “Custom fields” card; the button is called “Add custom field”.

In the dialog you give a name and a field type: “Text”, “Multiline text”, “Integer”, “Decimal”, “Date” or “Yes / No”. The type decides what can be entered — a date field will not take “next week”, and that is exactly why you can report on it later.

Under “Scope” you decide where the field applies: “All teams (including new ones)” or “Selected teams only”. The first choice also covers teams that do not exist yet — the kind of difference you only notice half a year later.

The three switches under “Defaults” are “Mandatory by default”, “Hidden for customer by default” and “Not editable by customer by default”. They only apply to a field as long as nothing has been saved for that field in the field settings on the same page. Once you set it there, the field settings decide.

On the ticket the custom fields sit in a card of their own, “Additional information”, between the description and the comments. Without a template the form shows all custom fields of the team. If you pick a template when creating a ticket, it shows exactly the fields that template lists, in its order — “only the fields this case needs”.

A template can make a field mandatory on top of that. What the administrator hid from customers stays hidden, even when a template lists it. A mandatory field that a template does not list is not asked for, so that requirement does not apply to tickets created with this template.

How many custom fields a team may have is set under “Settings → General Settings” in the “Custom fields limit” card. You get rid of a field with “Deactivate”: it disappears from the form, but its values stay on the old tickets — the “Show deactivated” switch brings it back into the list.

Sometimes somebody should follow a case without working on it: the team lead on a delicate matter, the colleague who takes over next week. That is what observers are for. On the ticket the “Observers” field sits on the “Actions” card, the button is called “Add observer”; the “Create new ticket” form has the same field. On the ticket a change there is saved with the “Save” in the “Details” card.

Only agents and administrators of the team the ticket belongs to can be picked. A customer cannot be an observer — they would otherwise receive mail about internal work.

An observer receives an e-mail when something happens on the ticket: a new comment, a changed status, a new assignment, changed fields. It is not sent immediately but bundled: after the last change the system waits a minute and then sends ONE mail covering everything that happened in that time. So working through a ticket in one go does not trigger seven mails. If several comments come in during that time, all of them are in the mail.

Who observes is part of the history: a change is recorded like any other, with the old and the new state.

Entering observers is part of Basic. The mail to observers is part of Professional, because it needs outgoing mail. Without it you can enter observers, but nothing goes out. An observer can remove themselves with the “Stop observing” button. That needs no right to change the ticket.

An observer is also added by itself: whoever hands a ticket on with “Escalate to another team” becomes an observer. That way they learn what the other team does with it.

When two people work on the same ticket at the same time, the later save could overwrite the earlier one, and nobody would notice. That is why the ticket shows who else has it open. It also refuses a save that is based on an outdated state.

The notice sits in the header of the ticket. “Marco Rossi is viewing this ticket” means that Marco has the ticket open. “Marco Rossi is actively editing this ticket” means that Marco has unsaved input on it. That can be a started reply, a comment being changed, the title or the description in edit mode, a follow-up, a custom field or a time entry. Changed fields in the “Actions” and “Details” cards count as well, as long as they have not been saved with “Save”. An open window on the ticket counts too. These are the windows “Involve another team?”, “Escalate to another team?”, “Close ticket”, “Resolve incident” and “Start a workflow”, plus the window for the comment on a status change. After two minutes without input there, the notice shows “viewing” again, even if the draft is still there.

If several colleagues have the ticket open, the notice sums them up, for example “Marco Rossi and 2 more are viewing this ticket”. Point at the notice to see all names. As soon as someone is actively editing, the line only counts the people who are editing. You never see yourself. If you have the ticket open in two tabs, you count once. If the ticket is only open in a hidden tab, you drop out of the others’ notice after about a minute.

When a colleague saves a change, the notice reads “Marco Rossi changed this ticket”, with the “Refresh” button next to it. A new comment from someone else shows “Marco Rossi added a comment”. If no person made the change, for example an automation rule or an incoming e-mail, the notice reads “This ticket was changed”. The notice stays until you refresh.

“Refresh” loads the current state of the ticket, such as status, assignment, fields and history. It does not reload the whole page. Your unsaved input stays. A started reply stays in the reply box, and an open title or description keeps your text. If the saved text has changed in the meantime, “The saved text has changed in the meantime.” appears below the field. If you save then, your text replaces the saved one. The “Refresh” button in the header of the ticket does the same.

If you save on an outdated state anyway, the save is refused. The window “Ticket changed in the meantime” opens. If a person made the change, it names them. Your change has not been saved. Click “Refresh”, check your change against the current state and save again. This applies to every change to the ticket itself, for example status, assignment, priority, the “Details” card and custom fields.

Comments are never refused. Two replies do not overwrite each other. Both end up on the ticket. The same applies to attachments and time entries. Bulk actions on the ticket list and automation rules are not checked against the state either. They change the ticket directly. Whoever has it open sees the notice afterwards.

Customers see none of this. They do not appear in the notice. They also do not see who is working on their ticket.

Who has a ticket open is only held in the server’s memory. About a minute after the person has left the ticket, the entry is gone. None of it is written to a log. The ticket stores who changed it last. That entry is part of the data export for that person. When the person is anonymized, it is removed.

The mail channel is one road with two directions, and they belong together: an incoming mail turns into a ticket, your reply goes out as mail, and the requester’s answer lands as a comment on the same ticket — not on a second one.

The matching is not done by feel: a reply only lands on the existing ticket when the mail carries the case’s reference in its subject or brings the reply headers of the mail program with it. A mail with neither starts a new case — better one ticket too many than two unrelated cases merged just because the subject happened to match.

Everything for it sits under “Settings → E-Mail Settings”. The upper card, “SMTP settings”, is the way out: host, port, “Use SSL”, user and password, plus the sender address and sender name. With “Send test e-mail” you send yourself a sample — save first, then test, as the card says itself.

The “IMAP settings” card is the way in: host, port, the poll interval and the two folders. You do not have to guess the folder name: “Read from server” fetches the folders that actually exist in your mailbox, “Create on server” creates a new one. The field then takes the path your mail server uses for it — one server writes “INBOX/Processed”, the next one “INBOX.Processed”, and both mean the same thing.

The “Processed folder” takes the mails the system sets aside: mails from blocked senders, automatically generated mails, and mails a workflow moves with “Move to folder” without a folder of its own. Leave it empty and they stay in the inbox. Below that you set when the cleanup runs (“Hour”, “Minute”) and how old a message may get (“Retention (days)”) — otherwise the mailbox quietly keeps growing.

Mailboxes belong to the team, not to the system: under “Team mailboxes” each team enters its own address with a password. That address is at the same time the sender of that team’s mails — so the requester replies to the same place the mail is collected from.

And now the part without which none of this happens: the workflow. A configured mailbox on its own does nothing at all. If a team has no enabled workflow, the mailbox is not even polled — no ticket, no confirmation, the mails just sit there. The automatic reply to your customers exists only here, and you set it up yourself. That is on purpose: a system that writes to every sender address unasked would be worse than one that stays quiet.

Under “E-Mail workflows” you pick the team at the top and create a workflow with “+ Add workflow”. It gets a name (for you only), an “Enabled” switch and two statements about when it applies: “Match” decides whether all conditions must be true (“All conditions”) or one is enough, and “Stop after match” ends the run as soon as this workflow has matched — a workflow further down never gets its turn then. You change the order with the arrows next to it.

Under “When?” sits the condition itself. “Every e-mail in this mailbox” takes every mail; “Only when subject or text contains” requires a word in the subject or the body. “Advanced” makes it precise: there you choose what is looked at — “Subject or body”, “Subject”, “Body”, “Sender (From)” or “Recipient (To/Cc)” — and how it is compared: “Contains”, “Equals” or “Regex”. That is how you separate, say, reports to a shared address from everything else.

Below that sit five actions as switches. They are the actual content of the workflow — whatever is not switched on does not happen:

“Create or append ticket” turns the mail into a ticket — or appends it as a comment to an existing one when the reference is in the subject. Without this action a mail never becomes a case.

“Set fields” sets priority, status, main and sub category, owning team and assignee right when the ticket is created. Everything left on “— Keep default —” stays as it would be without a workflow.

“Auto-reply” is the confirmation to the sender. With this switch off your customer gets no confirmation, no matter how well everything else is set up. “Send mail” can write to the sender as well, as the next action shows.

“Send mail” sends an additional mail: either to the sender of the incoming mail or to selected team members and fixed addresses. It has its own “Send conditions” — leave them empty and it goes out on every run of this workflow.

“Move to folder” files the processed mail into a folder. Leave the field empty and the general “Processed folder” from the IMAP settings above applies.

The “Auto-reply” action in detail: you build the subject from blocks. “Original subject {originalSubject}” takes over the subject of the incoming mail, “Ticket reference {ticketTag}” inserts the case reference — together they produce something like “Printer problem [TICKET-99-a1b2c3]”.

The reference is not added by itself. It appears only where you put {ticketTag}. {ticketId} only inserts the bare number, and the system does not recognise a reply by it. Without the reference in the subject, a reply is still matched if it carries the reply headers of the confirmation. Only a mail with neither becomes a new ticket.

The text below it is your confirmation message. Write it in English: it runs through the same export/import as every other text, and only that way can it be translated into the other languages. Leave it empty and the system sends its own default message. The same placeholders are allowed here as well.

“Reply language” decides which language the subject and the text go out in: “Standard English” uses English, “Fixed language” a language you pick, “Assigned agent's language” the language of the assigned agent, and “Team default language” the team’s default. The translations themselves are maintained on the languages page.

One piece of advice that the system prints above the card as well: everything belonging to one case belongs in ONE workflow. Only actions inside the same workflow know the ticket that was just created — that is why the confirmation can name its number and an action from a second workflow cannot.

The whole mail channel — in and out — is part of the Professional edition. In Basic the system neither sends nor receives e-mail; tickets are created there through the portal, the phone and the agent.

Time tracking is off as a factory setting. While it is off there is no field and no column. The “Time spent” card in the report then only appears if time was logged in the chosen period.

A dead field would be worse than none at all, so the feature disappears completely instead of sitting there greyed out.

The switch sits under “Settings → General” on the card “Time tracking per ticket” and is called “Enable time tracking”.

Every team then takes part. To leave one out you switch it off on the team itself, under “Settings → Teams” in the “Team details” box.

A company with an internal IT team and a customer-facing team often needs it only for the second one.

If you switch time tracking off again later, the entries that exist stay readable and exportable — they are a basis for invoicing, not a convenience. Nothing new can be logged. Existing entries can then no longer be changed or deleted either.

The ticket carries a card called “Time spent”. “Log time” opens the input.

Quick buttons sit next to the field: one click on “30m” logs thirty minutes. Which buttons appear is set in the settings.

The “Duration” field also takes free input: “90” is ninety minutes, “1.5h” is an hour and a half, and so is “1h 30m”. A number without a unit is always minutes.

Input the system does not fully understand is rejected. “1h in the evening” does not become an entry of one hour — it becomes an error message.

In “What for (optional)” you write what the time was for. The text travels into the export and does not appear in the ticket history.

Several agents log time on the same ticket. Every entry carries its day, its note and the name of the person who did the work.

Time is logged onto a day, not onto a clock time. The input has a date field for this that starts with today; to fill in yesterday you pick the day before there. A day in the future is not accepted. A clock time would claim a precision the input does not have.

For long sessions there is a stopwatch on the ticket: “Start timer” starts it, “Pause” holds it.

The stopwatch never creates an entry by itself. It proposes the elapsed time, and nothing is saved until you press the “Log …” button that names the time. What gets logged is the time that has actually run.

It replaces mental arithmetic, not knowledge. Without it the feature is complete, because typing the value is the actual path.

Opening another ticket pauses the running stopwatch, and the new ticket tells you which ticket it is attached to. If time that has not been logged is still waiting on another ticket and you start the stopwatch here, the application asks first. The “Start timer” question offers “Log …” for the time on the other ticket, “Discard” and “Cancel”. It appears from one minute of elapsed time.

A hidden window is not a break. The stopwatch keeps running if you merely click away.

Against a stopwatch left running overnight there is a maximum runtime. The value is capped, never discarded, and the agent is told.

The stopwatch is off as a factory setting. You find it in the settings under “Stopwatch on the ticket”.

Every entry carries a “Billable” switch. The time is logged once, and the switch decides whether it goes onto the invoice.

That is why the ticket can show two totals: everything logged on the left, the billable sum on the right. The second total only appears when it differs from the first.

There is no separate type for goodwill. Goodwill, warranty work and internal rework are called different things in every company, and the system knows only the one distinction that money hangs on.

This is how you log goodwill: enter the time as usual, switch “Billable” off and write the reason in the note.

The entry then visibly carries “not billable”. The minutes stay in the logged total, because the work did happen.

Anybody who does not log the time at all loses the very number that later explains why a customer was charged so little.

If most of your work is not billable, turn the default around with the switch “New entries are billable by default”.

As a factory setting everything is billed to the minute. Anybody who bills in quarter hours sets two values.

“Rounding increment (minutes)” is the step. Every entry is rounded up to the next multiple.

“Minimum per entry (minutes)” is the floor. Every entry is billed with at least this value.

The two work one after the other: first the floor, then the step. With a floor of 20 and a step of 15, five minutes become thirty, because the result has to satisfy both.

Below the two fields stands a sample sentence with your own values. It is calculated, not claimed.

Only the billed value is ever rounded, and only per entry — never the total. Two small entries are therefore rounded up twice.

The logged time stays untouched. Changing the rounding later falsifies no old data, because the value is worked out when it is shown.

You see both on the entry: where rounding changes the value, the result stands next to it in brackets.

A service provider often wants no ticket closed without logged time. There is a switch for that.

It is called “Require a time entry before resolving or closing” and is off as a factory setting.

It applies only when a person changes the status, and only to people who may log time. It also applies when a reply template sets the status on a single ticket. An agent without an entry gets a message and the ticket stays open.

Auto-close, merging and bulk actions are never blocked. Otherwise there would be tickets nobody can close any more.

This is the most dangerous switch of the whole feature. Only turn it on once your team really logs time every time.

The ticket list gets a “Time” column showing how much has already been logged on a case.

You do not switch it on. It appears as soon as time tracking is on. Only agents and administrators see it. You can remove it from your list with “Columns”.

On narrow windows it is one of the first to drop out again. The list then keeps the columns without which a ticket cannot be found.

Time that only stands on a single ticket is no basis for an invoice. That is why the report page carries a “Time spent” card. Only people with the “Time tracking: see the report” permission see the card.

Four numbers stand at the top: logged, billed, the number of entries and the number of tickets that carry any time at all.

That last number is the most important one after the total. Forty hours on three out of five hundred tickets is not an evaluation — it is three agents who are the only ones logging.

Below that come the breakdowns: by requester, by team, by category and by day.

On top of that comes one table per custom field. That is the road to billing by company or cost centre: you create a custom field, fill it in on the ticket, and the report groups by it.

The period at the top of the page applies to the day the work was done. July work on a June ticket therefore stands in the July report.

A note below the export buttons deserves to be taken seriously: the figures come from entries made by people and from your rounding rules. They are a working basis, not an audited invoice.

Three buttons sit below the card. They deliver the individual entries, not the totals from the page. They contain exactly the entries that match your filters.

These are two recipients, not three file formats. “Export entries (CSV)” and “Export entries (Excel)” go to accounting: both are complete and are never truncated.

“Export entries (PDF)” is the document for a human being. It goes to the customer as an attachment to the invoice. The PDF has no column for the note.

The PDF is capped at 20,000 entries, and the document says so itself. Nobody reads an invoice with more lines than that anyway.

All three files are built from the same source: filters, rounding, columns and figures exist once, so the three cannot drift apart.

An entry that is not billable has an empty cell in the billable column, not a zero. A zero would be summed up in a pivot table.

If “Per-agent evaluation” of time tracking is off, the “Agent” column is missing from all three files. If your licence falls back to Basic, the existing entries stay readable and exportable.

A customer never sees the time entries, not even on their own ticket.

This is not a setting but a lock in the server. There is no switch that opens it.

The reason sits in the entries themselves: notes are written for the team. They say what went wrong and how long the search for the cause took.

Other systems of this kind do the same. Where time reaches the customer, it reaches them as a document.

That is what the PDF export is for: it goes out with the invoice and not onto the ticket in the customer portal.

The report can additionally show who logged how much. As a factory setting it does not.

Time per person is performance data, and in many companies the works council has a say in it.

The switch is called “Per-agent evaluation” and sits in the settings.

While it is off the server does not even deliver the figures. The table is not hidden — it does not exist.

That difference matters. A lock that only the display knows about is not a lock.