Author: Edward Caissie

Posted on

Revenue Retainers

A common perception of most customer support, customer success, and customer experience (let’s be honest, these are all the same–let’s say CX for short) teams is that they are not revenue generators. This is true. Simply put, they are not best used for sales; that’s what the sales team is paid the big bucks for.

CX teams are best suited to tend to customer needs and ensure they remain. A potentially significant part of the customer experience is providing them with happiness and enjoyment of the product or service they purchased from the organization. Keeping the customer happy is a significant retention goal.

If you retain a customer into the future, you also keep the potential for future earnings that the company can realize from that customer. It is important to make certain the CS team is empowered to keep the customer happy.

Another possibly more critical idea to remember is that you also need to keep the Customer Experience (CX) team happy and motivated. They may not have earned you that first-dollar from the customer. Still, suppose you train them well and empower them to do their job effectively. In that case, they will earn you the potential for those future-dollars, and let’s face it, potential sales are almost as important as the immediate sales that are often overshadowing what your CX team has done for you.

Customer care (yes, yet another term for customer experience, etc.) does not ask, “What have you done for me lately?” It’s asking, “What have you done for me in the future?”

It is vital to future-proof your organization with a strong customer care and experience team focused on keeping your customers happy and engaged. This could mean a steady revenue stream rather than an overworked sales force.

A business is a holistic entity, treat it that way.

Posted on

Documentation Rule #1: Break It

“How do you ensure thorough mobile responsiveness testing?”

One of the most important things to consider was the thoroughness of the progress testing with their checks and balances. A deadline should not define the testing procedures of a project; those procedures and processes and their timelines should be built into the project’s time budget.

Emulators can help, especially for larger projects provided they can be scripted or automated to ensure a fully holistic approach to the test.

Regarding its effectiveness and ease of use, Luddite testing is essential to any project. Establishing the minimum level of technical adeptness needed for the project requires building a focus group to test with.

More to follow…

~ Edward Caissie

I have taken the above from a recent LinkedIn invitation to share my perspective. This is the following…

Testing can play a significant role in the support processes for any application, whether it be a mobile project, a desktop project, or any other project genre. The group assisting when needed should be involved in how it is used and utilized. While there may be a bias toward in-house support services, this is where their training also needs to come into play.

The project’s documentarians also need to be involved in the testing processes. In their case, the most straightforward rule of thumb is to “find ways to break it.” Suppose you know how to break something, with the ideal being extreme edge case usage. In that case, you can provide documentation that leads the reader, or viewer, depending on your medium, to not fall into those potential issues. Please document how to use the project while steering clear of any possible problems.

When faced with a shortened timeline or one that may have been unrealistic, your documentation and those who write it will likely be the best way to provide the final testing a project needs.

Could you find ways to break it?

Could you ensure documentation avoids these pitfalls and, more importantly, provides information on achieving the same goal or obtaining the same information?

The first rule of documentation is to find ways to break it.

Posted on

Lead. Follow. Friend.

positive diverse friends with bike walking on street

Managing your team is a lot like coaching your family. In some cases, you like the person, and there is mutual respect, so the management is easy. In other cases, you simply did not choose your family, but there they are all the same.

Don’t walk behind me, I may not lead.
Don’t walk in front of me, I may not follow.
Just walk beside me and be my friend.

Anonymous

Through many years of experience, I have learned the above does not apply, so why do I want to share this somewhat well-known quote as part of this conversation?

Let’s break down the whole thing to understand better how you can use this all the same.

Don’t walk behind me, I may not lead.

Yes, you can work with the understanding that your team will blindly follow your instructions, but they should be helped and coached to accomplish the goals you set for them. Please work with your team to maximize their skills and talents.

Don’t walk in front of me, I may not follow.

You should not be following behind your team to pick up the pieces. Your job is to manage your team so they can recognize when something gets missed and how to reconsider best and pick up their pieces. Following behind is tantamount to micromanaging, which ultimately will drive down productivity.

Just walk beside me and be my friend.

This quote is almost valuable on its own. However, what it means to be a friend should still be considered, as should creating a friendly atmosphere. A very fine balance needs to be maintained in this case.

Developing a friendship with a team member can have many valuable benefits, but it can also create an atmosphere where directions are not followed or ignored. The friendship can smooth over the indiscretions, but that does not get the work done. Creating a friendly atmosphere will promote better, more transparent conversations and more constructive feedback in both directions.

In life, take the full quotation as you will, but with work-related situations, remember that, in general, and at best, the quotation is both a guideline and a warning. Make sure it serves you well in either case.

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

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.