Monthly Archives: June 2015

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.

Is it bad to be smart?

by

I started writing this blog post about a year go. At the time, I had just come across a blog that introduced the idea that in business it is bad to be described as smart (In business, it’s actually a bad thing to be called smart). The author differentiated that it wasn’t about just being smart, but “being smart as your primary value.”  His premise was that people who were smart or talented as a primary value tend to get exploited more than anything else. “To call someone smart implies their other skills don’t measure up and, in business, people want solutions that work and productive relationships, neither of which require intelligence. What people usually describe as intelligence is what I call abstract problem solving.”

At first I was a little taken aback by this notion.  In general, I highly regard intelligence.  I have surrounded myself with smart people.  Not all of these people could be considered rocket scientists (although that applies to some), but they have intelligence across many different facets of life and have proven that time and time again. After I thought about it some more, I do get the point the author was trying to make. Being smart is just not enough. If someone is solely smart, they are marginalized to only the tasks that keep him/her in a bubble. Generally, we don’t want to interact with someone who can’t interact with us in return.

A good friend from graduate school coined the term “stupid smart” for people who were too smart for their own good. It describes people with high intelligence, but not enough common sense or other redeeming qualities. We often used this phrase to define personal decisions where we had overthought; missing a fairly simple ,often better solution.

At the end of the day, I want to be seen as someone who gets the job done well. This may mean solely managing it day to day, or getting my hands dirty to delivery. My passion lies in solving complex business problems leveraging different technologies. While that might make me smart, I do think there are adjectives I would rather see used to describe me first.