Halp Dev Corner
June 24, 2019

How we use Halp to support Halp while building a better Halp (How to be Halpful)

Building a modern ticketing system while also using it ourselves has proven to be a huge success as we move forward in developing and building a tool that is not only intuitive but a product we stand by in every way....because we use it!

At Halp, we’re building a conversational ticketing system for modern workplaces. We’re designing Halp to be the best product for internal requests. But the product is so versatile we’re actually using it for external support too. Here’s how.


TL;DR (Too long; didn't read)

  1. Request comes in through Drift, email, or a slack shared channel.
  2. Front end sales/support person escalates it as a Halp ticket.
  3. Halp ticket gets routed to the correct triage channel.
  4. If the issue is super high priority, our Halpseater works on it immediately and updates the customer.
  5. If the issue is not very high priority, Halpseater prioritizes it in Clubhouse and updates the customer on a rough timeline.
  6. We continue to deliver world class support.


The Process

Let’s say you sign up to become a customer of Halp. Eventually you might have a support question or a feature request. 

There are 3 ways to contact us for support:

  1. Chat with us using the chat tool that lives in our web app and home page.
  2. Email us at support@halp.com.
  3. Send us a message in a Shared Slack Channel (for existing enterprise customers).

Once the request is received by one of our front-end sales people (we’re hiring a support/success person to take over this role), they answer the questions they can or assign the requests that need to be escalated to the rest of the team by making a Halp ticket out of the request.


Here’s how we handle each channel:


Drift

Our front-end sales person opens a ticket in Halp using the /halp command. This ticket then gets routed to a relevant triage channel and dealt with by the Halpseater. More on that later.

Email

Halp supports multiple support emails that route to different triage channels based on the email address it was sent to. For example, emails sent to support@halp.com get routed to our support triage channel in slack. Any replies we make to the ticket in Slack get sent as an actual email reply. We also have our security@halp.com email address routed to our #security channel (as well as to our personal emails).


This is great because we don’t have to use a separate tool to collaborate around email support. We can just command+k in Slack into the triage channel and handle it from there.  The 🔒 private reply feature here is huuuge. 


Shared Slack Channel

Shared channels are great for support. But we ran into some problems with it:

  • If one of us wants decent visibility into what issues and feature requests our customers are asking for, it’s not ideal to be in multiple shared channels. Even being in 5+ shared customer channels can be daunting if you’re not a full-time support person.
  • Managing and tracking these requests became cumbersome.
  • It became unclear who owns these requests. 


Halp + Shared Support Channels are a game changer. It makes managing requests across shared channels much more manageable. In our process, whenever someone asks for feature requests or reports a bug, we simply mark the message with a ticket (🎫) emoji.

If you’re in our triage channel, you essentially have full visibility into the major issues that our shared channel customers are having.


Without Halp, there would be no process around the message above that came in to a shared channel with one of our customers. With Halp’s Ticket Recipes this feature request ticket is routed to the appropriate feature request channel. There, we can collaborate on it privately and escalate it into our product backlog if needed.


The Halpseater

The Halpseater is a weekly rotation for the developers here at Halp. If you’re the Halpseater of the week and a ticket has come into the triage channel, it’s your job to:

  1. Reply if nobody’s done so yet.
  2. Assess whether or not the category is correct. If this is an actual bug, assess its priority.
  3. If the issue is of high enough priority, stop what you’re working on and fix it.
  4. If the issue is not very high priority, schedule it as necessary in Clubhouse (our project management system).
  5. Update the customer on what’s going on so that they don’t feel left out.


Pros

  • We like to pride ourselves on fixing things for customers as quickly as possible. Our response times are blazing fast.
  • The impact to customer happiness is undeniable. 
  • Developers get the rush of making a customer happy. 


  • Developers get real visibility into how the product is being used, what’s broken, and what features are being requested. This makes prioritizing features much easier and it reduces the risk of making technical and product decision in a vacuum.
  • Halpseater role is a shield for other developers. There is clear ownership around interrupt driven work.
  • Efficiency. We have hundreds of customers and we’ve been able to scale this process with no support person (yet...)
  • It forces us to use our own product. When we drink our own champagne it makes us realize what works and what doesn’t.


Cons

  • If you’re Halpseater of the week, you might have a hectic week.
  • Being very responsive can be a crutch for missing information in our landing page, Halp center, or just basic functionality on the web page.
  • This model requires at least one person to be in all of the shared Slack channels. There is no automatic escalation/deflection component (yet....)

If you found this article interesting and would like to stay up to date with all of our latest articles, click here to subscribe for more tips!

Read what's next

Discover

The First Slack-based Ticketing For Modern IT Teams.

Learn About Our Solutions