See Spoke in action
Answer these two quick questions to get a customized introduction to Spoke.
Ticketing systems solve your support teams’ biggest problems… right? After all, they claim to be better than email support, to automate workflows, and to make your team more productive.
But when it comes to delivering on these promises, most traditional systems fall short. In this post, I’ll take a look at a few of the reasons why and how those problems have inspired what we’re doing here at Spoke.
When you’re migrating away from email support, a ticketing system seems like an ideal solution:
Traditional ticketing systems promise to deliver all of these benefits, and more. But if you want to know what support professionals really think about the systems they use at work, try scrolling through r/sysadmin.
What you’ll find: support teams still struggle with eight major issues after adopting a traditional ticketing system.
Traditional ticketing systems are monoliths. They’re massive, rigid, and formidable.
Another way to describe it comes from u/mintpepper who says:
“I see them like DVD remotes: there are 80 buttons, you only use four of them, and those four are difficult to find.”
They’re designed to do everything. And while the ability to do everything might sound excellent in theory, in practice, it makes doing anything—even simple tasks—much more complicated.
A few months ago, someone asked r/sysadmin users to describe their perfect ticketing system. The most frequent responses were related to speed:
In nearly every part of life, bigger means slower. It’s why you never see a sumo wrestler running track in the Olympics.
The more ticketing systems do, the more they lag. And that lag is more than just an annoyance. It makes using the system a burden for everyone involved.
Most traditional ticketing systems provide users with the ability to create an infinite number of rules for handling tickets.
And while a few rules are easy to manage, what usually happens is that teams create customized rules and workflows for everything, leading to what u/ResidentCollar calls an “unmanageable mess of spaghetti workflows.”
Instead, support teams crave something simpler: “A ticketing system only needs a few states for tickets, and maybe a couple branches in a workflow.”
Traditional ticketing systems are designed to do everything support teams could ever need them to do. But in the process of building complex rules and detailed intake forms, submitting a request gets more and more confusing.
There are entire threads in r/sysadmin dedicated solely to discussing strategies for getting coworkers to actually use a ticketing system. But the bottom line is that you shouldn’t have to con your coworkers into using your system.
First, instead of letting people raise tickets in the systems they already have open—tools like Slack—traditional ticketing systems make people jump through hoops to find an intake form for a system they probably only need once or twice a month.
Second, even when they find it, the form itself is baffling. Let’s say your monitor won’t turn on. What’s the priority? What’s the severity? Endless fields mean more cognitive overhead for the end user, making them less likely to want to file a ticket.
When the process of making a request feels like a burden, the people you support won’t use it. Instead, they’ll send an email, call you, or stop by your desk.
Traditional ticketing systems are niche products. There’s a system for internal IT support, one for external support, and one for logging production issues. Then there’s an intranet for HR, a portal for payroll, and of course, Slack for chat.
When you’ve adopted so many tools that you need a flowchart explaining which system to use for different scenarios, you’re suffering from the app proliferation problem. And it’s a problem that a niche, department-specific ticketing system contributes to. Take it from u/WoodChucking:
“We have most of our users trained on the ticketing system. Recently, we have a dev team who can’t or won’t wrap their heads around it… [T]hey keep telling us ‘there is a ticket for the task in Jira,’ and they send us that number. We don’t have access to their Jira, and for the last decade IT has had our own ticketing system.”
Imagine you’re at work finishing an important presentation that you have to give in an hour. Your computer freezes. You panic. You raise a ticket for support and get an email saying, “We’ll look into this and get back to you within 24 hours.”
It’s an impersonal response to what your coworkers believe are urgent problems, and it’s a problem perpetuated by traditional ticketing systems. As one Reddit user says:
“A ticket system introduces a layer between the customer and the engineer and impedes direct communication…. [A] customer will always prefer to talk to a human being who understands and sympathizes over a computer system that is cold and doesn’t provide immediate detailed feedback.”
A traditional ticketing system creates a workflow that allows your support team to get swamped with repetitive requests. Someone forgot their password? Send them the link to reset it. Printer not printing? Send the troubleshooting instructions. Computer behaving badly? Restart it.
Have your best and brightest work on these types of issues for long enough, and they’ll turn to Reddit to vent like u/justaverage who says:
“I’m being paid a ton of money to tell people to restart their computers, and it is killing me.”
Beyond being a poor use of employees’ time, responding to repetitive requests increases job dissatisfaction. In fact, boredom is a key contributor to job dissatisfaction in IT.
The traditional ticketing system solution to this problem has been to add a knowledge base feature. Then, when tickets come in, support team members can just search the knowledge base, find a canned response, insert it, and move along with their day.
But little bits of time add up. According to u/Lexluethar:
“It just wasn’t intuitive, and searching in the knowledge base sucked. I realize you can get really complex with things, but we just needed what the issue was, category, and the resolution. Their knowledge base template required way more input, and you couldn’t search all the fields.”
With a traditional ticketing system, employees get interrupted by repetitive questions and have to manually respond to each. This takes their attention away from bigger projects with broader impacts. Plus, on the other end of every ticket, there’s someone whose work may be blocked until they get an answer.
Every day at every company, employees need help with something. Maybe they need to add a new baby to their health insurance. Maybe they need access to specialized software to do their work. Maybe they just need to report that a toilet in the bathroom is overflowing. Or maybe they’re brand new and need help with basic things like finding the cafeteria or break room.
When the other founders of Spoke and I joined Google, we realized how big of a problem these things are for employees. When we had questions, not only did we not know where to go for answers, we didn’t even know who to ask to point us in the right direction.
Wouldn’t it be better, we thought, if there was a single place for employees to get answers to their questions and request services? Wouldn’t it be better if there was a tool that the entire company could use to capture and share knowledge and manage support requests?
With that idea in mind, we started researching existing solutions. What we found was that most companies were using traditional ticketing systems—and most companies felt these were imperfect solutions with all of the problems we discussed above.
So we set out to build something better. And we used those problems to inform how we did it.
It’s hard to get rid of the perspective that “more is better.” But sometimes more, is just “more in the way,” So, we’ve designed Spoke to give you the tools you really need—nothing more, nothing less.
The two concepts go hand-in-hand. By leveraging AI, we’re able to cut down on the amount of user interface—making the system more approachable to everyone.
Ticketing systems don’t work unless employees use them. And nagging your coworkers to file a ticket can be a pain to everyone involved.
Instead of designing with only the admins in mind, we designed Spoke for both team members and employees:
Nobody likes feeling like a human search engine. Looking up answers which are readily available is time consuming and, well, boring.
Spoke isn’t just a ticketing system. It comes with a deeply integrated knowledge base that learns as you use it, understands natural language, and supplies answers automatically.
At Spoke, we don’t just want to supply you with a better tool for managing knowledge and requests. We want to help you build a better workplace: one where employees have access to the information they need to stay productive, one where support teams—the unsung champions of the office—are freed up to focus on more engaging, impactful work.
Traditional ticketing tools aren’t built to deliver these solutions. They’re designed to create workflows—to be better than providing support over email. Unfortunately, being better than email isn’t enough.
We’re trying to fix the problems with traditional ticketing systems. What we’re learning, though, is that the best solution isn’t just another ticketing system. It’s a full-service solution that helps support teams not only track their requests, but also provides an amazing experience to everyone in the company.
That is our guidepost for what we’ve built so far, and what we plan to continue building in the future.
Let us help you build a better workplace. Sign up to try Spoke for your company or request a demo and we’ll show you how it works.
Answer these two quick questions to get a customized introduction to Spoke.