Support Handover Document – Keeping Support In The Loop

Knowledge transfer plays a big role in the success of software teams. In software testing, knowledge is transferred to the testing team during the requirements analysis phase of the software testing life cycle. Once testing is complete, knowledge is then transferred from the testing team to other involved people.

When testing is complete and the process is moving to production, your customer support team will start receiving questions from users about the new features/changes. It’s important that they know what’s going on because they are the ones in regular, direct contact with customers, answering product questions, writing documentation, and training users.

When your support team isn’t up to speed on what’s been changed, your customers are going to suffer.

For small teams, this can be pretty easy to manage. Your support team (or person) might sit next to the development team, and therefore have an ear to the ground on what’s going on. But in larger organizations, your support team might be on the other side of the room, or in a completely different country.

If this is the case, a Support Handover Document could be useful.

What Is The Purpose Of A Support Handover Document?

It happens all too often… testing is finished and a new feature is moved into production. Congratulations! But hold up, you missed one really important step; your customer support team doesn’t know how to use the feature. Even worse, they don’t even know the feature exists.

By staying in the loop, your customer support team is able to provide the best support possible at all times. A support handover document gives them the information needed to understand changes to the system and answer questions about the said changes.

What’s changing? When is it changing? How does it work? Any risks or issues to be aware of? All of these things need to be communicated to your customer-facing folks. A support handover document captures all of this information in one place.

What Should Be Included In A Support Handover Document?

Release Date: The support team needs to know when something is going to be released so they can prepare ahead of time and be ready to support it.

Summary of Changes: A definition of what has been changed and why? What extra value are the changes expected to provide the users? Support needs to know these things so they can speak intelligently around the changes and add context when necessary.

Known Issues and Workarounds: If there are any possible issues users could encounter, they should be documented here. Are there any workarounds? Support teams should be armed with the necessary tools to help the user successfully.

Usage Instructions: In general, how does this thing work? Your support team or documentation team is going to need to write product help documents. Give a quick rundown of how the new thing works. Maybe this means including user stories in the doc so they can run wild in the testing environment. Exploratory testing often comes into play here.

Instructions for Troubleshooting: If something goes wrong with the new feature, what steps should be taken to determine why this happened, and how it can be resolved? This might be referencing some logs or asking specific questions. Support needs to be able to solve these types of problems.

The nature of support is solving problems and answering questions. Sometimes support reps are going to hit roadblocks, but it helps to be as prepared as possible and have a good understanding of what’s being changed in the product. In a scenario where support discovers a critical defect, an issue should be logged internally and the development, or devops team, should be engaged.

Fitting This Into Your Process

Do you really need to create a support handover document? No. But if your support team is struggling to stay up to speed on product changes, it might be worth considering. So how do you squeeze this into your current development process?

I’ve seen handover documents come from testers and product managers both during and after testing. You might consider tagging issues in Jira (or whatever tool you use) as “needs support handoff” to keep track of which items require detailed communication to support. Or, once items get to a certain phase in the process, maybe you do a quick audit to see which items require a support handover doc.

Another way to transfer this knowledge is through a handover demo. Many teams have weekly demo meetings where new features, changes, or ideas are demonstrated. These meetings provide a tremendous opportunity to pass along knowledge to other teams such as support.

Bring your support team in early so that they know what’s coming down the pipeline.

Closing Thoughts

There’s no set way to create a support handover document. The key is to make sure the necessary information is shared and communicated to the right people at the right time.