deskten runs the support of many customer companies from a single installation. Each company has its own projects and its own portal, a ticket always belongs to a project, and nobody ever sees a request that is outside the projects they were given.
Two-step sign-in over SMS · Daily backups · A full audit trail
They pick one of the projects they belong to, describe the problem and drag their files in.
It lands in the staff queue with its company, project, category and priority. The SLA clock starts from the project's own target.
Public replies go to the customer; internal notes stay with the team. Every field change is written down.
The customer closes or reopens it themselves, and scores the resolution out of five.
They pick one of the projects they belong to, describe the problem and drag their files in.
It lands in the staff queue with its company, project, category and priority. The SLA clock starts from the project's own target.
Public replies go to the customer; internal notes stay with the team. Every field change is written down.
The customer closes or reopens it themselves, and scores the resolution out of five.
There is no separate copy in a separate tool, and no integration to keep alive between them. The portal and the queue are two views of one ticket - which is exactly why an internal note can never leak to the customer: it is a property of the record, not a different document.
"Since this morning the labels come out of the printer as an empty page. Forty parcels are waiting at the loading bay."
Internal note: the label service is sending A4 while the printer is set to 100x150. Fix the template, then check the two printers in the other warehouse before we close this.
An internal note is never rendered in the customer interface, and an out-of-scope ticket answers 404 rather than 403 - so an id cannot even be used to prove that a ticket exists.
Status, priority, category, assignment, an edited reply - every one of them lands on the ticket's timeline with who did it and when. Support arguments end by reading the record instead of trusting a memory.
A reply can be corrected after it was sent. The customer sees the current text; the team can read every earlier version of it.
A project can carry its own targets per priority; where it does not, the platform default applies. The countdown and the overdue warning both use the target that actually applied.
Scope is derived from memberships each time, never carried in the token. Remove someone from a project and their access is gone on the next click - not at the next sign-in.
Opened against Shipment Portal · priority High
SLA target taken from the project — 4h, due 13:41
Assigned to Ahmet K.
Internal note added — not visible to the customer
Reply edited — previous version kept
Status In progress → Resolved
Closed and rated by the customer — 5 / 5
A ticket always belongs to a project, and the company is derived from it. A company-level membership covers every project of that company, including the ones added later.
Urgent, High, Normal and Low targets can be set per project and fall back to the platform default. Overdue tickets are called out on the dashboard.
The team talks on the ticket without the customer seeing it, and the answers you send every week are one click away.
Files up to 10 MB per attachment, on the ticket and on any reply. They can only be downloaded by someone whose scope covers that ticket.
Trends, category and priority distribution, agent workload and SLA compliance on the dashboard; CSV export and print-ready PDF reports for the rest.
Sign-in can be finished with an SMS code. An invited user gets the link by e-mail and the code by phone, then sets their own password - no temporary password is ever mailed.
One mailbox · several private copies · a request that quietly falls through
One installation · the portal your customers use · one place the answer lives in
We open the installation, define your first company and project together, and hand you the portal address to give your customers. Half an hour is enough to see whether it fits.
