The caller hears the ticket number only once it exists.

You know that second call. “I rang yesterday — did that get through?” Voxori logs the ticket during the call and reads out the number only once it genuinely exists. If that fails, she promises nothing.

In pilot · €0 setup · €49 per month as a separate module · included in Complete

Logging it isn’t the work. The question after is.

A ticket arrives whenever it arrives: by phone, between two other things. The work starts afterwards — with someone who has no idea whether that first call landed anywhere.

Uncertainty costs on both sides. The caller rings again, because he is holding nothing: no number, no confirmation, nowhere to look. The person handling it searches his memory, his mailbox and a group chat.

The fault itself is rarely the problem. The problem is that the ticket has no single place to live.

• Tuesday, the second call. “I rang yesterday about the printer.” You know something was written down. You don’t know where.
• The note goes missing. Not out of neglect. Something came up, and the pad ended up under an order slip.
• Friday afternoon, ten to five. Something comes in that won’t happen today. Does the agreed deadline simply run through the weekend?

Recognise all three and the rest of this page is about your situation. Recognise none of them and you probably don’t need this.

Two ways in. There is no third.

A ticket is created on the phone, or by hand in your portal. Email, WhatsApp and the chat widget create no tickets today, and we would rather write that down now.

When someone rings with a fault, Voxori records what is going on, who is reporting it and on which number they can be reached. If the caller gives no number, the number they are calling from is used.

The ticket number comes from our own database. It exists only once that row is really there, and only then does Voxori say it out loud. She passes on a ticket number only if the ticket has genuinely been created. Never before.

A ticket number that doesn’t exist is worse than no ticket number. That is why she would rather stay quiet. If she is interrupted, or it takes too long, she promises nothing, and no second ticket is created afterwards for that same call.

• Numbers you can say out loud. Short, running per organisation from 1001. No years, no hyphens. Two tickets can never share a number.
• A holding line instead of silence. If it takes longer than roughly a second and a half, the caller hears a short holding line, and another one after that if needed.
• Never two tickets for one call. If the AI asks for a ticket again within the same call, it gets the existing number back.
• Any finished call can become a ticket. You pick the setting: only when Voxori creates one herself, only when an appointment was booked, or every call.
• By hand as well. Whatever comes in at the desk or via a colleague, you enter yourself in the portal. Same number series, same clock, same log.
• Never in the public browser demo. An anonymous visitor cannot create a ticket at a real customer.

If the ticket goes to a connected external system there is a network connection in between, so the outcome can be ‘unknown’ — and then Voxori promises nothing. With our own service desk the outcome is always either created or failed.

Changing priority moves both deadlines.

Four priorities, each with its own response and resolution target. Move the priority and both deadlines move with it.

Critical, High, Normal, Low. Each carries two targets in working minutes: when a response is due, and when a resolution is due. You set them yourself.

Raise an open ticket and both deadlines are recalculated from that moment. A priority here is a deadline, not a label.

The AI does not set the priority, and not the category either. Every phone ticket comes in as ‘Normal’. Someone on your side adjusts that priority; the category is fixed at ‘other’ and cannot be set in the portal.

• Eight targets, filled in by default. A response and a resolution target per priority: critical 30 and 240, high 60 and 480, normal 240 and 1440, low 480 and 2400 working minutes.
• Adjustable per priority. In working minutes, in the portal.
• Changing it recalculates both deadlines. From that moment, with a line in the log.
• A broken setting never produces a ticket without a target. The default configuration applies instead.

We promise no response time and no resolution time. We measure against the target you agree with your own people.

Friday at half four doesn’t count as half an hour.

The deadline runs on your working hours, not on the calendar. That isn’t a correction afterwards; it is how the sum is done.

You set per weekday whether you work, with your own start and end time. The default is Monday to Friday, 09:00 to 17:00. If a ticket arrives on Friday at a quarter to five and you have agreed four working hours, the deadline isn’t Saturday night but Monday at a quarter to one. The calculation accounts for the Dutch time zone and the daylight-saving shift.

Running 24/7? Leave the hours list empty. Plain calendar time then applies, and an hour is simply an hour.

Responded means: the reporter has seen something. A public reply counts, or the resolution itself. An internal note does not, and neither does changing a status.

• The clock stops while you wait. ‘Waiting on the reporter’ and ‘waiting on a third party’ halt the time. The list says so in words.
• And it shifts exactly. On resuming, the deadlines move by the working minutes you could not work. Not a minute more.
• Reporter replies, clock resumes. A reply on a ticket that was waiting on them sends it back to ‘in progress’ by itself.
• A stopped clock cannot expire. The monitor skips paused tickets.
• Met or missed, recorded at the time. It is fixed the moment it happens and never recalculated. Change your hours later and the history doesn’t get prettier.

The clock is your instrument, not a promise from us. You set the target and you see whether it was met.

A page of their own, no account and no password.

Every ticket gets its own unguessable link. It shows where the ticket stands — and nothing the reporter shouldn’t see.

On a phone ticket that link goes out by SMS along with the number, provided reporter updates are switched on and a phone number is known. The page carries your logo.

The reporter sees only the lines marked as visible. An internal note never appears there. That isn’t a setting you can forget; it is how the page is built.

Messages can fail; the ticket cannot. An email or SMS that doesn’t arrive changes nothing about the ticket itself and holds up no change. The ticket is the truth, the message is the delivery.

• What it shows. Number, status, subject, when it was reported and the full course of events.
• Replying. A reply on a ticket that was waiting on them sends it back to ‘in progress’ automatically.
• Closing. The reporter can mark it resolved. Reopening they cannot — that stays with you.
• Automatic notice. On a public reply, on ‘resolved’ and on ‘waiting on reporter’. On a phone ticket that goes by SMS — we record no email address for a caller.
• You get something too. On a phone ticket, one address you set yourself receives an email with number, subject, priority, reporter and description.
• Shielded. Not in Google, not loadable in an iframe, not cached, rate-limited. An unknown or withdrawn link returns exactly the same 404 everywhere.

Reporter updates go off with a single tick box and the tracking link copies with one click — and both the portal and that reporter page are in Dutch.

A work queue, not an inbox.

The list sorts itself by what falls over first: open work at the top, and within that by deadline. That saves you the sorting. Choosing stays your own work: adjusting priority and assigning is manual.

Per ticket you see at a glance whether the deadline has passed, expires within two hours, is paused, or was met. As a word, not just a colour. Search runs on number, subject, description, name, phone number or email address.

Under every ticket sits a log that is only ever appended to, never overwritten. Creation, status change, assignment, priority change, note, reply, reporter response, expired deadline. Each line shows when, by whom, and whether the reporter can see it.

• Six statuses, four priorities. New, In progress, Waiting on reporter, Waiting on third party, Resolved, Closed. And Critical, High, Normal, Low.
• Two buttons, deliberately separate. A reply to the reporter and an internal note. Only the reply counts as first response, and the portal says so.
• Create and assign handlers. Name, email, phone, team, active or not. Every change lands in the log.
• A short figures strip. Four numbers over a period you choose, thirty days by default: open work, expired deadlines, and how often the response and resolution targets were met. Only tickets with a settled outcome are counted.
• Nothing to measure yet? It says so. No invented 100%.
• CSV export. Number, subject, status, priority, source, reporter, phone, handler, created, resolution deadline, resolved. One export takes up to 500 rows.

Reopening is always possible: it clears the resolved and closed stamps, gives a fresh resolution deadline from that moment, and adds a line to the log.

What this isn’t.

This is the part you rarely read in a brochure, and it belongs here just as much. We are not softening it.

Voxori is the front door to your service desk, not the second line. She answers, she asks the follow-up questions, she records it and she makes sure the ticket has a number and a tracking link. Solving is done by a person. That is a design choice, not a shortcoming: everything behind the front door we deliberately leave with your team.

• Phone and manual entry only. Email, WhatsApp and the chat widget create no tickets. Those channels are not connected to this.
• No engine that thinks along. No rules, no triggers, no automatic assignment, no routing by category or keyword. Assigning is manual work in the portal.
• No register beside the ticket. No devices or locations, no change management with approvals, no file per reporter, no merging of duplicates, no knowledge-base article attached to a ticket.
• No escalation to second line. No levels, no matrix, no manager who is notified when a deadline passes.
• One schedule, and no public holidays. One set of working hours and one target per priority per organisation. Christmas counts as an ordinary working day.
• No attachments, no app, no way in for your own software. No photos or log files, no time tracking or rebilling, no satisfaction question afterwards, no iOS or Android app, no API key or webhook. There is a CSV, no PDF and no charts.

You don’t have to cancel anything. If an active connection to your ticket system is already running, that system stays leading and the ticket goes there. Such a connection exists today for TOPdesk only, runs one way, and is not yet running at a single customer. This module is meant for those who do not have such a system.

What happens while you’re not looking.

What stays manual, we would rather say now. A background process watches the deadlines; the rest of the looking is yours.

Every five minutes it checks whether deadlines have passed. If they have, that becomes a line in the log, even on a day when nobody signs in. One breach produces exactly one line, and a restart repeats nothing.

Beyond that, nobody taps you on the shoulder. There is no counter ticking on your screen either. Whoever looks, sees it; whoever doesn’t, doesn’t. That is precisely why the list sorts by what falls over first.

One more thing runs in the background: the clearing out. Completed tickets are deleted automatically after 730 days, counted from the last activity, or sooner under a stricter setting. A GDPR request on a phone number also removes the tickets and their logs. All access runs on your own signed-in session, and switching the module on, plus every change to the configuration, lands in the audit log.

• You set the priority yourself. Every phone ticket arrives as ‘Normal’. The category is fixed at ‘other’ — there is no picker for it in the portal today.
• A reporter replies, and you get no alert. The message lands quietly in the portal, without an unread counter.
• Manually created tickets send nothing. No email to the configured address, no tracking-link SMS. Those two hang off the phone path.
• Handlers get no notice on assignment. There is no separate login per handler and no ‘my tickets’. The portal account is per organisation.
• Replying to an update email does nothing. If the reporter answers an update email, it doesn’t reach the ticket.
• Nothing closes or chases automatically. No auto-close after X days, no reminder to a reporter who stays quiet.

The monitor writes a log line and nothing else. No email, SMS or push goes to you, your handler or your manager when a deadline passes.

“A ticket number that doesn’t exist is worse than no ticket number.”

How one ticket travels through.

Five steps. They are written out above; here they are in order.

1. 01The callSomeone rings with a fault, a complaint or a question that keeps slipping. Voxori listens, asks the follow-ups and summarises what is going on.
2. 02The numberShe records the ticket in the Servicedesk module. Only once that has worked does she say the number out loud. If it doesn’t work, she promises nothing.
3. 03The messageIf reporter updates are on and a phone number is known, the reporter gets an SMS with their number and a tracking link. One address you set yourself receives an email with number, subject, priority, reporter and description.
4. 04The work queueThe ticket lands in your work queue, with its response and resolution deadlines on your working hours. Open work sits at the front, and within that by what falls over first. You assign, you adjust the priority.
5. 05The replyA public reply counts as first response and appears on the tracking link immediately. Set it to ‘Resolved’ and the reporter is notified, while whether the target was met is recorded then and there.

Every step above is in the code today and runs in our own tests. What hasn’t happened yet: handling a real ticket from a real customer.

€49 per month — per organisation, no licence per handler.

A separate module on top of Voxori Base. In Voxori Complete it is included at no extra cost.

Billing is per organisation, not per handler and not per employee. So you can create as many handlers as you need; the count does not change the price. In this corner of the market a per-handler licence is the norm, which in practice means small teams start sharing accounts — after which nobody knows who picked up what.

The price ceiling applies here too: stack modules beyond the Complete price and you simply pay that flat price. Base plus this module comes to €128 per month, excl. VAT.

• €49 per month excl. VAT, on top of Voxori Base · included in Voxori Complete
• Fixed price per organisation · the number of handlers does not affect it
• €0 setup costs · cancel monthly · 30-day money-back
• In pilot: we switch it on together after a guided start — the price is fixed
• If your subscription bills separate modules, we ask you to confirm the agreed price before the module is switched on

Want to know what Voxori costs without this module? See the packages on the pricing page.

Questions about the service desk.

See also the page for IT help desks or the full FAQ.

We’re looking for a few companies to run this first.

No quote form, no sales funnel. Tell us how you get called and what is slipping through now — then we’ll explain honestly what this module does today and what it does not. If it isn’t a fit yet, we’ll say so.

In pilot · not running at a customer yet · €49/mo · €0 setup · cancel monthly