Hi everyone! 👋

You might have seen me on our LinkedIn and YouTube video tutorials. If you haven’t – nice to meet you!  I’m Approveit’s CMO, and I want to share with you our new case study. Approveit’s case study with… Approveit. 

We use our product internally for about 15 different workflows, and one of the most curious ones is bug reporting. There was a bottleneck in that process which was holding us back. I want to be completely open with you about our “before” and “after” applying Approveit to this workflow. 

Let’s jump into it! 

Company

Approveit, Inc. 

Problem

Our development team and customer success team work closely together. Most of the bugs are fished out and fixed before our customers see a new product version. But unexpected cases appear once in a while.  

Sometimes the system seems to work incorrectly, but in the end, it turns out to be an error in the client’s settings, expected behavior, or misuse of a feature. 

So, whenever one of our customers reported unusual behavior, customer success was poking the dev team about it immediately (to help customers quicker), and the dev team was getting frustrated with bug reports lacking proper information they could act on.

As a result, frustration all across the team and slower resolution of customer issues. 

Solution

We’ve introduced a bug reporting workflow into our internal operations. The bug report form looks like this: 

As you can see, every field is required, so you can’t submit a bug report without all the information needed for it to be reviewed. Screenshots or screen recordings can be attached if present. 

And here’s how the flow looks: 

Once our customer submits a support request reporting unusual system behavior, the customer success team immediately collects the following information:

• Who was affected by the behavior (email of the person and their access level)

• What steps were taken, in sequence 

• Are there screenshots or screen recordings of the behavior

Having all this information, customer success specialists are able to resolve the issue themselves in 70% of cases. 

If not, however, the request follows to QA engineers who determine if the reported case was indeed a bug or an expected result of the user’s actions. 

QA engineers get a notification right in a Slack channel that looks like this:

They can review and approve it right there in Slack.

If the request gets rejected – it gets rejected with a comment, explaining to the requestor why the reported case is not a bug and what should be the following steps to help the client. 

If the request gets approved – integration with JIRA fires and creates a bug ticket in our Jira Development workspace with all the information from CS team attached.  

All bugs get high development priority, and fixes are deployed as soon as humanly possible. 

Automation of this process saves our product, QA, and dev teams lots of time, keeps relationships between departments warm and fuzzy, and, most importantly, allows us to resolve our customers’ issues faster and more efficiently.