Around 2 years ago we began to shift from a product lead organization to a sales lead organization and part of this was increasing the headcount in the sales team from single digits to nearly 50. This rapid expansion lead to a dramatic increase in the number of internal questions for our support team and we found our team having to split focus between our customers and slack answering these questions.
I was able to work directly with our business operations team to implement HALP on our helpdesk channels and connect this to Zendesk allowing 2 way communication between a slack thread and a Zendesk ticket. I set a shorter SLA to ensure we were getting back to our internal stakeholders as fast as required. This change lead to a number of key improvements:
Questions were now sorted into their relative specializations so the right eyes were able to answer
Our team members no longer needed to monitor these slack channels allowing them more focus in Zendesk
We were able to quantify the volume, topics and time spent
We were able to easily leverage our knowledgebase and macro content
Accountability on the replies to our internal stakeholders through SLA's ensuring questions and follow-ups are not missed.
Unfortunately HALP has since been purchased by Atlassian who have moved to deprecate the ability to sync Slack to Zendesk instead opting to only allow syncing to their own service offering Jira Service Management. This meant that support needed to find an alternative solution for this functionality in order to maintain the improvements we had made above.
After a brief vendor analysis the conclusion was to attempt to recreate this functionality in house since many of the tools had extra features and increased costs that we did not need and would need legal, compliance and finance approval which would take some time.
The initial trigger to this flow is a new message posted in a Slack channel. The first step needs to check that this is not any kind of bot and does not react to the other side of the flow. From there there are two paths:
Path B is for messages that are not yet part of a thread, this is handled by a Thread TS attribute on a slack message. If this attribute does not exist then the message is the initial message of the thread. Path A is for messages where Thread TS does exist and is therefor a reply to a thread.
Path B will create a new ticket in Zendesk and importantly will store the TS of that message in a Zendesk field. Path A will first find the Zendesk ticket with the corresponding TS and instead add a new reply to that ticket. The TS becomes the Thread TS on replies to the thread.
On the other side I created a trigger in Zendesk which will, if a Thread TS exists on a ticket, send the message to a webhook in Zapier and then Zapier will clean this up since Zendesk adds lots of extra stuff to the message, it will use the Thread TS from the ticket to find the thread in Slack and add the reply back to the thread.
This allowed us to continue to have the advantages above reducing costs of HALP licences and preventing extra effort of configuring a new tool and getting it through procurement.