Posts

Posted on

Character Not Characters

This is a departure from my usual topics. Providing support (my generic term covering all the “C” acronyms: Customer Service, Customer Success, Customer Experience, etc.) will always be the responsibility of the team that is responsible for these tasks.

Sure, there may be a “manager” role involved, but ultimately, it will be about how well the team works together, and apart, to provide the most assistance and, yes, support to your customer base.

Although experience can be significant, this is another potential fallacy: Knowing the product beforehand will not give you the knowledge you need to assist another person using it. A good manager can train any of their reports to understand and use the product as it was designed. This requires intra-team communication to ensure these intended functionalities are accurately described.

Keep in mind that the properly prepared underlying documentation will be the training resource. This again points to proper integration between the relevant teams.

This integration is going to be supported by the character of the individuals working together. This is not about employees being characters but the moral and intestinal fortitude and the commitment to their organization, i.e., their character.

A person of character can be trained. They can be incentivized with the proper management. They can be provided the tools to succeed and left to do that.

Persons of character will succeed if provided this impetus and allowed to shine. They will provide more successful and innovative approaches than any amount of forced management of their skills could ever present.

Persons of character will always be a boon to any organization but beware of characters that are not about the organization. Their thinly veiled intentions will always shine through under scrutiny. They will show themselves in unexpected ways, and it will be challenging to make the hard decisions that need to be made.

Character versus characters: choose the former to succeed; do not give in to the latter.

Posted on

Do Right. Be Right.

man with headphones facing computer monitor

Do the right thing, and be the right person.

Stop! Think about what you are about to do. This is essential and extremely easy to do when writing, especially when responding to a request for assistance.

Do the right thing. Ensure you are reaching that point where you are providing a benefit to the person asking the question or reaching out for assistance.

Be the right person. Recognize that some conversations may start from a very stressed individual that first needs to be talked off the ledge they are peering over and then providing the information they need to take a step back and resolve their issues.

In almost all cases, your response should be designed to step up to the edge with the person and then walk them back to a point where they can see the problem for what it is. Then, you can move towards the best solution to sort out the circumstances they have found themselves in where they reached out for help.

Do the right thing. Find and relay the simplest solution, and more importantly, remember this may not be the most straightforward, but it will be the one that works best.

Be the right person. Know that taking care of a request for assistance rarely has any relevance to take personally. Making every effort to empathize with the request for assistance and the person making the request will go a long way in helping them accomplish their goals.

Posted on

Providing Documentation

When providing documentation, there are almost always going to be a great many factors to consider. However, going back to a simple system of asking the “W5” will get you focused in the best direction.

Who – who is going to be reading this? Who is the documentation being focused on? Who did read it?

What – what is being documented? What does it do? What could it do? What might it best be used for?

Where – where should it be located? Not only where, in general, the documentation should be located but where updates and additions should be added to the existing documentation.

When – when will this documentation be read? When should the documentation be read? When was it read?

Why – why is the documentation necessary? There are several schools of thought on why something should be documented. However, in a perfect world, the documentation is only for those not using the service or product, to begin with, as the UX/UI itself should be designed in such a fashion that it is intuitive and self-explanatory. This may not always be the case, but we also don’t live in a perfect world.

Think of the analogy of sitting down to a bowl of soup with utensils. Granted, most people will understand the soup is food and can be eaten and choose to eat in a manner comfortable to themselves — they may pick up the bowl and drink from it, or they may use a spoon provided. Others may need to be “spoon-fed” as this is something new, and they are not certain how best to eat the soup… think of documentation as “spoon-feeding.”

Remember that too much documentation or documentation that is too complex may be seen as the equivalent of force-feeding another bowl of soup after the diner is full and satisfied with their meal. No matter how great the meal, there will always be a point where you need to stop eating.

Photo by Lightscape on Unsplash

Posted on

Personalize Responses

Responding to customers in writing daily could lead to a form of “writer’s block” where although you may know the correct answer, you still stumble over getting that information out.

One thing to consider for these situations is “canned responses” — not form letters, but more basic templates to get the ball rolling and the creative juices flowing. Communicating with customers is all about getting the information across in a form best understood by the person receiving it. A “saved reply” provides the basics; you can fill in the “blanks.”

Always use an appropriate salutation and personalize the response to the subject and the recipient.

Also, keep in mind that if the customized “template” you are going to send feels a bit “canned,” it will mostly come across as such. In some cases, this may be fine, although, for the most part, it will always be a good thing to read, edit, re-read, and edit your response some more before sending it out — make those little tweaks so your response will be more personalized and on point.

Remember, writing begets writing; consider some off-topic personal writings to shake things up and give yourself some ideas and methods to improve your written communication skills. Maybe start a blog about support?

Photo by Nick Morrison on Unsplash

Posted on

Written In Whatever Works

yes written in the sand

Wow, it’s been a while, but I’m back… at least for this post.

There are times when it does become a question when trying to establish guidelines if you are taking the “written in stone” method or the more ambiguous and flexible “written in mud” approach.

“Written in stone” implies this is how it is, and there is virtually no wiggle room for you to move outside the guideline. You essentially have to work within them which is excellent in the beginning. However, as time goes on and things evolve, you might start to see bits and pieces of your stone tablet starting to chip away.

Those strong and idealistic guidelines proved very helpful in establishing your processes and creating the environment you are working with. However, they also may have become even more restrictive than you expected as these guidelines now control your work versus you controlling the work product you want to produce.

Hence, the idea of “written in mud” comes to light. Yes, as the phrase implies, it could get messy. Still, because it offers some ambiguity and more flexibility than the stone practices, that messiness allows you to try out new things within reason and carry on with your evolving workflow.

Your written-in-mud guidelines can evolve with the times versus needing to be carved out of another stone tablet that will likely fall prey to the same ravages of time the first set of written-in-stone guidelines did.

Which approach is best for you and your projects will ultimately be your decision, although it will eventually come down to the approach: written-in-whatever-works.

Posted on

Get It Right The First Time

You’ve only added two lines – why did that take two days! ~ Matt Lacey

The above is a great read and another aspect of providing support. In this case, the premise is “fixing a bug” and getting it right the first time.

Ideally, every time you have an interaction with someone in support you will be able to provide them with a solution in your first response… and sometimes that may take a bit longer than usual but most of those times getting a solution will be much more appreciated than a quick response prolonging the support request.

Photo by Dan Gold on Unsplash

Posted on

No Shortcuts

Learning a new shortcut can often take longer than the long way you already know.

When offering a new strategy or approach to something, keep in mind following the tried and true methods will always work. Sure, it may be great to find a new and better way but not at your customer’s expense or reducing the quality of care you would have provided before spending the time to find the new approach.

This doesn’t mean to say you shouldn’t find ways to improve and enhance your approach — only that it should not be at the expense of others when you do.

Photo by Andrew Neel on Unsplash

Posted on

Communication

Quality communication is a key component to any support endeavor. You will always need to be able to convey the idea you are trying to present to another person, or persons, and how you communicate will be of utmost importance.

As a continued theme, working remotely you will most likely be using some sort of communication “tool” with your team that provides audio, video, and text channels. This post will mostly focus on the text aspects and some considerations when using it.

First off, “text has no tone” is a bit of a mantra to remember. When you are typing your message to another person try to remember to be clear and concise in the information you are sharing. Also remember, there is no body language to convey any extra emphasis and no real means to add emphasis like physically leaning in or raising your voice to animate the conversation (there are some formatting tricks you might consider but for the most part think simple monospace plain lettering as what the person will ultimately see).

Also to note, mind your language! You are typing a message, it’s not like you can accidentally drop an f-bomb into the conversation and carry on — if you type it and hit send it’s mostly going to be a done deal and there for all to see that have access to your sent message.

Take a moment to read (and re-read) the message you have written before hitting the send button. Aside from any poor choice of, or inappropriate, words you should be re-checking your spelling and grammar as well. Some things like blatant spelling and grammar errors or unprofessional language can both distract the reader as well as affect the reputation you are representing (yours and the company if writing to customers). Of course, knowing your audience is the caveat to this, if having a chit-chat is expected/wanted by the other person then it might be best to use that approach and have the content of the message much more loosely guarded.

In my personal opinion, there is no reason whatsoever to use inappropriate language (i.e.: f-bombs, etc.) in text communication. Take the time to find a better way to explain the idea you are trying to share and find better ways to accentuate these ideas… even if that means using more socially acceptable, business-friendly terms that convey the same meaning as a frakking 5hi7-storm f-bomb might.

One last point to ponder, when you are writing someone, pretend they are on the other side of your workspace and consider what reaction they might have if you actually said what you typed instead.

Photo by Annie Spratt on Unsplash