A Form, Not An Inbox
Our helpdesk emails your customer when their request is updated. If they reply to that email, nothing happens — and no amount of the rest of the module being good makes that a small thing.
Four of the five posts in this series are about something we got wrong and then fixed. This one is not. It is about something that is still true today, that we are not going to fix this quarter, and that a reader evaluating our helpdesk should probably weigh more heavily than any of the other four — because those were defects in a mechanism that existed, and this is a mechanism that does not.
What exists
An external customer can raise a request from a public form, without an account. It becomes a real ticket with a reference, a queue, a category, deadlines and an owner. When somebody works on it, the customer is emailed — the request was received, somebody replied, the status changed — and each of those emails carries a signed link to a page where they can see the whole conversation and add to it. That works, it is not a stub, and for a lot of organizations it is enough.
What does not
If the customer replies to one of those emails, the reply goes nowhere. Not into a holding queue, not to a person, not into a folder somebody checks. We do not receive email. There is no mailbox we read, nothing listening for inbound messages, and no parser that would attach a reply to the ticket it came from. Our ticket record has always had a slot to say that a request arrived by email, and nothing has ever written it.
Why this is worse than a plain missing feature
Because we sent the email. A customer who receives a message from your organization about their request has every reason to answer it — that is what email is. The absence is not "we do not offer email intake", which a buyer can evaluate. It is that our outbound message invites a reply we cannot receive, and the person who loses is the customer, who has no way of knowing.
The difference between a form and an inbox
It is easy to treat these as two interfaces onto the same thing. They are not, and the distinction is about who is required to change their behaviour.
- A form is a place the customer has to go. It requires them to know it exists, to find it again, and to accept that this vendor has a particular way of being contacted. It produces clean structured data because it asks the questions it wants answered.
- An inbox is a place the customer already is. It requires them to know nothing. It produces messy data — no category, no priority, three problems in one paragraph, and a signature block quoted four times.
- The messy one is where the work actually arrives. Not because it is better, but because a customer with a problem reaches for the thing already open in front of them.
A system that only accepts the clean version has not eliminated the messy version; it has moved it somewhere it cannot see. The requests still arrive by email, to somebody's personal address, and get retyped into the form by a colleague — or, more often, get handled entirely in that mailbox and never become tickets at all. Every number the helpdesk reports is then a number about the subset of your support that happened to come through the front door. That is the real cost, and it is not a support cost. It is a reporting one.
What we are actually saying
If email intake is how your customers contact you — and for most organizations selling to businesses it is — then our helpdesk is a system your team will use and your customers will work around. That may still be the right purchase. Internal ticketing, where employees raise requests through a system they are already logged into, is a different problem and this module is genuinely good at it. But buy it for the problem it solves.
This is on the roadmap rather than a boundary, and it is commissionable now. It is a real build rather than a setting: a mailbox to read, a rule for matching a reply to the ticket it belongs to, a decision about what to do with a message that matches nothing, and a queue for the ones that go wrong. Tell us which mailbox and which direction and we will come back with a written specification, a timeline and a price. What we will not do is put a date on this page that nobody has paid for.
One thing to ask any vendor who does have it
Ask what happens to a reply that cannot be matched to an existing ticket — a forwarded thread, a changed subject line, a customer replying from a different address than the one we wrote to. Every email-intake system has this problem and the good ones have an exception queue with a person attached. A vendor who says it always matches has not run one.
Why this post exists at all
We publish our absences on the same pages as our capabilities because the alternative is asking you to take the capabilities on trust. The four sibling posts in this series describe defects we found in our own helpdesk and repaired within the week, and every one of them is a better advertisement than a feature list — but only if you believe the list of what we have not built is equally complete. So here is the largest thing missing from this module, on the same day as the fixes, with no date attached to it.
