Category Archives: Customer Success

3 Hallmarks of Customer Service

by

I read a blog recently that discussed exceeding customer expectations in an e-commerce context. This got me thinking about customer expectations in the broader business sense. Customer service has been a huge part of my business education from my own family’s businesses as well as other successful small businesses I’ve been a part of. I do think there are a few variances to how you should exceed customer expectations in a business to business (b2b) environment as compared to business to consumer (b2c).

The most critical components of delivering exceptional customer service in a consulting environment are trust, honesty, and communication. While these all 3 go hand in hand, each should be considered a separate initiative you need to foster as your relationship develops over time.

Trust

Consulting, like many other types of b2b businesses, is built on trust. Your customers are trusting you as experts or supplemental resources. They are often sharing the most basic aspects of their business with you so you can provide a service. The entire sales, implementation and customer success experience is about building that trust. If you do something to cause that trust to be questioned, every decision you make comes into question. This ultimately challenges who the customer buyer is and what they believe.

Lack of honesty or poor communication are two ways that you can quickly and easily deplete that trust.

Honesty

I think we all know how important it is to be honest. Unfortunately, sticky business situations can often challenge our abilities. For example, the situation where you are the “expert” but don’t know the answer to the question; or where you were unable to complete one set of customer work because you were too busy with another. I have found that your best option is still to be as honest as you can. In the first example, you can say “I don’t know, but let me know find out for you.” This is generally an acceptable response. Customers tend to appreciate this more than making something up, then having decisions made based on incorrect information. It takes less effort to wait to make decisions until after you have the information than it does to have to make corrections later on.

In the latter example, it was regrettable for you to have gotten to this question at all. Ideally, you would have clearly articulated what you were going to accomplish and when, setting very clear expectations. This might have involved a discussion around urgent versus minor issues with respective response times. Depending on the customer relationship, this may have also included a more detailed discussion around your prioritization model (don’t have one, see defining your customer prioritization model).

Communication

Almost every misunderstanding comes from poor communication. This might be lack of communication or poorly articulated communication. It doesn’t matter as these are equally bad. Communication is how you are show your honesty to your customers and how you build that trust. It comes in many forms – from quick social media engagements to project engagement emails, to marketing sales contact and training materials. Your honest voice must carry through every piece of communication, in order to build and maintain trust.

Project Coordination vs. Project Management

by

For as long as I can remember, I have described myself as a project manager. I found it was the simplest way to explain what I did. In reality, I have been a Sybase database administrator (DBA), systems analyst, software team lead, business process manager, implementation manager and most recently, a customer success manager. At the end of the day, I get s**t done. I found that the term “project manager” was the simplest way for people to grasp what I do.

I have started to wonder whether I’m using the right term. As I compare my methodology to how others are managing projects, I wonder if “project manager” may not be inclusive enough. Additionally, the response I get from resources involved in my projects often is one of pleasant surprise. Their prior experiences or preconceived notions of what a “project manager” is has left them jaded and unimpressed.

A few years back I was brought into an organization by a mentor and former boss to help alleviate his workload so he could focus on raising money for the organization. Prior to my entrance into the organization, everyone did everything for their customers. There were no project managers. This resulted in project delays and the curse of constantly switching gears to focus on the biggest fire. At first there was subtle push back and doubt as to what value I was bringing to the table. Out of necessity and as a result of the influence of my mentor, the project resources started engaging me on the basics – timelines, status, meetings, etc. As I got more involved and took on more responsibility (i.e. owning the documentation, managing the communication, pursuing the missing information) those same resources started to come around to me as a “project manager.” I believe they view me as the exception rather than the rule.

More recently, I overheard a conversation regarding a project where technical resources were responsible for writing status reports and updating the project team. This very much confused me as I have always felt that this function was a core responsibility of the project manager. After probing a bit, I learned that the project manager did not understand the technical solution and therefore was unable to provide descriptive enough project statuses. I understand that the project manager is in an oversight role and will rarely understand every detail of how a technical resource plans to implement, but I don’t understand how they are going to oversee every piece of the project if they don’t understand individual components.

These are just 2 anecdotes that make me ponder whether I misunderstand what a project manager is or incorrectly associate this term to what I do. A good project manager requires equal parts operational understanding, technical skill and project coordination.

PM

Operational Understanding: To manage a project effectively, it is imperative to understand how that project fits into the big picture.

  • How does it impact the business unit?
  • What motivates the project owner?
  • How will it impact the project stakeholders?

If I don’t understand that the goal of the project is to significantly reduce costs or improve efficiencies in order to prevent layoffs, I may not see or understand the anxiety of the stakeholders or the project owner. I may also not know the right way to motivate the team or get to the root cause of disagreements.

Technical Skill: Furthermore, it is crucial to have an active part in the technical conversation.

  • How do you step in to test or troubleshoot?
  • How do you mitigate disagreements between technical resources?
  • How do you translate between technical resources and the business owners?

Technical skill allows me to get my hands dirty when required. It is the reason that I can play “cardboard batman” to work through complicated project issues. It also allows me to step in and mitigate disagreements between technical resources, and pursuasively communicate decision “whys.”

Project Coordination: Lastly, it is critical to know what goes into running a project.

  • How do you estimate a project task?
  • How do you allocate resources and make sure milestones are met?

This is the nitty gritty of running the project. It’s the logistics – status meetings and reports, milestones and gantt charts, task estimation, etc. These are the basics you need to know. Unfortunately it is not enough to make sure project successful. Only by combining the basics of project coordination with technical skill and operational understanding can you truly get s**t done.

Defining Project or Customer Prioritization Models

by

I’ve come to appreciate the difficulty of project prioritization.  Historically, my teams only ever really had internal customers.  In some ways that makes the decision easy – you focus on the biggest revenue opportunities or impacts first.  Operational issues came first, with development coming second.  This problem becomes exasperated when you are in a consulting situation where there are multiple customers, with multiple customer teams and often, conflicting priorities.

At the end of the day, people want to do the right thing.  Ultimately what happens when you combine a lack of project prioritization with people who are striving to “do right by the customer” is time spent on non-priority tasks or employee burnout trying to meet everyone’s needs.  Neither one of these outcomes is optimal for teams.

In our personal lives, we make prioritization decisions everyday. Most often we put things we need to do (i.e. eat, take care of children, work to support family) before other things (i.e. sleep, exercise). This may not be the best long-term decision, but it is the best decision we can make at the time it comes up. The nature of business complicates this problem significantly as ever customer needs to be treated with respect. Each customers’ problems are the most important to them. If every organization had infinite resources, dedicated teams could exist to service each customer.

Unfortunately, resources are limited and you have to make trade-offs. People do understand this. They may not like it, but it ultimately comes down to how well you set and manage those expectations. An organization should evaluate their core values and align their prioritization methodology to it. While large and small customers should not necessarily be treated the same, it is important to make sure that you have a strategy for handling both sets of customers. This exercise must be re-evaluated on a regular basis. Some common prioritization considerations include: customer size, project duration, complexity, strategic project nature.

Customer Size: This really comes down to revenue. Your largest customers bring the most money to the organization and therefore need to be kept happy. Sometimes, some creative solutions might need to be introduced. This might be dedicating a team to customers over a particular size, or providing on call services to these select. As I mentioned before, the downside of this is you can’t do this at the expense of all your other customers. They won’t be ignored.

Project duration: If you can focus on a project, get it done quickly and make a big impact, there is value to making this a priority. There is a risk to constantly pulling resources in and out of new projects. You might want to consider a roaming “quick-hit” resource squad to rotate through these types of projects. It can be a great way for more junior resources to learn and grow, continuously being introduced to new case studies. Duration can also negatively impact prioritization as covered by complexity.

Complexity: Complexity is an interesting consideration. Who defines it and how does this impact how you use your resources? A project might be considered complex if it is something you have never done before; or it has quite a few moving pieces and is expected to take a really long time to complete. Additional complexities might have to do with hard deadlines outside your control. One way to minimize the impact of complexity on prioritization is to separate a complex project into more manageable mini projects. You can then prioritize based on your other factors. There may be a few cases where you will need to evaluate project complexity as a factor. This may increase prioritization of the project in order to meet strict deadlines, or it may reduce prioritization of the project given the state of other business and projects.

Strategic Project Nature: We all are aware of opportunities that come along and introduce us to a new market, technology or methodology. These can come from the large customer looking to push the limits, or a small customer willing to take a gamble on us. The upside of these types of projects can be significant, but if things go wrong the project could impact project duration, revenue, and resource allocation.

Once you have your prioritization factors, you need to decide how to weigh them. Giving each consideration equal weighting does simplify the process, but that may not work given your customer and project mix. You might be in the middle of a pivot and need to put greater emphasis on the strategic project nature than you do on customer size. You also need to determine your scale for assigning value for each prioritization factor to each customer or project. This can be as simple as rank order for the number of projects or customers. It could also be a simple 1-n scale, with n equal to 5 or even the number of factors you are using. For both weight and scale, make a decision and move forward.

This is an evolving process, so define a few prioritization factors as a starting point. Once you choose your weight and scale, you have a solid prioritization methodology. Apply this to your customers and projects. You should start seeing the benefits within a few weeks. Projects should finish and your ability to set and meet expectations of your customers should improve. Feedback from your customers will deliver the biggest set of data points. Adjust accordingly.