Issues are raised when something doesn’t work as expected – a user can’t log in, a picture or information doesn’t display, a number on a report hasn’t been calculated correctly, a link is broken, etc. For those of you that have launched a platform or app already, today’s blog post will certainly resonate with you. Getting to launch is often the focus for many, and they don’t get a chance to think about what happens after. In a previous article, I described 3 areas that you have to consider after launch. Today, I’m going to look at one area in particular – supporting your new product.

It would be nice to think that nothing goes wrong – unfortunately, it does. When it does, you need to do something to fix it. Your developer – or the people you hire to support your platform – will probably help you with defining this process. They may also have processes in place already. However, it always pays for you to be aware of what should be involved, so you can raise questions and make informed decisions about how your product will be supported.

The first thing about managing issues (a.k.a. defects, bugs, problems, incidents) is you need to know how bad it is. In tech jargon, this is called “severity”. Issues are often categorised into different severity levels, which indicate how important it is for the issue to be fixed. You might hear terms like "critical", "major", "minor" or "cosmetic".  People also use "severity level 1, 2, 3" - where the 1 is the most critical.  You determine if an issue is "critical" based on its impact to your business and your users.  The criteria for each category should be pre-defined, so that when a new issue is raised, you can just slot it into one of the categories.  There shouldn't be a big discussion when the issue is raised, because everyone is on the same page.   

The next step is to decide when each issue needs to be fixed by using the severity levels that have been defined above. Some issues may be so severe that it requires everyone to drop everything to fix it. Others don’t have the same urgency, as there are ways to work around the problem until it can be fixed.  

The timelines that you define will depend on what level of support that you want (and can afford). If you only have users in one country, then you may only need support during business hours or maybe for specified hours during the day. Alternatively, if you have users all over the world, then you may want to consider 24 x 7 support where someone is always available to respond to issues – even at 3am in the morning!

This step is about defining a process for investigating and resolving each issue. You need to think about thing like - how users notify you of an issue; checking if an issue is valid (e.g. is it really an issue or just human error?); documenting the issue (e.g. what information do you have to provide to the technical team?); categorising issues; testing an issue to make sure it’s fixed; where you test fixes; how  fixes are implemented; etc. When you answer these questions, you'll be able to create a process for handling issues when they arise.      

Running a business is hard enough when things do go right, so it’s critical that things get fixed based on the timelines agreed. If you can’t fix an issue, it could cost you money – both in terms of lost revenue and in payouts you might need to make. Your support partner needs to be accountable for that. However, you don’t want shoddy fixes just so that a deadline can be met, so ensure that you consider quality as well. When you’re setting up your support processes, make sure you define penalties – especially when the most serious deadlines are missed.  

When you’re setting up your support process, all of the above pieces will form the basis of a contract with your technical team. This contract will define “service level agreements” (or SLAs) that set out the expectations for resolving any issues that come up. As with your initial contract with your developer, this contract is about protecting your business and making sure everyone is on the same page – especially when the worst case scenarios occur.        

Now that you’ve got all of the above setup, you need to track and monitor what happens. This is important – not just for keeping on top of what’s going on with your product – but also to understand how your product is working. Issues can tell you where people are having problems with the user experience, or a specific function that needs to be reviewed.

To manage your issues, you need to a single place to list all of the issues that are raised, and what their severities are. Issues should be given a status based on their progress through the process that you define. You should also track the dates issues were raised, and when they were fixed. All of this information will help you to stay on top of whether your technical team is meeting the agreed SLAs.      

This might all seem like a lot to take in, but once you’ve got it all worked out, you can focus on the track and monitor piece. Your technical team will have a lot of input into this too, so they’ll be able to help you. If you’ve completed a thorough test of your product, then it’s unlikely you’ll have too many issues at the beginning. However, the nature of beast is that you can’t test everything, so there’s always a chance that something will go wrong. Setting this up will make sure you’re ready when it does.   

* When you sign up for our list, we'll send you emails that include news and updates, occasional offers and promotions, and exclusive content and resources to help you on your development journey. We will not spam you. If you don’t wish to hear from us anymore, simply select the unsubscribe option at the bottom of any email that we send to you. To view our privacy policy, click here.