Customer Service For Software Folk

2024-May-13 • by David Norton

If you build software, you are in the customer service business. Even if that software is used internally by other developers — a Kubernetes cluster, an internal API, or a shared Python library — your customers are the engineers and other professionals that work at your company.

This gives you the responsibility of supporting that software, and answering questions from your users.

Our experience is in building software delivery platforms: tools used to support building, deploying, running, and observing software in the cloud. The clients that we support have teams managing these platforms, and they in turn support dozens of other teams that run software on the platforms.

How to create a great developer experience through customer service

Create help channels

This may seem obvious, but of course, you need to have a place where your users know to go to ask questions!

Perhaps this is a ticketing system like JIRA, but many organizations today benefit from the conversational nature of Slack channels or the equivalent in Teams/AIM/etc.

Perhaps you have both, for different situations. For example, Slack for questions and GitHub issues for service requests.

Monitor the help channel(s)

Of course, any channels you may have are not of much use if questions aren't answered consistently in a timely manner.

Members of your team need to come to an agreement on how this channel is monitored. Some teams have the on-call engineer assigned to be the concierge. Others prefer to just have the whole team monitor and answer the questions they feel confident in answering.

We like rotation as it tends to force the team to learn parts of the platform they haven't worked on, and it lets the other developers stay heads down during the day. You can always ask teammates for help if you aren't sure.

Avoid DMs

When a platform engineer is particularly helpful, they get rewarded for their helpfulness by getting direct chat messages (DMs) asking for help in the future.

This can happen to us, and we nearly always request that the user re-asks the same question in the help channel. This has several benefits:

  1. Allows the appropriate support concierge to take the support load.
  2. Allows the conversation to happen where other members of the team can offer their insight or learn from the interaction
  3. Allows the conversation to show up in search if or when somebody else has the same issue.

"Hi Annemarie, would you mind asking this on #help-phoenix? I want to make sure the right people are involved in the solution."

Have empathy, smile

Put yourself in your user's shoes. The deployment is not working. They can't view logs. Their own customers are getting errors. Whatever the situation, they're reaching out because they are having an issue, and you will do a better job resolving that issue if you can understand their frustrations.

Additionally, text-based communication lacks body language and tone of voice. Try to inject the right tone into your writing. Use emoji if that helps.

"Shoot, that's really frustrating and I'm sorry it's not working for you. :/ Let's see what we can do."

Get your users to share the right information

"Is the cluster down?" is not a helpful question in Slack. However, the user may not know how to ask a good question, and provide all the information necessary. For example, on the software delivery platform my team supports, we nearly always need:

The pieces of information your team needs may differ. Consider making this a "pinned post" in the chat channel, or using Slack bots to automatically ask these questions.

Additionally, sometimes the user will figure out the problem themselves just by looking for this information -- you are effectively "teaching them to fish" (see below).

"Would you mind sharing the error message and a link to your application's deployment pipeline?"

Search for answers

It is usually worth a quick search in the Slack channel, documentation, or Google to see if anybody else has had this problem.

As much as possible, there should be product documentation supporting your solution. Rather than rehash it every time, try to point the user to the appropriate documentation -- it will save you time.

To be clear, don't tell the user to Read The Freakin' Manual, or Let Me Google That For You. Offer a link to the documentation, but also be open that the documentation may not be discoverable, clear, up-to-date, and complete.

"I think this page in the docs might help you out - would you mind taking a look to see if that answers your question?"

Teach them to fish

If there's something the user could have done on their own to identify or resolve the issue, walk them through it and either encourage them to take the action themselves while you are there to support them if they need it.

This helps them understand the system better, and they should be able to avoid the problem in the future.

"The application seems to be failing on startup. Can I help you look at the logs?"

Walk them over

When you're at the hardware store looking for a particular type of drain pipe, which of the following statements are more helpful?

  1. "That's in aisle 10."
  2. "That's in aisle 10. Let me walk you over!"

Often there's more than one "platform" within an organization. That is to say, your user may be having a problem, but you've identified that the problem lies with another team's product. Rather than shrugging them off, offer to dig a little further or help open the conversation with the appropriate team. Your user will appreciate this.

"That sounds like a database issue, so I'd recommend trying the #help-database channel. However, let me try a few connectivity tests before we open the conversation there."

Retrospect

Now, you may have just had a great conversation with a delightful person in your company.

However, they reached out because they were stuck, and we don't want them to be stuck in the future. Additionally, answering these questions takes valuable time and resources away from development, and so you want to avoid these contacts from happening in the future (especially as the platform grows).

This is a great time to do a mini retrospective and ask yourself a few questions after each support interaction. For example, we like to ask ourselves:

  1. Was this a bug in the system?
  2. Was there an error message that could have pointed them in a better direction?
  3. Is there a feature or functionality that could be added, leading to a better user experience?
  4. Is there an alert or dashboard that could have caught this issue before the users noticed it?
  5. Could the documentation have been improved?

Any of the above could become tickets (or perhaps a quick pull request).

Make sure to let the user know that you've identified an improvement and share a link to the ticket/PR.

"I've opened this ticket as I think the error message was not clear."

Thank the user

The user gave you an opportunity to improve your product, or learn how it's used, or even learn who is using it. There is always something to be grateful for in any support interaction.

"Thanks for working through this with me, I learned something. Have a great weekend, Steve! :)"

Build a community

Internal products - be they an API, a developer platform, or whatever - have users and those users can be valuable to each other.

I love when one user asks a question, and another user answers it for them. Or they share best practices with each other.

Sometimes it's necessary to connect users yourself.

"We don't yet support canary deployments (it's on the roadmap), but I know some teams have rolled their own system. @Joe you've done this before, right?"

Conclusion

Your platform is a product

The users of your platform are customers, and they're buying your product.

Support cases are opportunities

A user is coming to you because they are stuck or frustrated. This gives you the opportunity to help them, turn an adversary into a partner, and learn something that will improve the platform.

Your users are people

In my experience most users come in a spirit of collaboration and appreciate your system.

However, even if users do come in with guns a-blazin', it is helpful to defuse the situation, connect with them, and treat them how you'd like to be treated.

If you start with recognizing that your users are stressed, overworked engineers just like you, and treating them with dignity and respect, you will go a long way.

Finally, we at Platformers love helping to build software delivery platforms. This includes technologies like AWS, Kubernetes, and Terraform, but it also includes helping your team mature and improve. Please reach out if you think we might be of some help!