The Five Most Common Mistakes MSPs Make
Businesses entrust a Managed Service Provider (MSP)—an outsourced information technology (IT) consulting company that administers, supports and maintains your organization’s workstations, servers, networks, applications, cloud services, backups, business continuity planning and cybersecurity needs, among other possible IT responsibilities—for numerous reasons. MSPs boast larger staffs possessing greater technical expertise than small and medium businesses (SMBs) can reasonably approximate. Likewise, MSPs are better positioned to keep pace with rapidly changing technology standards, solutions and practices, field help desk staff and respond to emergencies. Outsourcing IT services to an MSP also frees organizations to eliminate distractions and focus on the business’ mission and purpose.
The functions MSPs fulfill are essential to daily operations. These technical tasks must be completed knowledgeably, expertly and quickly. Proper planning, continual monitoring, effective security and prompt response are all required to eliminate interruptions, prevent delays, minimize outages and avoid financial losses.
To maximize MSP relationships, businesses should prioritize eliminating the most common problems clients experience when outsourcing IT services. But MSPs sometimes make their own mistakes, too. By knowing and understanding these common errors, your business can recognize these occasional shortcomings and more effectively assist its IT services partner in acknowledging and resolving any potential issues and proactively taking steps to minimize their likelihood or impact.
While every MSP and client relationship is unique and possesses its own dynamics due to myriad underlying factors—varying personnel, organizational size, fields of specialty and similar elements, for example—a few specific mistakes commonly arise among MSPs:
- Poor communication
- Underestimating complexity
- Overpromising after-hours services
- Promising to support unusual system
- Overlooking a workstation or network device
Learning to spot these mistakes, which can initially manifest in different ways, is an important step in minimizing and resolving trouble and building a strong, long-term relationship with an IT services provider. Most MSPs welcome client feedback and appreciate opportunities to address an oversight, simple mistake or misunderstanding early before a problem receives time to incubate and become a bigger issue. The key is to correctly isolate the error, surface the topic for discussion and quickly and effectively resolve the problem together.
The conditions and circumstances that lead to these common mistakes vary widely. Both your company and the MSP serving it are potentially blind to some of these challenges. Complicating matters, each of these issues may present as a different problem altogether, making it difficult to zero in on the root cause of a problem and take required steps to truly resolve an issue and prevent recurrence, including sometimes in a different form.
Hopefully digging deeper into each of these common MSP mistakes will better enable your organization to spot any such occurrences in their infancy. Identifying trouble early greatly assists overcoming the problem before an issue spreads in scope and complexity, introduces other challenges or becomes too deeply rooted so as to prevent pruning, removal or elimination.
1. Poor communication
Infrequent, incomplete or ineffective communication isn’t just an MSP problem. A reportauthored by Grammarly and The Harris Poll confirmed $1.2 trillion is lost each year in the US due to poor communication. The failure is endemic throughout government agencies, private-sector businesses and nonprofit organizations. The problem is particularly insidious, however, due its ability to present as different issues altogether.
Some 86 percent of knowledge workers experience communication issues at the office. The Grammarly and Harris Poll report also confirms 96 percent of business leaders believe effective communication is necessary if performance results are to meet expectations. Yet, the problem continues, including within MSPs. Certainly, the complexity of their corresponding technical functions, the importance of these functions in fulfilling daily operations and the urgency with which proper IT administration and response are required only to heighten the importance of communicating effectively.
Communication, of course, requires a sender, a message and a recipient. Information conveyed by the sender should be relevant to the recipient. Buzzwords, jargon and any potential confusing acronyms should be eliminated in favor of straightforward and clearly understandable wording. Messages should be crafted with the receiving audience in mind. Your MSP should remember you are an expert within your industry, not IT.
Lessons from project management—including the CompTIA Project+ course and certification—are a handy reference, too. CompTIA’s course instructs project managers to remember the difference between effective and efficient communications. While defining the two may seem like splitting hairs, it’s important to recognize and understand the difference. Effective communication involves delivering the proper information in the proper format to the proper recipients at the proper time. Efficient communication, on the other hand, refers to delivering the proper level and amount of information at the proper time.
One trick is to properly balance formal and informal communication methods. While formal occasions, such as project planning sessions, weekly operations meetings and status reviews, are important communications events, informal communications—impromptu meetings, telephone calls, maybe a casual lunch and emails, for instance—offer critical opportunities to continually gauge where everyone stands, confirm whether needs are being met and determine whether any required adjustments are working as hoped.
Investing in more frequent informal communications can go a long way in preventing errant communication, which can take numerous forms. Short, imprecise emails. Abrupt text messages vulnerable to misinterpretation. Insufficient voice mails. Failures to listen. Distracted attention. A prevalence for multitasking. These are all factors that impede effective and efficient communications.
Here’s how a potential communication breakdown might occur between you and your MSP. Maybe you read of a new ransomware trend that targets unpatched workstations, prompting you to send to your MSP representative an email requesting a workstation patch report. That’s all you want: a report that permits you to review the patch status of all your organization’s workstations. But the MSP resists, maybe because it doesn’t want to send a report not knowing the context and, instead, delays responding until someone has time to call and ask why you want such a report, are you unhappy, did you find an error? What might initially seem like a reasonable response is actually poor communication. If the MSP and its representatives are managing your organization’s needs properly, the MSP should already know the answers to those questions. The fact it needs to ask is, subsequently, a potentially worrisome sign.
Just as with individual performance reviews, there should be no big surprises when meeting or talking with an MSP’s representatives. Regular, ongoing discussions—whether conducted via text, instant message, email or telephone—provide ample opportunity to raise questions, concerns and any pressing topics. There should, subsequently, be no disconcerting conversations when meeting casually over wings on a Wednesday, for example, at lunch to catch up on the state of affairs. Questions, concerns, issues, problems, mistakes, failures and other shortcomings should always be addressed immediately and to both parties’ satisfaction when they arise. Permitting confusion, wariness, dissatisfaction, disagreements or other concerns to linger and grow is a dysfunctional characteristic that rarely assists a client and MSP in strengthening their relationship and working more effectively together.
Effective client-MSP communication should be accurate, precise, thorough and prompt. Questions should be well received. Both sides should dedicate themselves to prioritizing meeting regularly, reviewing dashboards and reports, agreeing on steps needed to make inevitable course corrections and following up to ensure software, hardware and services are all working as intended.
2. Underestimating complexity
If you’re a hammer, the old saying has it, all problems are nails. But that’s not how the world works. MSPs offering a specific solutions package will find some client’s specific needs a mismatch for the MSP’s standardized solution set.
Such a mismatch is not a problem if the MSP recognizes the mismatch exists and is willing to make necessary accommodations. But sometimes, in the push to assure a client the MSP is dedicated to the client’s specific needs and boasts experience supporting similar clients with similar issues in the past, problems can arise.
Take the case of a client needing to upgrade to a 64-bit version of its industry-specific software. Say the client has been running its operations successfully for years on a 32-bit version of Microsoft’s Small Business Server (SBS). The application proved the main program in use throughout the organization. This one program essentially directed most every employee’s daily tasks and operations workflows. All essentially worked well for years, but now the program’s new version is needed due to the application developer ending support for the older platform.
In such cases, MSPs are tempted to determine the third-party app manufacturer’s server requirements and quote the new server chassis and the corresponding labor required to install the server and migrate the application to the new machine. Spend any time within the industry in a consulting capacity, however, and you’ll learn rarely are any projects so straight forward.
A deeper dive surfaced a surfeit of interconnected escalating incompatibilities. The Windows SBS platform couldn’t accommodate another server on the network, so the SBS box needed replacing, which led to needing to migrate the firm’s email to hosted Exchange. But hosted Exchange proved incompatible with the company’s Office OEM licenses that, while 10 to 12 years old, were servicing their current needs fine.
So, the project rapidly expanded to requiring not just the deployment of a new server, but a migration off SBS, a new domain, email migration to a hosted solution and new Office licenses for every employee within the organization. And, further complicating matters, many workstations were becoming outdated and hosted Windows operating systems (OS) incompatible with the new Windows server OS that would be required to run the new industry-specific software program. Additional workstations and corresponding migrations proved necessary, too.
Unfortunately, such tales are not isolated anomalies. Similar issues have arisen within medical offices, at manufacturers and within real estate and development firms. IT systems are incredibly dependent upon interconnections and compatibilities across a variety of software and hardware setups. Only by pausing, asking the proper questions, conducting a comprehensive audit and carefully studying a new solution’s true requirements and dependencies can an MSP properly estimate the requirements for a new initiative. Not all take the time to do so. So when selecting an MSP, be sure to ask questions to learn the methods and systems an MSP maintains to avoid surprises later in a project.
Any resulting or abrupt cookie-cutter standard approach strategies should be met with some healthy skepticism. Instead, seek an MSP that seeks to prioritize reviewing the network, studying a new solution’s requirements and writing project plans that strive to surface dependencies, risks and incompatibilities upfront before a project begins rather than as a project is underway and scope changes become necessary. As any commercial painter will tell you, the bulk of the work painting a house is completing the preparation work necessary to ensure new paint adheres to the surfaces upon which it’s applied; despite the required expertise, the actual act of painting is typically the easier task.
3. Overpromising after-hours service
Many MSPs maintain an on-call technician. Some even staff a third shift. With such contingencies in place, it’s easy to assure clients the IT services consultancy is prepared to manage after-hours emergencies and provide support and assistance, including on weekends and holidays.
Emergencies have a way of teaming together, however. An MSP with numerous clients can actually track severe weather as it tears through a region by monitoring corresponding disconnections and outage alerts. Thunderstorms and tornadoes are infamous for knocking voice and data circuit providers offline. Accompanying lightning can destroy modems, routers and switches, the primary components that manage much of the heavy lifting for the networks that connect a company’s systems to one another and the outside world. The resulting outages and havoc, which often occur in the evenings and on weekends, can quickly overwhelm a single technician and even a small but capable team of professionals working stridently and with purpose.
The fact is it’s difficult for any MSP, regardless of size, to accurately predict the future or anticipate demand. While it’s easy to assure clients that steps have been taken and personnel and processes are in place in case of after-hours needs, crises—either in the form of storms, floods, earthquakes, tornados, a cybersecurity event or other breakdowns—arise in myriad ways that complicate forecasting the future and staffing accordingly.
Clients typically want to hear provisions for after-hours service are in place. And MSPs, especially those that are forward thinking and understand the importance of acknowledging issues quickly, are smart to implement basic processes and procedures to ensure help is available at odd times. But because neither party is necessarily motivated to truly explore the ramifications and inconveniences that can arise when crises occur or an unanticipated need demands rapid response, both parties typically believe themselves to be covered, noting a technician is on call or a small team is available working the night shift.
The mistake MSPs (and their clients) make, however, is believing business as usual can persist at night, on weekends or on a holiday. For one, the often-necessary guidance from a third-party software developer—such as a dentist’s imaging software provider—may be unavailable to explain why its software is displaying a strange never-before-seen error when trying to capture an x-ray needed to guide the treatment of a child who’s fallen on a sidewalk and chipped a tooth requiring immediate repair on a Saturday evening. In other words, other resources (including experienced technicians possessing a wealth of institutional knowledge at an ISP when an essential data circuit servicing an immediate care clinic fails) needed to assist in resolving an issue may simply prove unavailable. Yet, many MSPs may not even be fully aware of these dependencies themselves, and clients, more often than not, don’t want to think about all the ways operations can go wrong, if even for a short period of time.
Guard against such contingencies by having open and frank conversations with an MSP. Ask difficult questions, such as what the MSP does when a disaster occurs that affects multiple clients simultaneously. How does the MSP triage service and determine which customers receive service first?
Coming on the heels of the pandemic, answers might be readily available based on recent real-world experiences. Essential industries—health care, government agencies and supply chain firms receive assistance first—might be the answer and one you don’t want to hear. But by having such conversations upfront and before crises arise is the best method of setting realistic expectations and understanding how events will unfold should the need for after-hours services arise, which it certainly sometimes does.
4. Promising to support unusual systems
When mistakes of this nature occur, it’s not necessarily all the fault of the MSP. IT consultants typically don’t eagerly volunteer to provide continued support for an outdated application (of which the bankrupt manufacturer is long gone) running on an old Windows platform (for which security patches and performance updates are no longer produced) on top of aging hardware (long past its intended lifespan). But it happens, sometimes because an MSP genuinely seeks and values the opportunity to assist the customer in modernizing its systems.
Such arrangements are a losing proposition, however. There’s really no option for effectively managing unsupported software vulnerable to new and serious security vulnerabilities running on old hardware upon which components are likely to fail and an outdated operating system that is itself introducing vulnerabilities and incompatibilities of its own. Other than regularly capturing image backups of such systems, to ensure operations can be recovered when a component inevitably fails, there’s not much an earnest MSP can effectively do to properly safeguard such setups.
It’s for such reasons MSPs frequently encourage clients to update their systems, upgrade legacy platforms and standardize solutions (as reviewed earlier). With contemporary systems typically comes access to hardware and software vendors who can assist patching, troubleshooting and correcting a unique application’s issues. Underlying operating systems for updated computers further benefit from widespread hardware and software compatibility, security patches and performance updates. Newer hardware, too, is less prone to abrupt failures and corresponding outages, and when newer components fail, the likelihood of finding needed replacement parts is greater.
Yet, MSPs frequently agree to support a nonstandard, legacy system a client is desperate to keep running. Think of the MSP, in such situations, as being similar to a local earnest and talented auto mechanic whose being asked to service an outdated automobile for which parts are no longer available. Even completing basic repairs could prove significant challenges. Considering the automobile in question may not even meet new safety standards, it’s questionable whether the mechanic should even make repairs that return a dangerous or unsafe vehicle to the road.
Once an MSP agrees to support a nonstandard or unique configuration that’s well past its prime, expectations are subsequently set that the IT consultancy will keep the system running and operational. Should the consultancy later recommend updating other systems, the client could understandably seek to replicate the same efforts in place maintaining the older, outdated platform. It’s a slippery slope, in other words, that potentially leads to encouraging or adopting other bad habits, and that’s one of the reasons it’s, ultimately, a mistake for an MSP to agree to continue maintaining a solution that is actually in the client’s best interest to replace. But that doesn’t always happen.
5. Overlooking a workstation or network device
While MSPs usually work diligently to properly identify and administer every desktop, laptop, tablet, server, router, network switch, wireless access point, and other devices, occasionally one is overlooked. Unfortunately, missing even a single computer or network component can introduce other issues, including incompatibilities, network errors, cybersecurity vulnerabilities and performance-impeding conflicts.
One way your company can assist an MSP is by helping ensure all computers and network equipment are properly being monitored, administered, maintained and secured. Ask to review the list of equipment the MSP is tracking. Examine the provided inventory and confirm everyone’s computers and all known network components are listed and being tracked by the MSP. While the method isn’t foolproof, having extra sets of eyes on such reports—including your department heads and those previously responsible for monitoring and administering the network—can help identify missing equipment and ensure important systems aren’t overlooked.
Even catching a single omitted device can pay significant dividends in the long run. Consider the case of a client whose MSP took over managing its network a decade earlier. While the MSP worked diligently to properly catalog and add new systems to the network and decommission equipment being retired, and although the IT services firm worked professionally to safeguard the network and effectively secure data, trouble arose following the deployment of a new performance-sensitive SQL-based professional services application. After a brief power blip, the software began experiencing delays and performance errors that were adversely impacting SQL performance and threatening to corrupt the database’s integrity. The consultancy followed industry best practices and confirmed recent network switch upgrades met the new application’s demanding performance requirements and ruled out numerous other potential causes.
The MSP went a step further and, suspecting the presence of an unexplained network conflict, performed comprehensive and invasive testing that, while revealing almost 100 legitimate MAC addresses on the network, also surfaced a single unexplained node: a component believed to be a generic consumer-grade Linksys network switch (based upon the unexplained MAC ID). One immediate problem presented itself: the MSP had never deployed nor encountered such a device at the site, nor could such a switch be physically located within the building.
Only while sitting, exhausted, around the client’s breakroom table lamenting the untold hours that had been invested troubleshooting the problem, discovering a potential rogue device and searching unsuccessfully for the offending equipment did a long-standing client employee mention once seeing someone rearranging office furniture and a cabinet to solve a network problem. You’ve not seen an MSP’s technicians sit up so fast as when the employee recalled a technician from the original IT services firm—back when the company began business within the office the week the property opened and who hadn’t worked with the MSP or been onsite for maybe 15 years—creatively solving a network problem. The employee remembered there being a need for two cables, one for a printer and another for a PC.
After asking the employee to repeat what she’d just said, the technicians followed her to a large cabinet and desk positioned in a way that looked permanent, as if the desk were physically attached to the wall. But that wasn’t the case.
No, the employee said, the desk can be moved. With that, the technicians gingerly pushed the desk, which in fact moved. Although there was only a single computer in this location (no printer had ever been present in this location since the MSP was servicing the client), once the desk was moved several feet from the wall, a previously unknown power outlet was discovered connected to a telltale blue-and-black Linksys five-port consumer-grade switch. One network cable was connected to a wall jack, while another cable connected the workstation to that switch.
Neither the client’s office manager nor the MSP ever had a way of really knowing, without running an exhaustive network scan and painstakingly tracing each MAC address for every individual telephone, computer, scanner, printer, wireless access point, network switch, router and firewall, door access controls and other network-connected equipment—a time-consuming and expensive task—that the unmanaged device was present.
But the culprit was found. An approximately 15-year-old consumer-grade switch had begun malfunctioning following an electrical surge. The subsequent flood of nonsensical data packets on the network, a flood that helped drive the conviction a rogue network device was, in fact, present somewhere on the network, even if the physical device and location couldn’t be found, was the source of the business’ application performance problem.
That’s just one way an MSP can miss or overlook a network-connected component and how such a device can cause disruption, whether it be a computer, network switch or some other piece of equipment. So don’t take it for granted your MSP’s built an accurate list of every node attached to your network. Just as fire department connection (FDC) valves and extinguishers are prominently labeled throughout office buildings, do the same when installing any equipment that could be forgotten or overlooked, and review an MSP’s list of devices being tracked and managed to ensure there are no known omissions. A little effort upfront can save significant time and intensely frustrating and prolonged trials later.
Seek true collaboration to avoid common MSP mistakes
Most MSPs seek to establish strong long-term relationships with clients. By truly learning a customer’s needs, servicing those technical needs at competitive rates and ensuring the customer’s data and networks continue operating efficiently and securely, client relationships can strengthen and deepen, while extending a decade or, in the case of many Louisville Geek clients, almost two decades.
Although MSPs make mistakes, as these examples illustrate, most seek to provide quality services and support to their clients. The more a client understands an MSP’s processes and habits, and potential common industry mistakes, the better the client can assist the MSP in recognizing those errors, correcting for any deficiencies and avoiding any corresponding fallout.
If you find yourself still having difficulty after working collaboratively, or should you suspect other issues are present, the sooner you directly approach such deficiencies the quicker they can be addressed. And, if you find yourself unsure whether to believe or trust information being provided by your MSP—the industry is notoriously complex and the MSP might simply be failing to effectively communicate strategies in place—there’s nothing wrong with getting a second professional opinion. Legitimate MSPs should prove comfortable standing on their work and reputation. Whenever asked to present information or reports to another technical expert to assist the client in better understanding its software, network and/or systems, the MSP should oblige. If your IT services partner doesn’t cooperate or outright resists efforts to shed light on its approach and methods, that behavior alone might be a sign problems are afoot. Keep pressing until you feel your concerns are heard and your needs are being addressed competently and professionally.
