Making the transition
to becoming a managed services provider can be a daunting task. Lane Smith,
president of Do IT Smarter, made that transition and shares his secrets with
you. 
So you just signed your first managed services contract, the check
is in your hand and you are ready to go. Now what? That is a tough
question to answer for many resellers that are just getting into the
managed services business. Since this is your first sale, you want to
keep it simple—selling basic monitoring and management for the
customer’s single Windows server and a firewall. The contract “go live”
date is in two days.
Unfortunately … you are already behind the eight ball. Having
told the customer that you can go live in two days, you have already
broke the first rule to starting a new contract—setting deliverable
expectations. It is certainly possible to start monitoring a network in
two days, it’s just not realistic. So now let’s talk about how this
should have gone.
There are three key things to remember when starting any
managed services contract: good communication and realistic
expectations, documentation, and process.
You already know how important communication is in keeping your
customers happy on a day-to-day basis. It is even more vital now as
they are entrusting you with some of their most critical assets.
1. Set Expectations: Allow yourself ample time to truly prepare to
support their environment. We generally allow two weeks from signature
to go live date. This is often hard as the customer is usually ready to
go when they sign. Make sure that they know that without proper
documentation and process in place you will not be able to properly
support them.
2. Communications: Don’t make the mistake of thinking you now own their
environment—they have simply given you the keys, nothing more. Make
sure that you communicate with your customer every step of the way.
Create a schedule for the next two weeks and discuss it with them. If
you change anything in their environment, let them know.
3. Training: If you have not already done so, now is the time to go
through your service-level agreement with the customer. It is very
important that they understand exactly what you are going to provide
them. Train them on all of the procedures associated with your
solution. What do you do if there is an outage? How do they contact you
to request support? When do you bill them?
Documentation is an often overlooked step. Perhaps you built the
network, already have a network diagram and know everything there is to
know about their environment. This knowledge is great; however, there
is still a lot missing. You will need to put together the rest of the
documentation you will need for your run book. Here are some important
things to consider:
1. Contact Information: Don’t just include your primary contact’s
information, but also the names of those you contact after hours. Who
can approve software installations? You also want to take a look at the
other vendors they use and ensure you have their contact information.
This applies to items like copiers, phone systems, accounting packages,
etc.
2. Device-Specific Information: Make sure you have the basics—IP
address, admin password, serial number and warranty information. Don’t
forget other essential information to support an environment remotely.
How do you connect remotely? Can you restart remotely without approval?
What is the process for patching the system? What other systems are
affected if this one is down? I could keep going, but I think you get
the point.
As with anything, you will need to determine exactly what level of
documentation you will need. Be careful because too much documentation
could provide more confusion than help. The key is to document the
information that is critical to providing remote support. Ask yourself
whether knowing what the chip set on the server video card is will
really help your technicians support the server remotely.
Now that your documentation is set, it is important to ensure
that your processes are in place to allow you to leverage this
information. What you are looking to do is identify as many support
scenarios as you can and then document the process from incident to
resolution. During the launch of a new customer, you should have a
standard set of processes that you create. These may include:
1. Contact information and escalation procedures for both during and after hours.
2. Patch management process
3. Change management procedures
4. Vendor escalation processes
5. Emergency response process
6. Deciding when to dispatch an on-site tech
7. New hire and termination processes
8. …
Remember that the beginning of your relationship can set the tone
for some time to come. Use these guidelines as a foundation for the
beginning of your contract, continually work to improve your
communication and streamline your process to enjoy a long-term
relationship with your customer.
Lane Smith is president of Do IT Smarter, a leader in
transitioning VARs to MSPs—the path taken by Do IT Smarter, which is
now a Master MSP. Lane sits on the board of several technology
companies, as well as the MSP Alliance Board of Advisors in an effort
to help educate the reseller community on MSP best practices. Prior to
his role in founding Do IT Smarter, Lane was an enterprise solutions
consultant for a large VAR, where he managed enterprise deployments of
Microsoft-based e-mail messaging solutions. He began his career as data
system technician for the U.S. Navy. After leaving the Navy, Smith
worked in various technical positions for companies in the
small-and-midsize-business market. He can be reached at LSmith@doitsmarter.com.
Knowledge Center 
/ 5 
