May 4, 2026 • 6 min read
Every helpdesk on the market will tell you how many tickets your team closed last week. None of them will tell you whether your customers feel taken care of.
That gap is not a measurement problem. It is a product problem. Helpdesks were built to count tickets because tickets are easy to count. But the thing your customers actually experience is a relationship that either feels handled, or doesn't.
Slokoto Support is built around that distinction. This is the first post in a series about what we shipped, what we left out on purpose, and why.
The Metric That Quietly Broke Support
Walk into any support org and you will hear the same three numbers. First response time. Tickets closed per agent. Average handle time.
All three are throughput metrics. They reward the team for moving tickets off the board, regardless of whether the customer's problem actually went away.
So agents learn the game. A vague reply inside the SLA window stops the first-response timer. A "marking this resolved, please reopen if needed" closes the ticket. A canned reply with a help-center link counts the same as a real fix. The dashboard turns green. The customer files a second ticket next Tuesday with the same problem. Nobody connects the two.
This is not a people problem. The product is teaching them to do it.
We Started With One Rule
Before we wrote a single line of Slokoto Support, we picked one rule and held everything to it.
The unit of work is the customer's problem, not the ticket.
That sounds like a slogan. It is actually a constraint that quietly shapes every screen in the product.
A customer sends an email, then chats in two days later, then calls. That is one problem, three touch points. A helpdesk built around tickets gives you three rows. Slokoto Support gives you one conversation. Same customer, same thread of context, no matter which channel they used to find you.
When the rule starts at the data model, the rest of the product falls in line.
What That Changes In Practice
A few examples of what changes when you stop treating the ticket as the goal.
The agent sees the whole story. When a customer calls, the agent's screen is not a phone log. It is the same conversation that already has the email thread, the chat history, the previous ticket from six months ago, and the products this customer owns. The agent does not have to ask "have you contacted us before about this?" The product already knows.
Channels stop being silos. Email, chat, phone, and the contact form all land on the same conversation. An agent answering chat can pick up where the email thread left off. A supervisor reviewing a phone call can read the chat that preceded it. There is no "but did you check the chat tool" handoff, because there is no separate chat tool.
SLAs measure the right thing. Slokoto Support's SLAs are scoped to the customer's problem, not to ticket creation timestamps. Closing and reopening doesn't reset the clock. Splitting a thread into two tickets doesn't game the metric. If a customer has been waiting four days for a real answer, the dashboard says four days, not "fresh ticket, 12 minutes."
Closing means closed. A resolved conversation is the one where the customer stopped needing us, not the one where the agent clicked a button. We track which conversations come back, by who, and how often, and we surface that to the team that owned them. If the same customer files three "different" tickets with the same root cause, that is one unresolved problem with a closure rate of zero, no matter what the helpdesk dashboard says.
What We Did Not Build
A first post is also a chance to be honest about what we deliberately did not ship.
No deflection theater. We did not build an AI bot whose job is to prevent the customer from reaching a human. The metric "tickets deflected" is the throughput trap dressed up in newer clothes. AI in Slokoto Support points the other direction: at the agent, not at the customer. It summarises the conversation, surfaces the relevant history, drafts a reply the agent can edit, and stays quiet when there is nothing useful to say.
No gamification of agents. No leaderboards, no points, no public "tickets closed today" rankings. The fastest closer is not the best agent. We do not want the product encouraging that fight.
No CSAT pop-up after every ticket. A one-question survey after every interaction trains customers to ignore surveys and trains agents to chase scores. We measure customer health at the relationship level, on a longer cadence, with signals the customer doesn't have to opt into.
No mandatory categorization taxonomy. Helpdesks love a 47-level category tree because it makes reporting look rigorous. In practice it is a tax on every ticket that nobody trusts. Slokoto Support categorizes conversations using the same data model the rest of the platform uses, automatically, after the fact. Agents do not file the report; the product files it.
What This Looks Like For A Support-Only Team
If you are a support team picking up Slokoto Support without Sales and without Communication, here is the shape of what you get.
Your team has a queue. The queue is full of conversations, not tickets. Each conversation has every channel the customer has used to reach you, every previous time they reached you, and every product or account they are attached to. SLAs run against the customer's wait, not the ticket's age. Escalations route by workload and skill, not by who is online and unlucky. Your dashboards show resolved problems and reopened ones, not just closed counts.
If you later turn on Communication, the same conversations gain calls and chat as native channels, with no migration. If you later turn on Sales, the same customer identity is already shared, no merge tool required.
Support is the product. Everything else is opt-in.
What's Next
Over the next few weeks we are going to walk through the parts of Slokoto Support in more detail. The conversation model. How AI assists agents without trying to replace them. How a phone call, a chat, and an email become one thread. How escalations work when the on-call human is not the right human.
If your team has been measuring tickets for so long that the word "ticket" feels like the work itself, this is the series for you.
The work was never the ticket. The work was the customer.