How to Start a New Managed Services Contract

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.

Resource Library:

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.