The Number a Shared Inbox Cannot Produce — First Response, and Why It Gets Faked
Every internal queue argues about response times with no number either side can point at. The reason is that "answered" in a mailbox means somebody read it. What it takes to produce a first-response figure that survives being audited, including the four ways teams accidentally fake one.
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 a fortnight 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:
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-prioritising 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 judgement 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.
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 read from their own pricing pages on 22 August 2026.
For a three-person internal desk that is $165 or $57 a month — arithmetic, not a vendor quote. Helpora is $69 once, which is roughly what Freshdesk costs those three people in fourteen months.
Both of those products do a great deal Helpora does not, and if you serve customers 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.