Posted by: James Murray
business growth, business requirements, Business Strategy, Cloud architecture, Cloud architecture questions, Cloud Architecture rationalization
One of my Seattle IT consulting clients had a problem. After onboarding a new client, suddenly!… They were in the midst of an IT failure cascade. It started with all the workstations that were old and past their normal life span. Then servers would begin to fail.
As technology experts we just think of onboarding as a technical process. We are migrating data, software, settings, network objects and hardware from one environment to another. We often want to do this quickly and with as minimal downtime as possible for the users and customers of our clients. Most technicians are juggling a lot so expecting them to also juggle the business side is a little unrealistic.
So as technicians we create an onboarding path for our new clients. Now here’s the rule I use for onboarding. If my client is an Seattle IT Support company, I make the onboarding process very long. If I’m my client is a customer, I may be tempted to encourage a very quick onboarding process. The quicker the onboarding process, the more liability is placed on the shoulders of the IT Support Company. So my goal with my Seattle IT Services and IT Support clients is to slow down the process.
The IT Services Company should have a big advantage when it comes to keeping down costs for IT Support. After all they have better architects designing the systems, better vision about the future of technology, system administrators with more experience and stronger technicians than their clients could afford. Put that together with a solid NOC and we should be seeing a bullet proof operation for the IT Services Company. The risk for the IT Services Company is bringing unknown systems into their environment. Each change means the possibility for failure. This is why an onboarding process for customers is so important to the IT Support and Seattle Cloud Architecture company. The contract will read something like,
We support systems within our base configuration. All systems outside this base configuration will not be supported by the SLA. As the client systems fail or are replaced, we will maintain all systems installed by us at the best possible SLA possible for the customer. All system repairs for non-compliant configurations will be priced at a discounted fix rate price.
So instead of a weekend onboard, we contract the onboarding for 6, 12 or even 18 months out. During that time the onboarding teams job is to bring all systems into compliance with the SLA requirements for the new company. When expressed this way, it makes the migration to the cloud seem fair. Nobody expects the cloud company to support all the systems, as if they were already SLA compliant, before the systems are ready. The IT support company is no protected from past mistakes and can focus resources on slowly building out the network. Onboarding actually becomes a benefit for that the sales department can use to sell the onboarding process.
Most IT support companies have problems in the first 6 months of the migration onto our site. This is often because they are inheriting the problems from your last IT Support vendor.
So instead what we do is onboard you over a 6 months. During that time will fix or replace all the problems we find that migrated from your old system. Once the onboarding process is complete and we certify your systems as compliant with our SLA, any failures will be fully covered.
So a well designed onboarding plan sets the new customer with the right future expectations.