What's your support customer profile?
Who are these clowns emailing you all the time, anyway
Welcome to the new home of Andy’s Support Notes! I don’t want to spend much time on the why rather than the what, so suffice it to say: there were too many Nazis and other folks I didn't care to share a bar with. Now on to the logistics:
- Emails will now be coming from andy@supportnotes.org and should continue coming from there for the foreseeable future, even if I later change providers again.
- New posts will continue to publish at 9AM ET on Mondays, so if you don’t get one next week, check your spam folder and please move it back to your inbox. It may take a little while for this new sending domain to develop a good enough reputation to keep it out of the penalty box.
- Archives are all here—links and images may be messed up. I’ll be working through all of the back issues in my spare time to fix, but please bear with the dust in the interim.
I think that’s about it! Please do let me know if anything in the archives is particularly jacked up and I’ll take a look. Thanks for reading, and now for your feature presentation.
This week let’s talk about something a bit less controversial than LLMs and stick to real people talking to real people. Can you tell me, in one sentence, your typical support customer profile? I don’t mean the kind of company that buys your product, or the kind of persona Sales is trying to sell to, or even the technical champions your Customer Success team are cultivating. I mean, day to day, what kind of person is throwing things over the transom of your support inbox? If you can’t answer that question, why not?
Defining your customer
‘Support customer’ is a little awkward, so from here on out I’m going to just talk about ‘customers’. But we’re going to be focusing on the folks who are reaching out to your team day after day. So what are they like? There are any number of ways to categorize them, but here are some features that I’ve found instructive in the past.
- What are your customers knowledgeable about? It’s important that your engineers are able to keep pace with them, or at least be aware of the basics. For example, if your customers are software engineers, your team should at least understand the rudiments of software engineering, the typical workflows, and concepts like source control and CI/CD (continuous integration/continuous delivery). If your customers are data scientists, your team should know about SQL and non-SQL databases, Jupyter notebooks, and so on. Having a basic understanding of the field will save time and trouble when working with your customers, and help build credibility.
- What concepts do your customers need help with? Being aware of your customers’ typical shortcomings and blind spots is also important for your engineers when explaining concepts that may be unfamiliar to the customer. If your customers are software engineers but the product you’re supporting is a sales tracking tool, you’re going to have to bone up on Sales Terminology 101 to make sure you can answer their questions effectively. Data scientists, faced with a DevOps tool, may need some extra handholding when grappling with Terraform. When your team is well prepared to explain concepts and terminology that the customer may not intuitively understand, you can provide extra value to the customers who are reaching out for assistance with your product.
- Is your customer employing the product for work or for personal use? Though I’m mostly focusing on B2B (business to business) support teams here, it’s worth thinking about whether your customer is using your product for their job (and may have had no influence on purchasing this particular product, or even preferred a different one) or an individual buying your product for their own personal use. The way customers will approach asking support questions may be very different depending on how they came to use your product in the first place.
- What is your customer’s organizational position? Are you dealing with individual contributors (ICs) or managers? Are they bringing support issues of their own or on behalf of others? This will have a bearing both on how to prioritize the issues they bring to you as well as how regularly they may expect updates, especially if they’re beholden to other end users within their organization!
- What are your customer’s communications preferences? Do they prefer that you stay in regular contact, or do they chafe at regular check-ins? If your customers tend to be very busy, they may appreciate occasional nudges, but on the other hand they may resent what they see as busy-work preventing them from doing their jobs. While there can be a lot of variation from individual to individual here, you can probably pick up on some general trends across your customer base around how regularly they prefer to hear from you on longer-running issues. Relatedly, how do they like to communicate? Will they answer emails or do they prefer to send you Slack messages? Do they wish they could call you?
Spend some time with your team to answer these questions, and any others that make sense for your team to help characterize your customer profile. Look through recent tickets, talk about any memorable customer interactions your team members have had lately, and a picture will probably start to emerge.
Implications
A good understanding of your customer profile is an insight that can be applied to many aspects of your team’s operations and future planning. Here are just a few places that you can put this information to good use.
- Communications style and cadence: Most obviously, understanding how your customers prefer to communicate with you can have immediate impact on your team’s communication choices and methodology. Email or Slack? Chat on the website, or phone support? Understanding how your typical customer prefers to stay in touch with you, and how frequently, will help you figure out how to build your team’s communication standards and modalities.
- Support engineer recruitment: I mentioned this a while ago, but I have had great success in recruiting customer engineers by looking at people with profiles much like our typical customers. When serving DevOps engineers, try to hire folks with a DevOps background if they’re available and excited to shift into the support world. This gives your engineers a jump on both what the customer already knows, and where they might need additional assistance.
- Team training priorities: Once you understand what your customers know, and what they don’t know, you can take a hard look at your team’s existing knowledge base. If you’re serving software engineers and half the team has never opened an IDE (integrated development environment), make it a priority to close that knowledge gap. If you notice that your customers are struggling to write good Terraform code in order to integrate your product into an existing IaC (infrastructure as code) setup, get your team trained on Terraform. Investing that time now will pay off manifold as your customer base expands and comes to you with more of the same questions.
- Capacity planning and other logistics: As you get to know your typical customer better, you’ll gain a stronger understanding of about how much they’re going to need your help, and what kinds of help they’ll be looking for. This, in turn, can be of great use when planning for future support needs. If your customers are very technical and tend to only need assistance with really thorny bug reproductions, you will need to take that into account when you know that a thousand new users are being onboarded over the next year. On the other hand, if your users tend to only need simple troubleshooting steps that are inexplicably not yet in your documentation, you can save yourself a lot of time and salary expenses by simply improving your documentation rather than hiring more engineers.
Do keep in mind that your customer profile is likely to shift over time, and it’s important to regularly revisit your assumptions about your customers and the kinds of problems they’re reporting. But this information is well worth gathering. If you can’t quickly define your support customer persona today, take a little time and try to build that profile with the help of your team. What you come up with might surprise you, and will definitely be useful to you in team and process planning.
Thanks for reading Andy's Support Notes 💻💥📝!