Florian Herlings.

The importance of collaborating with customer support teams

It used to be true that we (software engineers and tech leads) heavily focused on the software development part of building products. In the last years, engineering teams learned to put more focus on the product management and the dev-ops side of things.

In this article I want to draw attention to a part of the lifecycle that does not get enough focus yet, which is how our customer success teams collaborate with the customer to deliver value for our customers. I want to answer the why, the how and also what tech leaders in our field can do to encourage better collaboration.

Benefits

The customer support teams are the working very closely with the actual users1 of your product, which allows them to get an incredibly deep insights into how users are actually using the features you and your teams built. You can spend a lot of time on research, UX and building high quality frontend code, but you would be surprised how many users will still encounter problems. No feature survives contact with the user.

Customer success teams will also be your first “line of defense” against bug reports, that are missing crucial information. By helping them to gather all the necessary information, your team will be able to fix bugs with more efficiently.

An aspect that is often overlooked is that support professionals2 are power users of your system, who probably know more about the details of existing features that the developers who built it.

What to do?

First of all, you should help customer success teams to understand the capabilities of your system. Things that come to mind are not only the features that your customers get, but also hidden features like admin sections and special export or import capabilities. You should also help them understand limitations of your system, like maximum amount of elements in a lists, file size limits for uploads and things like these. Also let them know what expected performance characteristics are (like “generating the report should take between 5 and 10 seconds”), so they can keep an eye on things taking longer for certain customers.

I have also had great success with giving CS teams direct access to the logs. Even though logs we all know that an error message like “Cannot read property name of undefined” is sometimes not super actionable, support professionals can often see patterns emerge, or recognize that the seemingly cryptic error message usually shows up, when a customer has an expired credit card (or similar). Give them something to work with, so they are not relying on you to do their work.

Something that I have had great success with is to ask them about recurring tasks that consume a lot of their time. I have – for example – seen CS teams manually create data via the user interface for hours and hours, because the system did not have a simple csv3 import functionality. Try to find out about these “low hanging fruit” feature that you could build, because helping your support team is helping your users.

Last, I want to emphasize how important it is for CS teams to know which new feature will be deployed at which time. They need to be prepared to answer questions about the cool new dashboard (to use this as an example), and silently deploying something on a Tuesday morning is not helping with that. Try to make this information accessible to them in a format that is useful to them. How to do that? Automated release notes via email are a good thing, but – at least in my experience – a quick and friendly slack message like “The new dashboard will go live today, probably around lunch time”, goes a long way.

What can you do as a tech lead?

If you are in the position to make policy changes for your development team, make sure to very much encourage people on your team to actively talk to people in the customer success team. If you can, allow your developers to pick up topics that the CS team reported to them and have them write the bug tickets themselves. Best case scenario is when the developers start actively pushing stories or bug reports into sprints. This is when you you successfully reached the point, where developers care.

In my personal experience, it is very valuable to dedicated times, where developers themselves pick up a few customer questions and try to answer them themselves. This does not only allow the to understand how users actually use the system and which kinds of problems they encounter, but will also allow them to develop an appreciation for the CS team’s work.

tl;dr / Action plan

I hope I was able to convince you that a great collaboration between dev and customer support teams is important and will greatly help your company to deliver an excellent user experience.

Here is an action plan of what you can start doing today:

  • Provide information about features and limitations.
  • Give them access to logs and monitoring.
  • Ask them about recurring tasks and add features to make that easier for them (thus saving time for your company).
  • Let them know when new features will be deployed upfront.
    • They should also have access to the roadmap / sprint planing, but this is a task for the product team.
  • If you are the dev team lead: Encourage eye-level communication between the dev and CS team.

  1. In many companies, the words customer and user are used interchangeably, but there is a fine distinction: A user is a person who will directly interact with your system in order to solve problems. The customer is the person (or company) who will be the legal partner in your contract and/or paying money. If you buy ice cream, you are the user and customer in one person. But if you buy ice cream for another person, the other person will be the user. In this dynamic, you (as the customer) might stop basing your decision on the best user experience and focus more on other things, like price. It is important to understand who your customers and users are. ↩

  2. This is also (maybe even more) true for testers. ↩

  3. CSV (short for Comma Separated Values) is a very simple file format, which is able to store table data (think spreadsheets) in a simple text based format. It is often used as a file format to export and import data from one system into another system or even for backups. The very simple file format resulted in almost all major programming languages and frameworks to have some kind of CSV integration. ↩

This website does not use any tracking or feedback mechanism. Instead, I would love for you to get in touch with me to let me know if you liked it or if you have any suggestions or questions.