MSPs – Begin at the Beginning

Having run an IT Support Company for a few years, I arrived at the conclusion that that an IT Support Company/MSP needs the following Internal Systems:

• Monitoring System
• Remote Support & Management Tools
• Helpdesk System
• CRM/Purchasing/Logistics System
• Billing / Financial System
• Performance Review System

I used to spend a lot of time looking for ONE system which linked everything together. A system which encapsulated the way we wanted to do business, a system which allowed us ‘wiggle-room’ as we learned and a system which allowed us room to grow. And of course, I didn’t find one.

I see recently that vendors who provide software to our market have ‘twigged’ and are trying to do most of these bits now and some have even coined the phrase ‘ITRP’.

It’s a step forward, or is it?

With the benefit of hindsight, it strikes me these systems are written from the IT Support Companies/MSP’s perspective. This is, of course, the wrong place to start; systems (and software) should be written to deliver what your customers need you to deliver.

When I was running this IT Support operation, I accidentally met (and used) a consultant, a very clever one. He knew about ‘lean’ and ‘value’ relating to services. As an example:  he distilled down on parts of our business (one at a time), such as our IT Support/Help Desk.  He determined this was our value (as stated by our customers):

‘Fix my problem accurately and quickly, fix it first time. Tell me what the problem was and tell me what I can do about it in the long term (if I need to know)’

We (slowly) re-engineered our Help Desk (and its systems) to deliver what our customers really wanted and changed our systems to measure the following ‘Leading Measures’:

• Report to Resolution time (User Reports until the time we Resolved it, and by resolved it, I mean fixed the customer, not the problem and given him the long term perspective (which is of course our sales opportunity). We shortened the time and found more sales opportunities.
• First Time Fix – If we ‘handed the customer off’, i.e.: didn’t select the right guy in our company to fix it and had to get another guy involved, wasting the customer’s time.
• Accuracy – Number of cuts we had at getting it right. We cut this down massively by removing confusion and focusing on predictability.
• Communication -we measured this by ‘failure demand’, i.e.: our failure to communicate or do what our customers wanted, which resulted in them phoning, emailing or chasing something. By working on this we reduced interruption, context shifts & fire-fighting.
  We looked at what stopped us from delivering what the customers wanted and concluded that part of the problem were limitations imposed on us by off-the-shelf software and in some cases these were stopping us from working the way we needed.

And by the by, it mostly turned out we actually needed more simplicity. For example, in the end each Request in our system had only four states:

• Reported (Reported or Requested by customer, monitoring. Scheduled work).
• Technical Work Complete
• Customer Informed
• Long Term thoughts communicated.

We had a dashboard where everybody could visualise the queue of work and which of the four states each request was in.  We measured throughput and NOT billable time, hours, etc.

In essence, we focused in, on, and improved what the customers wanted (leading measures) safe in the knowledge that success (lagging measures) would follow automatically: Profit, Billable Hours, Efficiency, etc.

In the end our systems became simplified (and cheap). Our profit went up. Our business grew very quickly. All the best technical guys in our region wanted to work for us.

MSPs – Begin at the Beginning NOT with what a software sales guy tells you is important.  Begin with what YOUR customers want you to do and work backwards from there.