Support arrived in three places, and one of them was WhatsApp
1 August 2026
Nobody decides to run support out of three systems. It accumulates.
Ours started as one address. support@, forwarded to two people, answered from whichever
mail client was open. That worked for about as long as you would expect.
Then a customer we had spoken to on a call sent the next question directly to a personal address, because that was the address on the last mail they had. Fair enough. Then somebody asked for a phone number during a rollout, got one, and used it — first for the rollout, then for everything after. Then a customer added one of us on WhatsApp, and that channel was suddenly where their urgent things went, because urgent things go where a human answers fastest.
None of those were mistakes at the time. Each was a small accommodation for one customer, and each was cheap. The cost is not in any one of them. The cost is that after a year, answering the question “what did we tell this customer?” meant opening three apps and asking a colleague.
What actually breaks
Not the obvious thing. Tickets rarely vanished outright — somebody usually remembered. What broke was quieter.
The second answer contradicted the first. Someone answers on WhatsApp on a Sunday from memory. On Tuesday somebody else answers the follow-up in the shared mailbox, with no idea what was promised, and gives a different date. The customer is now the only person who has seen both messages, and they are the one who has to point it out.
Context lived in people, not in the thread. The real reasoning — their workspace predates the VAT migration, the rate never got written — was in a chat between two of us, in a different app, in a conversation about four other things. Six weeks later the same customer writes in again, a third person picks it up, and all of that is gone. They start from the beginning, and so does the customer.
Handover cost more than the work. Going on holiday meant a briefing. Not “here are the open tickets” — there was no list of open tickets — but “if Marta writes, the thing about the invoices is still open, ask Jonas”.
Nothing could be measured, so nothing could be argued about. Not in the dashboard sense. We could not answer are we getting slower? or is this one customer taking a day a week? because the record was scattered across three places, two of which were personal.
What we wanted instead
Something dull, and quite specific:
- One thread per conversation, containing the customer’s messages and our discussion of them, in order. Internal notes marked, and never leaving the building.
- The mail stays mail. Replies land in the customer’s ordinary inbox. They should not have to learn a portal or accept an invitation to get an answer.
- Somebody owns it, visibly, so that “I thought you had it” stops being a category of incident.
- On our own machine. Support threads are the single most candid record a customer produces about their own systems — versions, error output, sometimes a config file with the secrets badly redacted. That is not data to hand to a third party for the convenience of a nice inbox.
That last one is what ruled out most of the market, and the rest of the market wanted per seat per month for the features that make it work at all.
So we built it
Kiku is that shared inbox. It is AGPL-3.0, self-hosted, two containers, and every feature is in the box — there is no enterprise edition to graduate to.
It has not fixed our phone. People still call, and they always will. What it fixed is that after the call, somebody writes what was said into the thread, and the next person to touch that customer can see it.
If you recognise the three-apps problem, the quickstart is about fifteen minutes plus DNS.