Business: The new client on-boarding process

To follow-up on my last post, one of the learning opportunities that came out of the DST effort was in our client on-boarding process. For the uninitiated, client on-boarding is just what it sounds like… the process that we follow when we add a new client. So how is this connected to daylight saving time?

Competing priorities.

For us the two most common ways that we engage a new client is through project work, or in some type business-down situation. As much as I wish that new clients all came on with clean, working systems, fully patched, using our supported application-stack… we all know that's just not how it works. What we did have though just prior to the DST change, was a CPA firm that brought us on to handle support issues and get them though tax season, as well as to do a network assessment and make recommendations to better prepare them for next year.

At the point that we brought this client on, we were running at about 125% utilization. Utilization is one of the metrics that we use to help measure our staffing/loading, and 125% is pretty high. As individuals maybe you and I can each do 150% for weeks on end, but as an organization, you can't expect to max out all of your people for an extended period of time without developing quality issues.

Getting back to the process – the client came on-board just days prior to the DST change. As a result, there wasn't enough time to schedule a proper network assessment. The on-site Engineer did a spot-check of their system to hit the highlights and... they were way out of date. The servers were all running 2003 (no SP), Exchange 2003 (no SP), no patch-management tools, out-of-date antivirus software... the list goes on. With DST approaching, we met with the client and highlighted the DST risks, and the considerable effort that would need to take place prior to the change. We then started working though the punch-list to get them covered for the DST change. Complicating this was the fact that the this is their busy season as April 15^th approaches, so treading lightly while still accomplishing everything was a key deliverable.

End result?

We were successful. Everything was patched, and functioning prior to the deadline. However, this success came a cost. From an internal perspective we were busy re-prioritizing tasks, shuffling resources, and generally making life difficult for ourselves. As a result, it has became apparent that we need a more effective client-on-boarding process. Not only should this process better address some obvious deficiencies – the hand-off from sales, technical account ownership, and network assessment projects, but also incorporate our metrics into the process. For instance, does our utilization rate, effectiveness rating, pipeline, and profitability in existing verticals support adding this client? Does this vertical present any business-specific risks? Or In other words, does this client fit our business model, and if so, can we effectively bring them on without risking current clients?

DST: A Rollout in Review

The DST change came and went this past weekend largely without incident. While our testing suggested that this would be the case –as with all things, hindsight is 20/20. So with the benefit of hindsight, I wanted to take a minute here and highlight a few items, as well as hit on some opportunities for improvement.

Successes:

• The DST Rollout was completed for all managed clients on schedule
• 100% of servers processed the time change without incident
• Less than 2% of end-user systems failed to receive respective DST updates (primarily laptops)

Despite the fact that this was largely painless for our clients, there were a number of opportunities for improvement, and in unexpected areas at that. Most notable items… the client on-boarding process. There will be more to follow on that topic. There were also some notable vendor misses that our testing either caught, or highlighted, but for which no solution was available.