We get letters . . .
John asks,
I understand that your definition of managed services includes operating system and software maintenance only. We have a client with a line-of-business application that has a client-server structure. When the software vendor releases an update for the application, it requires significant installation time (multiple hours) on the server and on every workstation. Would you include this in MSP as “software maintenance” or would you recommend charging an hourly rate for the work?
This is a great question because it gets to one of the biggest problems I hear about making Managed Services profitable. Rule number one is: You need to be profitable! Managed services is not intended to make you poor or make you struggle. In fact, it's intended to make you more profitable, and more predictably profitable while providing better tech support.
I always tell people: You need to draw clear, dark lines around what's included in your plans!
There has to be a limit on what's included and what's excluded.
As John mentions, I believe managed services is based on maintenance of the operating system and software. Maintenance is important for a couple of very important reasons.
First, clients understand the concept. Maintenance is to keep things working. That's why we change the oil in the car and rotate the tires. Other work is either a project or add/move/change. Replacing your ugly stock wheels with fancy, expensive chrome spinners might be important to you, but it's NOT maintenance.
Second, you can get pretty good at estimating the amount of time and money you will spend on maintenance. For example, you might estimate 60-90 minutes per server per month, averaged over twelve months. Some will be a little more and some will be a little less, but you won't lose money if you use that estimate. (That's an example; use your own estimates based on your experience.)
But you cannot estimate project labor months or years before a project pops up. And you cannot estimate adds/moves/changes. One project might be ten hours and one might be fifty. On a whim, a client can ask for thirty hours of changes. That's hard to guess months in advance across all your clients.
Maintenance is included. It is limited by its nature. It is predictable. There is NO excuse for a maintenance contract to be unprofitable.
So . . . the question about drawing nice clear lines is all about profit based on predictability.
Software Updates and Line of Business Applications
The obvious question becomes: How do we draw the line between tiny, easy, simple, patches/updates and long, complicated, major upgrades? Remember, rule number one is to be profitable. So you need to think about this before it happens.
One of the core components of maintenance is keeping things patched and updated. After all, if you have a problem with any hardware of software, the first question is going to be: What's the version level or service pack level? In other words, is it up to date? If not, tech support says to go apply all the patches and updates before you call back.
Why? Very simply, we all know that patched, fixed, updated systems have fewer problems. You probably won't call back because the problem will probably go away.
Okay. Here's where we are: Patches and all those little updates are included in managed service because they're part of maintenance. And, since these things generally require you to check for updates, apply updates, and maybe reboot, this process is small and know-able. So you can predict the time it takes, and you can roll that into your estimates when you create your plans.
But we all know there are major version updates. Whether it's a big service pack or "R2" update, these big changes take a lot more time. They may involve taking the system offline. Sometimes, you have to uninstall a previous version of either the core software or a database engine. You need to back up the data and potentially re-import it.
Sounds like a project, right? And you probably don't have a good idea if this will be a one-hour job or a three-hour job until you've gone through it. So you can't easily include these updates in the maintenance part of the agreement. Major upgrades, such as version upgrades or annual upgrades should only be included if you have a very good idea of how long they will take!
Line of Business (LOB) applications fall into this category. Examples include American Contractor, ATX MAX tax software, Autodesk, and every other kind of "practice management" software.
For an LOB with significant work on the upgrade, there are two basic options. One is to estimate the number of hours this takes each year and work that into the overall annual cost. This works great for software with regular, annual updates. For example, the MAX software used by some accountants must be updated every year for tax season.
The other option is to say that major upgrades (for example, Microsoft’s “R2” updates) are not included. So little patches are fine, but major version updates are outside managed services. This would apply to most line of business apps, in my opinion.
Notes
If you have a really good niche market, you may see a certain software package a lot. That gives you a better idea of what their upgrades involve and how long they take. After you go through several years of these updates, you will be able to work that time estimate into your managed service contracts and still guarantee profitability. But be very sure that you have good estimates!
In my Service Agreements book, I require that the client maintains a maintenance contract on all major software, so I can talk to the LOB tech support at times like this. This limits my need to know the details of a product, especially the un-knowable problems during a version upgrade. Without a maintenance contract, 100% of my labor is billable.
Finally, remember that the goal of managed service is NOT to provide 100% flat fee service. That will always reduce your profitability and we want to increase your profitability. The legitimate goal is to provide flat fee maintenance. The client should always know that there's a flat-fee component and an un-knowable component.
Remember, in all pricing, to make sure you have nice, dark lines around what's included and what's extra!
Questions welcome.
:-)
