Get Inside Unbounce

Subscribe

Bridging the Gap between Customers and Developers

A lot of people have asked me to put pen to paper and illuminate how we keep the communication flow between our developers and the intrepid Customer Success (CS) team vibrant and healthy.

When the team was smaller the flow was easy, if there was a problem that needed a developer you’d either shout across the room, or assign it in Zendesk (the support ticket tracking service we use) and the developer would look into the problem. This worked perfectly in theory. In practice however, it had one drawback that we struggled to overcome – getting our developers to regularly check Zendesk for open tickets. For a while, we tried to convince them to log in to Zendesk on a daily basis, but over time we realized that tickets were still getting lost.

I started at Unbounce when this system was still in place and spent some time looking at our oldest open tickets. While tickets were being resolved for our customers, many had been left open in Zendesk making it very difficult to work with. We realized that our process was the problem and started to look for solutions. Eventually, we found a way to let our Customer Success team continue to work in Zendesk, while letting our developers help without ever having to leave JIRA.

On the Zendesk Side

In Zendesk, the changes we needed to make were almost purely social. Instead of assigning a ticket to a developer, you would now share the ticket with JIRA and mark it as ‘Pending’ in Zendesk while you waited for a response. This meant that individual success coaches would have to track more tickets, but none of the tickets would get lost.

Screen Shot 2014-12-02 at 12.19.00 PM

On the JIRA Side

This is where the majority of our effort was spent, and at times felt like we were trying to tame a wild animal. We needed something that seamlessly integrated into the developer’s everyday workflow and felt as natural as possible with minimal explanation required.

Since our development team uses the JIRA Agile interface to determine what they are going to work on next, we needed to find a way to get escalated tickets front and centre in JIRA Agile. We considered escalating them as bugs, but found that it implied that the developer needed to fix a bug as well address the customer’s problem. Instead we created a separate issue type with its own simplified process: Open, In Progress, Pending additional information, and Done. We also ensured that this new process was visually distinct, giving a queue to the developer that it was to be treated differently than a normal issue.

Unfortunately, to get escalations to show up in our active sprints we had to do a bit of creative tweaking of JIRA. We created a never ending sprint so that our team’s sprint metrics would not be affected by any Customer Success escalations, and then ensured that any new Customer Success ticket was automatically added to this never ending sprint. Below is a screenshot of the modification we made to the issue creation transition for CS tickets.

Screen Shot 2014-12-02 at 12.21.11 PM

Of course, we didn’t want to clutter up the board with closed CS tickets so when a CS ticket is closed it is automatically removed from the sprint.

The key aspect of this effort was to find a way to get our developers on board. Since one of our existing team agreements was to always grab from the top of the ‘To Do’ column when starting a new issue, we simply placed the CS tickets at the top, making them the priority.

Screen Shot 2014-12-02 at 11.34.37 AM

Making sure everyone stays informed

When a developer is working on a Customer Success ticket their goal is to solve the customer’s problem as quickly as they can, and ideally respond to each ticket within 24 hours. However, if the ticket requires a code change to get fixed properly, then the developer will file a separate JIRA issue and link it to the CS ticket.

This means that the CS ticket still provides all the necessary background information and that the development team can separately prioritize the issue. Sometimes this means the newly created issue will be brought into the current sprint, while other times it will require more discussion before work can commence.

If there is a linked JIRA issue, the developer can comment on the CS ticket to inform the Success Coach before marking the issue as ‘incomplete’ indicating that further work is required and will be tackled separately.

The last piece of this puzzle is to make sure that the original CS ticket is updated with the progress of any linked JIRA issues. To do this, we wrote our own JIRA plugin which comments on any linked CS Tickets when an issue is moved through our process (i.e. if someone starts work on a bug, then the success coach’s issue will have a comment saying “A related issue LP-XXXX, has been marked as “In Progress’”).

This gives us the power to automatically inform Customer Success when we have fixed a bug that directly impacted one of our customers, so they can relay this information on to the customer.

Moving forward

Since we’ve had this process in place, we have only had to make minor adjustments though there are always bits and pieces that could be improved.

One area that we know needs improving is the ‘resolution’ field on the Zendesk side, as this field only lists the state of the escalated CS ticket in JIRA, and not any linked bugs. The auto-comments alleviate that problem, but only partially. We’re working on a solution to address this and should have it put in place soon.

Unbounce’s team is growing rapidly and we are keen to get feedback and/or suggestions on how we can improve the workflow that has been put in place.

So, if you have a suggestion, have been working on your own integration with JIRA and Zendesk that you want to share or just think Unbounce is really cool, let us know!

Tynan Rollo
QA Lead