Most IT managed services providers we work with suffer a fundamental problem: the definition of who they are. The lack of a clearly defined definition of the business can be the biggest obstacle they face to success in the MSP 2.0 environment. The statement "I am a tech" needs to change to "I am a IT consultant." Unfortunately people often underrate themselves because they lack an MBA or they’re uncomfortable with so called “sales.” This limits them and their teams in engaging with more clients and prospects in a meaningful business way.
However, being a business consultant is just a role, a mode of operation, a mindset and the subject can be anything technical. Consulting is a behavior, a set of skills and tools that anybody can learn and implement. We are creating a series about being a consultant so you can harness the power and reframe how your clients see you.
In this first blog episode I will show you the circumstances in which it is better to act like a "consultant" rather than an "technician"
What is the consultative (trusted advisor) vs. tech (technician) mindset
First, many MSPs are under the false impression that they are having business conversations with their clients.
Be aware of this! For your clients, discussing the ROI of a VOIP is still just tech talk. Even having a chat about the financial aspects (OPEX, CAPEX) of the cloud is still tech talk. Discussing how a CRM could boost their top line is still tech talk.
The reason these are all tech talks is that in many cases the problem is created by the solution, not the other way around. This means we need to switch the conversation to talking about a potential business opportunity which the given tech-related solution could exploit. In most cases, the client did not say: "I have too much telecommunication expense", "I have too much CAPEX and want to transfer to OPEX" or "I have a sales problem” but with your expert consultation, they will be able to relate those to a technology solution you can offer. The client might be relating to these ideas in mind, but not in heart. Purchasing decisions are made using emotions backed up by logic, not the other way around.
Unfortunately the logical mind of a technician wants to speak of solutions in logical terms. That is the "I know what is best for you" mindset. And that is the telling mindset. This serves your business more than your clients, and ultimately makes your offering an expense, rather than an investment.
What if we address the business issues first and let them come to the conclusion that they have a problem? Spending time on questions and going deep into the subject not only means we understand them, but that they feel understood. Every solution we bring will be the result of a dedication to solve the problem stated. In this case, the tech projects become business projects.
This is the vCIO consultative mindset we need, and has nothing to do with having an MBA or wearing Armani suits. It is about sequence, tool set and mindset.
Let's have a look where we could use this mindset in our MSP practice:
All meetings with prospects
Every time we have a meeting with a prospect, we should wear the consultant hat. If we do, we immediately stand out in a big way. The main differentiation is that prospects usually expect to have a tech talk with a geek instead of a business conversation with an informed and experienced business consultant.
If we do not overshoot the role but just ask the proper questions and be genuinely curious about their business, we might hear something like: "Hey, I have been talking to other vendors and nobody was asking these questions..." This is the distinction we need to make..
Be open and try not to sell; you will make the sale eventually. If we trust ourselves and are courageous enough to go off the solution and focus on the issues and the problems that could form, then we are smart enough to convert those problems into tech solutions.
Firing up solutions without the business context is only noise for the client, and a false assumption for us that we have created interest.
Quarterly, yearly client meetings
I have reviewed many mature MSP's Quarterly Business Reviews. My conclusion is: reviewing MSP services like technology roadmaps during meetings is not the right way to engage clients. A consultative role lets us ask questions about their sales performance, obstacles of growth and the processes with which they are are struggling. We have to find out why the CEO is not able to sleep at night, and then help with that. In this case the meeting would be the review of their business instead of a review of ours.
Let's be proactive and challenge our clients. The best way is to start where we have experience. Every managed services provider is a process machine. Our MSP business model is all about processes, streamlining and automation. That is why every managed services provider leader has great experience with processes, human aspects, software automation, and so on. Let's start analyzing the client processes. You are going to find holes and great solutions that you can implement. These will come from your core business competencies.
Before and during projects
Technology Projects are a great way to leverage our consultative mindset. Before the project we should understand why the results of the project are required. What business benefits or deliverables will the project provide? Create a simple "Vision Statement" collecting the expectations of all stakeholders; this is a small investment of time but can be put to use during and after the project.
Use the "10 points exercise" from our MSP 2.0 Quickstarter Kit to have a better, common understanding about the goals, benefits, and expectations.
And believe me, not so many IT companies have asked the accountant or the operations manager what their expectations of the project are beforehand. So focusing on their problems and them as individuals will pay off in the long run and distinguish you now.
Any request, call we have from the client's C level
Of course, if a C-level executive calls you with a problem, there is something behind it. Most of us tech people immediately jump to conclusions, and search for solutions and so on. But our consultative mindset has to make the hard stop and ask "why?" Why do we even have a problem? Why do we need a solution at all? What are the goals, the circumstances, the context? In most cases, this is what the client really needs - to think through the problem with someone with an outside perspective who can help them to see different points of view. After a session like that you will get more phone calls about solving business problems than about fixing routers… (don’t worry, you’ll still get those calls too).
These are great ways to engage clients and open up discussions about problems that need to be solved. From this point forward nothing is going to be a tech-based project, initiative or conversation.
Conclusion
If you can just change this one thing about your communication it will pay off heavily. It differentiates you; it teaches your people how to communicate and it shows your client who you really are. This will help you to define your purposes and to communicate them accordingly. It will help you to stay always curious and focus on what matters to the client, instead of the perspective of the tech.
