top of page

What to Do After Onboarding: Corrections Phase for IT MSPs

  • Writer: Yusuf Yeganeh
    Yusuf Yeganeh
  • Dec 4
  • 5 min read

Updated: 2 days ago

I. Introduction


Onboarding was successful. The users are calling up your MSP and not the old IT company. However, the issues are obvious when looking a little deeper. It might be a misconfigured switch, an ancient RJ45 connector, or a problematic user access configuration.


What should you do next?


Most MSPs mistakenly ignore such teething issues or try fixing them on the spot. This is done without documenting, planning, or communicating about it. It leads to a reactive approach that’s best avoided - it’s also a missed opportunity with the client.


Our third module is the Corrections Phase. It’s a chance to slow down, take stock, and create a solid plan.


II. Why the Corrections Phase Exists


The Corrections Phase bridges the gap between the onboarding and what comes next.

A thorough analysis enables a clean-up process of anything that was overlooked, producing a strong framework and better control over the outcome before the responsibility is handed to the support team, the vITD, and the NetAdmin.


By adopting this strategy, which includes recording unusual items, the support desk prevents unpleasant shocks. They can structure the answer appropriately by observing when an issue was identified and highlighted, either during the Corrections or Onboarding phases. The client is informed that it pertains to an uncommon problem requiring additional time to fix.


Using this approach builds trust with your new client, reinforces realistic expectations, and keeps them happily moving through the journey with their MSP. From a support standpoint, issues relating to outdated equipment or legacy software do not descend into chaos or risk the managed services contract becoming unprofitable.


III. Common Mistakes MSPs Make After Onboarding


A. Fixing Things Without Telling Anyone


While it may seem efficient to quickly address minor issues without discussing them, it’s a mistake to do so, especially if the client is completely unaware. This approach risks them being regarded as an unimportant activity.


The result is that a trust-building moment is gone forever.


All fixes require documenting, quoting for (when appropriate), and communicating clearly.


B. Failing to Document What’s Broken


A broken hardware or software solution (or one that’s unsupportable by your MSP) must be documented. It gets added to the Corrections list, making it a known issue.


When a non-standard OS or an obscure firewall isn’t noted, it is a fresh rediscovery for the help desk. Just being aware of it is insufficient because your MSP isn’t a one-person operation.


Recording it passes the information to all relevant personnel, who can tailor their support approach accordingly. As a result, the help desk performs better.


C. Dumping It All on the Help Desk


Priming the help desk to take over results in passing it on, not dumping a troublesome client onto them.


Failing to isolate and highlight any quirks or issues to be aware of hinders the help desk. Tickets require more time to resolve, and your engineers resent it.


D. Selling Too Early

Sometimes, clients pre-emptively ask, “How much will it cost to fix all this?


While it is tempting to provide a quote off the bat, avoid it. All the pertinent facts are not known yet, making any quote premature.


Instead, outline the existing problems. Let the client prioritise the critical ones to resolve. Leverage your technical expertise by giving pointers where appropriate. Build trust early and leave any quotes until a later time.


IV. How to Run the Corrections Phase Like a Pro


A. Create a Formal Corrections List


Produce a structured formal Corrections list or use a tool to include:


  • Out of standard items.

  • Why it is important (reliability concerns, risk factors, difficulty to support).

  • The effort required to fix it.

  • Impact potential if left as-is without fixing it.


The Corrections list is for the client and internal use.


B. Define “Out of Scope” Clearly


Out-of-scope areas, equipment, or software must be clearly defined as early as possible.


Remove any grey areas. This avoids a host of potential problems later.


Be sure your client is clear about:

  

  • What is included in their support contract

  • What is categorised as a project (and billable for labour hours)?

  • What qualifies as “desktop abuse”? For example, the installation of Netflix or a personal app.

  • Are server updates included in the contract? (Typically, they are not).

  • Do “impromptu moves”, such as staff relocating a desktop PC and it fails to function correctly post-move, result in an additional request to the help desk?


By drawing the dividing line early and firmly committing to it, clients respect it.


C. Pass It On, Don’t Pass It Off


Prepare your help desk properly:


  • Here is a list of what’s broken.

  • This is why it’s broken.

  • Here is how we plan to handle it.


By making the handoff clear, complete, and easy to understand, the help desk receives new clients that it can fully support.


D. Use the Corrections Phase to Set Budget Expectations


View Corrections as a prepping phase. It is not about selling new solutions to the client.


Instead, you’re assisting the client by helping them to see and understand what needs to be brought into standard in the coming months. Emphasise using proven, supported solutions to reduce the instances where their staff must contact the help desk.


When doing this, they anticipate the type of IT spending required this year and beyond. This budget alignment reduces friction points later when implementing changes.


V. Teach Your Team the Mindset


The goal is not to fix everything immediately.


The goal is to:


  • Confirm what’s wrong.

  • Know what to expect.

  • Be clear about who’s responsible.

  • Establish the plan.


When everyone is completely aligned, stress, surprises, and costs are all substantially reduced.


VI. Tools That Make This Phase Easier


The following tools make light work of this phase:


Corrections Task Template — A list of planned corrections to implement.


Standardised letter/email summarising findings — This provides an easily digestible explanation in plain English for non-technical clients to understand.


Internal + external reports — Necessary reports, such as the SAD Report, detailing what’s required on the client’s behalf. Breaks down support corrections, planned projects, and other related matters.


Visual documentation — Photos and screenshots taken both on-site and relevant to the SAD Report, NetAdmin Visit Report, and any other documentation.


Define the Edges” contract clarification tool — Clarify what is included in the contract and what is not included. It removes client doubt and is referenceable, where appropriate.


VII. Final Thought: Manage, Don’t Magically Fix


The client’s work environment is often messy. It cannot be fixed in one day. Do not even attempt it.


Look at the issues and demonstrate understanding by highlighting them to the client. Set out a robust, coherent plan to resolve the non-standard technology.


The Corrections Phase is your opportunity to avoid constant reactivity. The help desk and other team members operate from a position of clarity. This allows them to proactively manage the client and progressively work to move the client toward full compliance with the standard.


Conclusion


Onboarding establishes the right tone. The Corrections Phase creates a robust foundation for both now and the future.


Document corrections. Communicate non-standard technology calmly. Set the right expectations as early as possible.


Following this process transforms messy client takeovers into long-term, profitable partnerships.


Next steps:


 Learn the full Stamp Out Support system → https://www.stampoutsupport.com/








 
 
 

Comments


bottom of page