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 appear at all and which of them are mandatory is set under “Settings → Ticket Settings” — separately for agents and for customers. That is why a customer sees a shorter form than you do, without anyone having to maintain two forms.

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, priority, assignment, channel and observers sit one card higher under “Actions” and take effect immediately, without a separate save.

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. Only then do those tickets disappear from the live database — 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.

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 “Only for Admin/Agents”. It then carries the “Internal” badge and is invisible to the requester — not even the search will surface it.

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 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.

A comment appears there shortened — the full 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. Six statuses carry the “Mandatory” badge in the list — Open, Assigned, In Progress, Resolved, Closed and Reopened. 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 “Rejected”, 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.

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”, “Site”, “Role”, “Status” and “Priority”. Behind each of them is the same handling, so you only have to learn it once.

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 site”, “+ Add department” and so on. The rows below are the existing entries: that is where you change a name and confirm with the “Save” next to it.

For many entries at once there are “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, six of the statuses that ship with the system, and one placeholder each in the Site, Position and Department lists (“None selected or available”). They can be renamed but not deleted: permissions and processes hang on them that would otherwise quit without a word.

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 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 “Email” when it grew out of an incoming mail.

That is also why you cannot switch a system-assigned channel to “Phone” later on: 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.

“Email” 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. 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.

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.

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.

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” apply to new tickets: “Mandatory by default”, “Hidden for customer by default” and “Not editable by customer by default”. They are defaults — the field settings on the same page remain the place where you set it precisely per role.

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, but it cannot lift a rule: what the administrator hid from customers or declared mandatory stays that way, even when a template says otherwise. Otherwise a template would be a way to opt out of a house rule.

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.

Only agents and administrators of a participating team 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.

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

The notification is an e-mail — so outgoing mail has to be set up (Professional). Without it you can enter observers, but nothing goes out.

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.

Processed mails move into the “Processed folder”; 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 — the only place where the system answers on its own. With this switch off your customer never gets an automatic reply, no matter how well everything else is set up.

“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]”.

The reference is not added by itself. It appears only where you put {ticketTag} or {ticketId} — and that is exactly what the system recognises your customer’s reply by later. Without it in the subject, every follow-up starts a new ticket instead of becoming a comment on the old one.

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, no column and no tile in the report.

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.

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. Filling in yesterday is the normal case, and 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 “Log”.

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.

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” tick. The time is logged once, and the tick decides whether it goes onto the invoice.

That is why the ticket shows two totals: everything logged on the left, the billable sum on the right.

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, untick the box 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. 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 a ticket in the list carries time.

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.

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 above the figures deserves to be taken seriously: they 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.

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 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.

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.