The Seven Major Obstacles on the Road to Managed

Services
Whitepaper

The Sev en Major Obstacles on the Road to Managed Serv ices

Table of Contents
Introduction ... ... 3

Defining Managed Services... .. 4

The Challenge of Managed Services ... .6

Obstacle 1: Insufficient C-level commitment... .7

Obstacle 2: Lack of a standardized remote monitoring and management toolset... .8

Obstacle 3: Failure to adopt or properly implement best practices... .10

Obstacle 4: Poor value illustration to the customer ... ...11

Obstacle 5: Absence of demand generation sales ... .12

Obstacle 6: Lack of targeted marketing ... ...13

Obstacle 7: Lack of service automation and management software and processes... .14

Conclusion ... ..16

-2-

The Sev en Major Obstacles on the Road to Managed Serv ices

Introduction

Virtually ev ery IT serv ices business in North America is claiming to be somewhere in the ev aluation, planning
or implementation phase of a managed serv ices program, and y et only a v ery f ew hav e y et to deliv er high-
v alue serv ices to customers in the small- and medium-sized business (SMB) market. How is it that a business
model that has so much potential to rev olutionize the way that SMB businesses consume IT serv ices, a
business model that has captured so much attention within our industry , remains so elusiv e? Just as
importantly , why are so many IT serv ice organizations content to settle f or merely re-labeling their existing low-
v alue break-f ix and reactiv e serv ices when the business benef its of managed serv ices are so critical to their
v ery surv iv al? Why do so many of these organizations underestimate the dif f iculty of transf orming their
business to become a true managed serv ice prov ider (MSP)?
In order to answer these questions, it is important to f irst clearly def ine what managed serv ices are and why
this business model makes sense f or both y ou, as the serv ice prov ider, and the customer. Once a clear
def inition of managed serv ices is established we can begin to look at the key components required to deliv er
real managed serv ices v alue and subsequently the major reasons IT serv ice organizations f ail in their mission
to deliv er that v alue.

-3-

The Sev en Major Obstacles on the Road to Managed Serv ices

Defining Managed Services

Ov er the past sev eral y ears, the phrase ”managed serv ices” has morphed into an umbrella term to describe
v irtually any lev el of outsourced IT serv ices - ev ery thing f rom semi-automated break/f ix activ ities all the way to
high-v alue, SLA-driv en engagements. This dilution of the managed serv ices intent is unf ortunate f or both the
customer and the IT serv ice organization, as it will preclude both parties f rom achiev ing the f ull potential benef it
of a true managed serv ices program.
Many people believ e that an MSP is any IT serv ice organization that prov ides remote monitoring capabilities to
complement more traditional break-f ix and block serv ice engagements. While there is certainly a market f or
monitoring as a low-v alue serv ice, the real opportunity lies with organizations that hav e a greater dependence
upon IT. Though remote monitoring is a key piece to the puzzle, true v alue-based managed serv ices is much,
much more. Managed serv ices is a method of IT serv ice deliv ery through which y ou can prov ide the same, or
more, v alue to a customer as an internal IT department deliv ers in a large enterprise - only in a consumption-
based model that makes f inancial sense f or ev en the small business owner. To completely understand the
v alue the customer expects f rom y ou as an MSP, y ou must f irst rev iew the f undamental purpose of IT within
the business env ironment.
The purpose of IT, in a v ery general sense, is to automate or enable business processes, thereby allowing an
organization to do something that otherwise couldn’t be done, or alternately would cost exponentially more to
accomplish. So it’s ultimately about creating productiv ity and business v alue - and the f unction of the IT
organization (internal or external) with respect to that v alue is two-f old: to ensure that existing sy stems continue
to appropriately support and enable the business processes, and to recommend and deliv er new solutions that
will help the business driv e more productiv ity and business v alue in new way s.
The second part of the equation - the deliv ery of new IT serv ices - is well understood in the industry and
requires little discussion here, except to say that as the relationship between y ou and y our customer ev olv es
into a true strategic partnership, so too will y our ability to ef f ectiv ely recommend and deliv er solutions to the
customer ev olv e. As y ou come to know y our customer at the strategic and tactical lev els, y ou will be in a much
better position to make recommendations on IT solutions that will positiv ely impact y our customer’s business.
Similarly , the trust f actor that is inherent in a strategic relationship will mean y our customer will hav e f aith in
y our recommendation and will more of ten incorporate the recommendation into their ongoing business
planning.
The f irst part of the equation - the support of existing sy stems within the customer inf rastructure - is where the
problems generally arise. Many IT serv ice prov iders f undamentally don’t understand (or don’t accept) the
customer’s expectation of IT, which of course is that once technology is deploy ed it will continue to work
perf ectly f orev er. The f act that this is entirely unrealistic and f lies in the f ace of logic is irrelev ant. The upshot of
this is that as soon as there is an IT f ailure, the serv ice prov ider has already f ailed and no amount of heroics
will change the f act that the sy stem stopped working. The reason customers expect (or want to expect) that IT
is inf allible is that the business has become so dependent on IT sy stems such as email that, f or many
businesses, operations v irtually shut down when a major IT f ailure occurs.
While the customer expectation of unstoppable IT is impossible to deliv er, it helps us to begin to f ormulate a
conceptual idea of what a v alue-based managed serv ices program is: a collection of IT serv ices that av oids
and mitigates the business impacts that arise f rom IT f ailure as much as possible. This is a good start, but
we’re not quite there because deliv ering higher and higher lev els of uptime costs more and more money . Logic
dictates that as the IT av ailability target approaches the unachiev able goal of 100% uptime, the cost to deliv er
the serv ice begins to increase logarithmically , which of course is neither af f ordable nor required by the v ast
majority of customers. So then we update our concept of managed serv ices: a collection of IT serv ices
designed to av oid and mitigate the business impacts that arise f rom IT f ailure to an acceptable lev el f or the
customer.

-4-

The Sev en Major Obstacles on the Road to Managed Serv ices

We’re v ery close at this point, but there is still one other major element to consider and that is IT-enabled
business risk. It is ironic that while IT enables so much productiv ity , it is also a source of incredible business
risk. Consider that while we hav e database sy stems that allow us to store and manage customer inf ormation,
that inf ormation is now v ulnerable to exposure in way s that it nev er was bef ore; while email allows us to
communicate globally in near real-time, it is a constant source of v iruses, spy ware and other f orms of malware.
A f ailure to manage these risks may result in huge amounts of IT downtime (of which the customer deems any
amount to be unacceptable), inf ormation loss and thef t or worse - civ il or ev en criminal penalties. A f inal
rev ision to our concept of managed serv ices prov ides a solid working def inition: a collection of IT serv ices
designed to minimize the inherent risks associated to IT as well as av oid and mitigate the business impacts
arising f rom IT f ailure to acceptable lev els f or the customer.
Hav ing nailed down the v alue that the customer is looking f or in a v alue-based managed serv ices engagement,
we can begin to understand how y ou, as an MSP, prov ide that v alue in a scalable, cost-ef f ectiv e manner. The
answer is simpler than it seems; the ty pes of serv ices that combine to prov ide the desired business v alue are
actually f airly well understood in the enterprise. The key is re-inv enting the deliv ery model of those serv ices so
that they can be prov ided in the centralized, remotely managed model that is the hallmark of managed
serv ices.
The ty pes of IT serv ices that combine to deliv er the v alue that businesses (large and small) are looking f or
include:

• User and desktop support

• Emergency inf rastructure support
• Proactiv e maintenance
• Security and risk management
• Business continuity management
• IT / business interconnection
• Hardware as a Serv ice
While the common approach (monitoring plus break-f ix) begins to touch on reducing the business impact of IT
f ailure, it does so in an entirely reactiv e manner - which also happens to be the lowest-v alued component of
the of f ering since IT shouldn’t hav e f ailed in the f irst place.
Each of the abov e def ined components of a f ull managed serv ices of f ering is complex enough in an enterprise
env ironment where the IT organization generally has the adv antages of proximity and a singular set of
corporate expectations. For y ou to prov ide the f ull range of required serv ices in a cost-ef f ectiv e, highly
prof itable manner to a wide range of customers requires caref ul planning, attention to detail and excellence in
execution. Now it becomes clear why so many IT serv ice organizations f ail in their pursuit of true managed
serv ices, or decide not to try at all. Simply put, building an organization that is actually capable of deliv ering that
v alue in a consistent, scalable manner is really hard.
Fortunately we can be a little more specif ic. Hav ing worked with a large number of sy stems integrators, VARs
and IT serv ice prov iders through the business transf ormation process, N-able has identif ied sev en key
obstacles that stand in the way of true managed serv ices:
1. Insuf f icient C-lev el commitment
2. Lack of a standardized remote monitoring and management toolset
3. Failure to adopt or properly implement best practices
4. Poor v alue illustration to the customer

-5-

The Sev en Major Obstacles on the Road to Managed Serv ices

5. Absence of demand-generation sales activ ities

6. Lack of targeted marketing
7. Lack of serv ice automation and management sof tware and processes

The Challenge of Managed Services

We hav e discussed the def inition and rationale f or managed serv ices, as well as introduced the obstacles with
managed serv ices. If the benef its of managed serv ice deliv ery are so pronounced, why are so many serv ice
prov iders struggling with their transf ormation to becoming a true MSP? The core reason is that they are not
try ing to transf orm their business and this is the greatest challenge of managed serv ices today . Too many
serv ice prov iders v iew transf ormation as being a problem solv ed by technology , when in f act the scope f ar
exceeds just technology to impact ev ery f acet of the business. By f ocusing entirely on the technology
dimension, usually just on the remote monitoring and management aspect, it means they are ov erlooking the
other six obstacles that prev ent their success. As a result, they wonder why they are struggling in their
initiativ es to sell and deliv er prof itable managed serv ices. On the other hand, organizations that make a
successf ul MSP transf ormation recognize that they must address all sev en obstacles.

-6-

The Sev en Major Obstacles on the Road to Managed Serv ices

Obstacle 1: Insufficient C-level commitment

Unquestionably , one of the tenets of good business is that success begins at the top. This is certainly true f or
IT serv ice prov iders making the mov e to managed serv ices. Without the commitment of the owner, CEO and
entire management team, the shif t to managed serv ices will f ail. Why ? Too of ten organizations approach
managed serv ices as if it was a mere extension of an existing business line and does not need management
time and commitment. Becoming an MSP is much more than an extension to an existing line of business.
Rather, it is a new line of business with v ery dif f erent driv ers and success f actors that require the absolute
commitment of the CEO, partners and management team.
Top-lev el management needs to recognize the f ull business commitment required to build a successf ul MSP
practice. They must embrace and champion this new business model, leading the charge to transf orm the
company by incorporating prov en operational and sales and marketing best practices f or managed serv ices
success.

-7-

The Sev en Major Obstacles on the Road to Managed Serv ices

Obstacle 2: Lack of a standardized remote monitoring and

management toolset

The purpose of a tool, any tool, is to automate and enable processes. The processes are those things that we
do that prov ide tangible results (v alue) to the customer. Most MSPs recognize the need f or a remote monitoring
sy stem, but that is only one tool in the arsenal. Unf ortunately , a common practice f or many MSPs is to
supplement their lack of a standard toolset with whatev er tools the customer already has on hand - the
rationale being that since the customer has already paid f or it, there’s no reason to spend money on another
tool. In actuality , nothing could be f urther f rom the truth.
Adopting whatev er tools happen to currently exist at the customer location has sev eral dangerous ramif ications
f or MSPs interested in growing their business in a prof itable manner. This practice essentially destroy s any
opportunity y ou hav e f or dev eloping standardized processes that are essential to the deliv ery of high-v alue
serv ices, it dramatically increases y our cost of doing business and it can hav e a signif icant impact on y our
ability to deliv er a consistently high lev el of serv ice to y our customers.
Standardized processes are essential to an organization that intends to grow in a prof itable manner because
only by doing things in a planned, structured way can y ou understand the cost of doing so. Additionally , y our
organization needs to hav e a single, structured approach in place so it can sy stematically work to improv e and
optimize both the quality and ef f iciency of those activ ities. Tools support and automate elements of a process;
that’s f undamentally all they really do. In doing so, they become an intrinsic part of those processes they
interact with. So much so that substitution of one tool f or another (substituting one set of behav iors and
perf ormance lev els f or another) of ten means that the process is no longer the same - or at the v ery least the
execution time and cost characteristics change completely . Multiply this ef f ect across y our entire customer
base and y ou’ll f ind y ourself reduced to a break-f ix serv ice organization once again.
Properly dev eloping and maintaining subject matter expertise on any giv en toolset has real and implied costs
f or y our organization. Those costs may be direct - in terms of actual dollars spent on training courses - but
more of ten (and more insidiously ) are the indirect costs, consumed in terms of ramp-up time, technician
research and worst of all incompetence in the f ace of y our customer. By and large, these costs can’t be directly
passed on to a customer - they are simply a cost of doing business. A standardized toolset, howev er, means
y ou can minimize those costs by reducing the number of v ariations of a giv en tool to one.
Clearly y our company - just like any business - cannot justif y pay ing f or a solution that y ou do not need.
Howev er, this happens f requently among many MSPs, as they acquire solutions with f unctionality that will not
be used because it is not required f or a specif ic managed serv ices engagement. For example, y ou might hav e
a new customer whose inf rastructure includes 20 routers, switches and other dev ices that carry a minimal
management burden. Howev er, y our remote monitoring and management solution includes remote support and
remote env ironment management capabilities. While v ery usef ul f or PC and serv er support, this adv anced
management f unctionality represents a waste of money because it is not needed to ef f ectiv ely support routers,
switches and other low-management dev ices.
So, f or a managed serv ices toolset to be truly cost-ef f ectiv e, it must prov ide f lexibility so y ou can tailor y our
serv ice deliv ery to address each customer’s unique needs. In the case of management specif ically , a standard
toolset is needed to prov ide core management capabilities, complemented by optional tools f or remote support
and remote env ironment management. This means y ou only pay f or the f unctionality needed to deliv er the
appropriate lev el of management capabilities to each of y our customers.
Tools that are appropriate f or an IT administrator to use within a LAN env ironment may not be applicable to the
MSP model because of security and operational ef f iciency . Networked tools that are designed f or local use may
transmit and receiv e sensitiv e data in an insecure manner. On a local network this may not present a problem
as the perimeter security inf rastructure reduces the risks surrounding this. MSPs, on the other hand, rely on the

-8-

The Sev en Major Obstacles on the Road to Managed Serv ices

Internet as the key v ehicle to connect their centralized network operations center (NOC) inf rastructure to their
v arious customer inf rastructures. Transmitting that same unencry pted inf ormation ov er the Internet may imply
risk that neither y ou nor y our customer can af f ord to accept.
Additionally , many tools designed f or use on a single LAN just don’t support the MSP model in an ef f icient
manner. A good example of this is a tape-based backup sy stem. As an MSP, y ou can’t change, rotate or store
the tapes f rom the comf ort (and ef f iciency ) of y our NOC, unless y ou rely on y our customer to perf orm this
critical part of the process (risky ). This activ ity requires y ou to send a technician on premises to perf orm
backups. An MSP-f riendly solution, on the other hand, would allow y ou to prov ide the same serv ice to y our
customer - in this case, saf ekeeping of the critical data - in a manner that remov es the operational ov erhead of
a customer v isit.
Another major issue when using these tools is the cost and ef f ort of deploy ing remote monitoring to y our
customers, as well as the ongoing administration of customers. MSPs of ten spend a great deal of time on
customer deploy ment because the process can be complex and requires technicians with considerable skill
and experience. The result: the cost of deploy ment is excessiv e and it is dif f icult to standardize monitoring
policies f or similar dev ices at dif f erent customer sites. All of this combines to create a real impediment to rolling
out managed serv ices to y our customers
A larger issue ov er the long term is the continuing ef f ort required to administer y our customers once remote
monitoring is deploy ed. When y ou need to make a change to a serv ice, such as establishing new thresholds f or
alerts, the time and ef f ort required is excessiv e. Ev ery dev ice that uses the serv ice has to hav e its settings
updated again, which increases y our serv ice costs. In addition there is the risk that some dev ices will be
ov erlooked, so y ou do not hav e consistent rules. In the ev ent there is a change at the dev ice lev el that impacts
monitoring, all of the dev ices hav e to be touched again. Each touch is not a recov erable cost, so it impacts y our
bottom line.
While these costs can be calculated and passed on to y our customer, it adds a degree of dif f iculty into the
sales and quoting process as the operational impacts of the customer’s toolset need to be considered and
added to the price. More of ten, the MSP simply ignores the operational ov erhead and once again absorbs the
inherent costs, jeopardizing the prof itability of the engagement.

-9-

The Sev en Major Obstacles on the Road to Managed Serv ices

Obstacle 3: Failure to adopt or properly implement best practices

True managed serv ices programs are based on v alue - not time. In other words, there is no mention of the
number of technician hours included in true managed serv ices programs. This is a f undamental change to how
IT serv ice prov iders hav e behav ed in the past, and it carries with it its own set of risks and rewards. The
reward: ef f iciency improv ements that reduce the number of technician hours required to deliv er the v alue will
result in an improv ement to y our bottom line. In a time-based model, the customer would notice that y our
technician was not spending as much time prov iding the serv ice as bef ore and, quite correctly , demand a price
decrease. The risk: f actors that increase the amount of time required to prov ide the serv ice will lower y our
prof its.
The single largest f actor that af f ects the amount of time required to prov ide a serv ice is the operational
management of serv ice deliv ery processes. Deliv ering true managed serv ices in a prof itable manner requires a
v ery consistent approach to serv ice deliv ery and serv ice management. Without this lev el of control, it is
ef f ectiv ely impossible to ev en arriv e at a cost to deliv er v alue-based serv ices, nev er mind consistently
achiev ing or exceeding the targets.
Ef f ectiv e processes describe how people perf orm v arious tasks. Good process management ensures that
ev ery body who perf orms that task does so according to the process - in an identical f ashion, time af ter time.
As y ou can imagine, this giv e y ou the ability to accurately assess the amount of time to execute the process
with v ery little v ariance f rom indiv idual to indiv idual - and ev en that v ariance can be measured and optimized.
Clearly def ined processes prov ide y ou an opportunity to continually improv e upon those processes f rom both a
quality of serv ice as well as a cost of serv ice perspectiv e. Regular process rev iews pav e the way f or y ou to
reduce the number of manual steps required, either through automation or process improv ement.

- 10 -

The Sev en Major Obstacles on the Road to Managed Serv ices

Obstacle 4: Poor value illustration to the customer

Historically IT serv ice prov iders hav e illustrated the v alue prov ided to the customer in terms of the number of
technician hours prov ided. This is f ar f rom ideal f or y our customer and downright problematic f or y ou. From the
customer’s perspectiv e, it is dif f icult to draw a direct line between the business benef it of the serv ice and the
time taken to deliv er the serv ice. From y our perspectiv e, this model of v alue illustration doesn’t prov ide a lot of
incentiv e to build ef f iciency into the serv ice deliv ery model, as this ef f iciency would only serv e to erode y our
rev enues. Since a key element of a true managed serv ices program is the use of serv ice automation
technologies and process optimization to reduce the ov erall cost of serv ice deliv ery , alternate means of v alue
illustration must be dev eloped.
In a managed serv ices world, v alue illustration is comprised of awareness activ ities, reports and report analy sis
that perf orm the f ollowing f unctions:

• Educating the customer about managed serv ices

• Illustrating achiev ement of serv ice-lev el commitments
• Prov iding strategic direction to the customer
As prev iously discussed, the ty pical customer v alues IT in terms of the number of hours required to deliv er the
serv ice. The customer believ es this because we, as an industry , hav e taught them that this is the correct unit of
measurement. In order to mov e f orward, y ou need to replace this unit of measurement with other units of
measurement to ensure that the customer will recognize the v alue y ou deliv er. This is ty pically done by hosting
an initial orientation session f or all of y our customer’s stakeholders at the start of an engagement,
supplemented by ongoing awareness and education newsletters.
Once the customer understands how to measure the v alue y ou prov ide, it is incumbent upon y ou to illustrate
that v alue on a regular basis through serv ice lev el reporting. A serv ice lev el report prov ides a breakdown of
ev ery serv ice lev el objectiv e def ined within the serv ice lev el agreement (SLA) and illustrates both the
commitment y ou made as well as the actual achiev ed perf ormance lev els f or the reporting period. The
objectiv e is to show customers that they are getting what they paid f or - or alternativ ely , that the perf ormance
targets were missed and some def inable actions are occurring as a result (penalties, etc).
Many smaller businesses av oid technology as much as possible, taking the approach that the more dependent
they are on technology , the more pain they ’ll be in when it breaks. Ultimately this giv es their riv als an
opportunity to lev erage a competitiv e edge to gain customers, reduce ov erhead and generally out-execute
them. Businesses tend to take this attitude because historically the business impact f rom their existing IT
sy stems has prov en to be so problematic that they hav e little reason to adopt ev en more technology . Engaging
with an MSP will address these business impact issues, which allows the customer (with help f rom their MSP)
to begin to look at new technologies as business innov ations. This prov ides a key element of v alue-illustration
f or y ou as an MSP. By helping customers dev elop their IT strategy in terms of what ty pe of solutions may help
to driv e rev enue and reduce operational costs, y ou can demonstrate y our true v alue as a trusted adv isor to
y our customer.
Value illustration in a managed serv ices engagement extends f ar bey ond any thing possible in a traditional IT
serv ices model. By making a commitment and quantif iably achiev ing the targets set out in that commitment -
as illustrated by ef f ectiv e serv ice-lev el reporting - as well as prov iding strategic and budgetary direction to the
customer, not only do y ou contribute to a better-managed business today but a much more successf ul
business tomorrow.

- 11 -

The Sev en Major Obstacles on the Road to Managed Serv ices

Obstacle 5: Absence of demand generation sales

Selling managed serv ices is a much dif f erent beast than selling hardware or implementation projects. In the
case of hardware and sof tware, it is the v endor that traditionally generates most of the demand and it is the IT
serv ice prov ider who f ulf ills that demand. Projects tend to be the natural extension of selling hardware and
sof tware and, as such, f all into the same category . Managed serv ices, on the other hand, are much dif f erent
because they aren’t a product prov ided by a v endor but rather a serv ice prov ided by y ou as the MSP. Y ou are
the v endor, so y ou must generate demand f or the serv ice.
The other element that adds complexity to the situation is that prospects aren’t waking up in the morning
thinking about outsourcing managed serv ices - not because managed serv ices aren’t a f it f or their business but
because they hav e no idea what serv ices are av ailable or how they can be of benef it to them. This places the
selling of managed serv ices in a category known as ”missionary sales” where the sales people must preach the
”gospel of managed serv ices”.
Ov ercoming these hurdles requires a dif f erent approach to sales - one that f ocuses on demand generation
activ ities supplemented by a reasonable approach to sales management. Sales management is ty pically an
area of weakness f or many IT serv ice organizations that, due to their background, tend to hav e v ery strong
technical management but much less management depth in sales or marketing.
A common f ailure among MSPs try ing to ev olv e their sales f orce towards demand generation is to hire a ”killer”
sales guy and expect magic to happen. While a charismatic salesperson with a background in solution and
serv ice sales is important (especially f or missionary sales) to the ov erall success of the program, managing the
activ ities that lead to sales is just as important. Solutions/serv ices sales prof essionals who are charismatic and
capable of executing a missionary sales program and who are also disciplined enough to self -manage their
own activ ities do exist, but they are def initely exceptional indiv iduals. The thing about exceptional indiv iduals is
that they are (by def inition) the exception, not the rule.
A better approach is f or y ou to manage sales by mandating y our sales team to identif y what activ ities are
required as part of the sales process and what quantities of each activ ity are required in order to driv e the
desired sales. Once these activ ity targets are established, the sales team needs to ensure that the planned
activ ities are happening and that the desired results are occurring.
Dealing with the lack of awareness within the market requires close collaboration between marketing and sales.
From a sales perspectiv e, a well-conceiv ed sales process - probably longer than most IT shops are used to -
should aim to educate the prospectiv e customer on the benef its as well as mechanics of managed serv ices. It
should culminate with y ou deliv ering an ROI (return on inv estment) presentation that illustrates the prospect’s
total cost of a managed serv ices program as compared to their current cost of IT (in terms of business impact,
risk and actual IT spending).

- 12 -

The Sev en Major Obstacles on the Road to Managed Serv ices

Obstacle 6: Lack of targeted marketing

Unlike many traditional IT serv ice prov iders that operate without a marketing f unction, an organization looking
to of f er true managed serv ices will hav e dif f iculty f unctioning without a marketing department. In a traditional
VAR env ironment the v endor carries the load f or marketing the product and generating demand. Since a
managed serv ices program is, in ef f ect, y our product as the MSP, it f alls to y ou to market y our programs and
generate demand f or y our serv ices.
In pre-launch mode, marketing acts in a product management capacity , prov iding the driv ing f orce behind the
y our MSP program dev elopment, determining what IT serv ices the market is looking f or and what price the
market is willing to pay . Marketing ev aluates the competitiv e landscape, def ines a marketing strategy , dev elops
the business requirements of y our MSP program and the appropriate messaging, then works with sales to
create the sales pitch and appropriate tools to support the sales process.
In a post-launch env ironment, marketing is responsible f or dev eloping a v erticalization strategy , generating
qualif ied leads f or sales and lev eraging email, Web, phone or any other number of campaign strategies to keep
the pipeline f ull of good opportunities. Additionally , marketing works hand-in-hand with the sales organization to
ov ercome the lack of market awareness - dev eloping newsletters, email communications, educational
seminars and other end-user awareness tools - all tactics to educate the consumer on the benef it of the
serv ice prov ided, establish y ou as a leading prov ider of the serv ices, and ultimately f uel demand generation.
Internal marketing is also a key f unction of a successf ul MSP. Incidents where the MSP f ails to achiev e its
serv ice lev el commitments tend to be common knowledge within the MSP sales organization (especially when
customers hav e a tendency to call their sales person to complain), but news and statistics on successes and
wins are of ten generally unknown within that department. If lef t unchecked, the natural tendency is f or sales
people to dev elop a jaded v iew of the product they are selling. This is of course v ery dangerous, as sales
people need to believ e in their product and the message they ’re deliv ering. An internal marketing program aims
to ensure that y our employ ees hav e a more balanced v iew by prov iding the company in general - and the
sales team in particular - with inf ormation about the successes of the managed serv ices program y ou of f er.

- 13 -

The Sev en Major Obstacles on the Road to Managed Serv ices

Obstacle 7: Lack of service automation and management software

and processes

Since managed serv ices is a grass-roots mov ement, it is not surprising that many , if not most, MSPs hav e
ev olv ed f rom traditional IT serv ices organizations (VARS, sy stem integrators and resellers). Just as y ou hav e
gone through an ev olutionary dev elopment, so too hav e y our internal practices - not necessarily f or the better.
A common practice that is inef f icient, inef f ectiv e and potentially dangerous is that of deliv ering all lev els of
serv ice support through the use of named technicians. With this approach, y our customer has a relationship
with a specif ic technician within the IT serv ice organization. That technician is responsible f or prov iding v irtually
all ty pes of IT serv ice support. The problems with this model are as f ollows:

• Scalability
• Quality of serv ice
• Cost of serv ice
• Misplaced relationship
• No corporate memory
In the model where a technician is specif ically responsible f or a def ined set of customers, there are a f inite
number of customers that can be assigned to that tech bef ore the quality of serv ice becomes detrimental to the
IT serv ice organization’s business. With this in mind, the only way of adding new customers is to linearly add
more technicians, which creates a business model that has serious scalability concerns.
There are two main components to the quality of IT serv ice support - timeliness of the serv ice and capability of
the technical resource to deal with the specif ic problem at hand. Both of these components suf f er under the
named technician model. Since IT f ailures are unpredictable, it is impossible to predict how many customers of
a technician will be experiencing problems at a giv en time. As soon as that number climbs abov e one,
somebody is waiting f or serv ice, meaning that timeliness (serv ice quality ) is immediately af f ected.
Regardless of how small or big a customer might be, there is a bare minimum lev el of complexity inv olv ed -
desktops, serv ers, networking, security and potentially much, much more. The practice of naming a single
technician to a customer immediately assumes that the technician is an expert in all required areas. Not only is
this impractical, but it is essentially impossible. IT has ev olv ed to the point where each of these areas is a
recognized specialty , each requiring its own set of skills, certif ications and background. So while it’s reasonable
to assume that a technician may be an expert in one, or ev en sev eral, of the IT disciplines, it is guaranteed that
the technician will not be an expert in all. This absolutely guarantees that y our customer will experience a
technical issue at some point that y our technician is not qualif ied to support - thus dramatically af f ecting the
quality of serv ice.
The cost of serv ice support is a f unction of the total amount of time spent resolv ing the incident. The cost of
that time is the f ully adjusted hourly cost of the technician and the ov erall technician utilization rate (somebody
has to pay f or unbilled time). Put another way , the cost of serv ice support is directly af f ected by the scalability
of the serv ice, the rate of pay of the technician and the ef f iciency lev el of the incident handling process. The
named technician model inhibits the optimization of each and ev ery one of the contributing f actors.
The named technician model is a monolithic process where by and large the single named technician perf orms
the entire serv ice support f unction. It is well documented in the process-engineering world that monolithic
processes of this ty pe are orders of magnitude less ef f icient than modular processes that allow f or indiv idual
tuning of the capacity , skill and cost of each component of the process.
Since the named technician must be capable of handling most, if not all, issues encountered, ev ery technician
must meet a certain skill lev el and is presumably compensated according to their skill and capability . The truth
- 14 -

The Sev en Major Obstacles on the Road to Managed Serv ices

of the matter is that many , perhaps most, of the incidents that occur do not require a senior, or ev en
intermediate, resource but could easily be f ielded by a junior technician - at a f raction of the cost.
In order to maintain any semblance of timeliness of serv ice, y ou must employ enough technicians to handle the
load. Ty pically this results in a technician utilization rate of between 40 and 60 per cent. This has the net ef f ect
of approximately doubling the cost of serv ice support.
In the named technician model, the customer generally has a great relationship with the technician and v irtually
no relationship with any one else on y our staf f . This puts y ou at considerable risk. Should the technician decide
to leav e the company , y our customer might be strongly tempted to f ollow.
In most cases, the only inf ormation that is tracked and maintained is the prerequisite data to substantiate billing
f or the incident. While the indiv idual may hav e an opportunity to learn through experience, y our company as a
whole maintains little knowledge of the problems or solutions that hav e occurred in the past or the nature of the
business relationship with the customer.
A properly implemented serv ice management solution, including a managed serv ice desk, solv es all of these
issues by breaking the monolithic process into a series of modular processes (incident management, problem
management, change management) that can be staf f ed according to v olume and skill requirements at each
lev el and centralizing the relationship at the serv ice desk. In other words, a pool of junior (inexpensiv e)
resources work on solv ing easy problems, while complex issues are escalated to a pool of senior resources
with the appropirateskill set. The net ef f ect of this change is as f ollows:

• Driv es up technician utilization - By working with the f irst av ailable technician, as opposed to a
specif ic technician, y ou can generate a much higher technician utilization rate.
ed,
• Driv es up quality - By working with the f irst av ailable technician, timeliness is immediately improv
and by escalating issues to appropriate specialists, the capability of the technician with respect to the
incident is improv ed as well.

• Driv es down cost - A number of f actors contribute to a dramatic decrease in the ov erall cost per
incident, such as the increased technician utilization rate, the number of incidents that are managed by
lev el 1 (junior) technicians and the reduction in the amount of time required to resolv e a problem due to
improv ements in the ov erall process.

• Relationship with y our customer - In this model of serv ice support, the v alue that y our customer
receiv es is prov ided by a number of people representing y our company as a whole, not by a single
resource. This dramatically reduces the risk of losing customers if a specif ic technician decides to leav e
y our organization.
In addition to these core benef its, a centralized managed serv ice desk prov ides other opportunities f or y ou to
generate improv ements and cost sav ings. Initiativ es such as a self -help portal prov ide additional v alue to the
customer as well as help to reduce the ov erall number of incidents that are managed by y our serv ice desk. A
well-conceiv ed serv ice management solution will not only enable a self -help strategy but will integrate,
automate and underpin many aspects of y our business f rom the serv ice desk to the project activ ities all the wa y
to generating billing f or the activ ities and serv ices rendered.

- 15 -

The Sev en Major Obstacles on the Road to Managed Serv ices

Conclusion

Many IT serv ice organizations limit their serv ice of f ering to a reactiv e v ariation of managed serv ices, with the
sole intent of adopting the label of managed serv ices. This practice does little f or them and ev en less f or their
customers that actually require a higher lev el of serv ice. Deliv ering a true, v alue-based managed serv ices
program is a complicated business model that requires caref ul planning and consistent serv ice deliv ery
execution. While the sev en key obstacles are the most common points of f ailure f or those MSPs that do wish to
adopt a true managed serv ices model, they are not insurmountable, and awareness of the pitf alls is the f irst
step to ov ercoming them.

- 16 -

The Sev en Major Obstacles on the Road to Managed Serv ices

About N-able Technologies ®

N-able Technologies is the pref erred global supplier of remote monitoring and management technology and
business transf ormation serv ices f or managed serv ice prov iders. N-able’s prov en platf orms of f er the right
combination of technology , people and processes, which help IT serv ice prov iders to deliv er highly prof itable
managed serv ices to small- and medium-sized businesses. www.n-able.com

Copyright
Copy right © 2007 N-able Technologies.
All rights reserv ed. This document contains inf ormation intended f or the exclusiv e use of N-able Technologies’
personnel, partners and potential partners. The inf ormation herein is restricted in use and is strictly conf idential
and subject to change without notice. No part of this document may be altered, reproduced, or transmitted in
any f orm or by any means, electronic or mechanical, f or any purpose, without the express written permission of
N-able Technologies.
Copy right protection includes, but is not limited to, program code, program documentation, and material
generated f rom the sof tware product display ed on the screen, such as graphics, icons, screen display s, screen
lay outs, and buttons.
N-able Technologies and Monitor Manage Optimize are trademarks or registered trademarks of N-able
Technologies International Inc., licensed f or use by N-able Technologies, Inc. All other names and trademarks
are the property of their respectiv e holders.

www.n-able.com
inf o@n-able.com
1-877-655-4689

MA-VEL- 3.0- WP-1. 1 -ENUS- 7OBST ACLES -RES

- 17 -