Two people describe the same internal queue.
One says response times are fine. The other says nothing ever gets answered. Both are being honest, and there is no number either of them can produce to settle it.
That is not a reporting gap. It is a consequence of where the requests live. In a shared mailbox, "answered" means somebody opened it, and there is no event anywhere that records the moment a human actually replied.
The number that matters is narrower than people think
Not resolution time — that depends on the problem, and a hard problem taking two weeks is not a failure.
Not "time to first touch" — reading something is not answering it, and an auto-reply is definitely not.
The useful number is: how long until a person actually wrote back. It is the one a requester experiences, and the one a queue can be held to.
It is also the one that gets faked, usually without anybody intending to.
Four ways it gets faked
Stamping it twice. If replying writes the timestamp every time, the last reply overwrites the first and the figure improves as the thread gets longer. Helpora writes it in exactly one place, guarded so it can only ever be set from empty:
Try the Helpora demo ↗Live, on sample data, no sign-up.
UPDATE requests SET first_response_at = ?
WHERE id = ? AND first_response_at IS NULLOne writer. A second reply cannot move it, an import cannot backdate it, and the agent tool goes through the same door as the screen.
Closing what was never answered. The single cheapest way to make a queue look healthy is to tidy away the requests nobody touched. Helpora refuses to settle a request with no first response, and the refusal says why. If you never answered it, it is not resolved — it is abandoned, and those are different words.
Pausing the clock by hand. Every system with a manual "on hold" state eventually has a queue where everything is on hold. There is one pause here — waiting on the requester — and it ends automatically when they reply. Nobody can hold a clock open to protect a number.
Moving the deadline backwards. Re-prioritizing can extend a target. It cannot pull one in retrospectively to make a breach disappear, and every move is on the record.
Working hours, or the number is a lie
A request arriving at 16:00 on Friday is not four hours late by Monday morning, and any system that says so will be ignored within a month — correctly.
Targets are counted in working hours, against your hours and your holidays. This is unglamorous and it is the difference between a figure people act on and a figure people explain away.
Never answered is its own number
Most dashboards report a percentage: 83% of first replies within target. That single number hides the thing you most need to see.
A request nobody has touched is not a slow request. It is a different failure. Averaged into a percentage it disappears; reported separately it is the first thing you look at.
The demo desk reads: 83% first reply within target · 2 never answered · 3 breaching now · median 1h 45m. Four numbers, and the second one is the one that would have been invisible.
Median, incidentally, not mean — one request that sat for three weeks should not make a good month look bad, or a bad month look catastrophic.
The agent is the caller that would route around all of it
An assistant told to "tidy up the queue" will happily close forty unanswered requests. It is the most dangerous caller the product has, because it is fast, obedient and has no judgment about what closing means.
So the MCP surface is scoped rather than trusted. A read-only key does not merely get refused the write tools — it never sees them. They are absent from the tool list, so the model does not propose settling anything in the first place.
And every rule the screen applies is applied there too. An agent cannot settle a request nobody answered, cannot move a first-response stamp, and gets the same refusal text a person does.
What it is not
Helpora is for internal requests — IT, facilities, HR, ops. There is no public portal, no customer accounts, no branded ticket site.
It does not read your mailbox. No IMAP polling, no inbound mail parsing. Requests come from the form, the REST API or MCP; outbound notification goes through your own SMTP.
There is no requester login, no CMDB, no change approvals, no incident/problem hierarchy, no chat and no phone. It is a request queue with an honest clock, not an ITSM suite.
The product page says all of that before you buy rather than after; the demo is open without a sign-up, and Helpora is one of the four products in the Front-Desk Suite.
What the alternatives charge for the same question
Zendesk publishes '$55' 'agent/month paid yearly' on Suite Team; Freshdesk publishes '$19/agent/month, billed annually' on Growth. Both were read from their own pricing pages on 22 August 2026, and both figures were still there when the pages were read again on 5 September 2026.
That second reading showed this guide had been pricing the wrong shelf. Helpora is for internal requests, and both vendors sell a line for precisely that — priced under the customer-service plans quoted above. Zendesk's employee-service pricing opens at '$29 agent/month paid yearly' on its Suite Team, for teams "getting started with a service desk and ticketing system". Freshservice opens at '$19 /agent/month, billed annually' on Starter, carrying incident, knowledge and task management with a support portal. Even on the customer-service side Zendesk begins below the plan quoted above, at '$19 agent/month paid yearly' on Support Team — sold, with some irony for a guide titled this way, to teams that have "outgrown a shared inbox".
Every figure above is an annual rate. Both vendors advertise 20% off for paying annually and put the monthly option behind a toggle, so paying by the month costs more than any number printed here.
For a three-person internal desk, that is $87 a month on Zendesk's employee-service entry, or $57 on Freshservice. Arithmetic, not a vendor quote. Helpora is $69 once, which is about five weeks of the cheaper of those two.
All of those products do a great deal Helpora does not, and if you serve customers rather than colleagues you should buy one of them.
The point
You cannot fix a number you cannot produce. And you cannot produce this one from a mailbox, because the mailbox has no idea which message was the one that answered.
Everything above exists so that when the figure is finally on a screen, nobody in the room can improve it without actually answering somebody.