When we for the second time heard from one of our prospects, about how they were fighting to find a smooth process for managing tickets between some of their teams, we realized that we were on to something.
After several meetings and productive discussions we had enough data to see how challenging it was for many to implement something that is intended to be so easy and supportive to many of the key teams that are operating inside of a company. But yet many failed.
The common pattern was often that companies were pushing teams into the same system as their public support team was using to communicate with customers. The scenario was repeatedly mentioned with the companies we talked to. They were all trying to customize and set up flows, special rules and invest in many custom solutions to find a fit for this system with many of their teams.
Rarely was there a good fit for a ticketing system made for support, to work against several teams that were mostly dealing with internal team-to-team ticketing.
At the same time, many companies we looked into, were trying to find approaches to deal with incoming requests directly on their communication platform Slack. IT Operation, Engineering, Helpdesk, Marketing, Office management, Sales - they were all doing similar solutions on the problem to keep communicating on Slack.
They were using message threads and different emojis to triage and respond to issues, help support other teams and communicate the status of the submitted message. Ending up in overusing features like “Mark as unread”, “Remind me later” and different emojis for different meanings - resulting in lost cases and quite a mess after seeing team growth where the process couldn’t keep up.
And they were all doing it for the same reason, it was too heavy and negative to the productivity, wasting valuable time, when they were forced to use a ticketing processes outside of their natural habitat on Slack.
All teams were already on Slack, why force them to start communicating and dealing with cases somewhere else?
Why force users to adopt to a product when it should be the product who adopts to the users. It was simply the wrong way of doing it and the only solution we saw was to build a solution that provided a Slack first ticketing process.
When our first customers started to use Suptask, they were met with a solution that enabled them with a complete ticketing process in Slack that supported both requesters and responders (eg Agents) to work with tickets. Users could easily submit a request inside of Slack where responders could pick up the case, discuss privately with the team and provide a solution to the user’s request.
We found out that working with emojis turned out to be extremely popular among our customers. Therefor Suptask got adopted to this, using emojis as a way to trigger, not only reactions, but also actions. Actions that was easy to understand and powerful to support a ticketing workflow inside of Slack channels.
Every Slack user can easily filter among their tickets, all inside of Slack, to see what the status is, who is assigned on it and the latest progress. Responders have a flexible way of filtering tickets with an overview of what tickets that need attention and the status of their current active tickets.
Conversations were now happening between teams that were stunning to watch, where ticketing processes became a part of the messages that got sent between different colleagues from different teams within a company.
The conversation based ticketing system had landed and it was magic to hear how it optimized the way teams were now working. Barriers between teams were no longer there, instead teams were communicating closer to each other with the instant messaging powered by Slack together with the structured process for cases supported by Suptask.
Ever since the first teams started to use Suptask we have seen new use cases popping up in teams we never thought would use it initially.