Accounting for Client Change Requests & Prevent Scope Creep

  • 0_1453838079817_How_to_Account_for_Client_Change_Requests__Prevent_Scope_Creep-1.jpg

    If you're an MSP with clients on fixed-fee managed service agreements, you've likely been faced with the issue of "scope creep," or unexpected changes in a project's scope. You know the situation well. One of your clients loses an employee, you have to configure a new user account or you're called upon to install applications you hadn't previously discussed. The trouble is that you don't know how to charge for each move, add or change (MAC). You either aggravate clients by surprising them with an additional bill, or you take on the work without any additional compensation. In both cases, scope creep stalls business growth by damaging client relationships, disrupting workflow and reducing margins. How do you then avoid it? Fortunately, as a former MSP who worked for All Covered, I have some experience navigating this conversation with customers.

    Step 1: Know Your Clients and Indicators of Change Requests
    First and foremost, to avoid scope creep in managed IT services, you have to take the time to get to know each customer. You should be able to predict which clients will require more MACs based on the information you gather, such as:

    the company's growth plans, both in hiring and acquiring new business
    the health of the business overall - is it profitable?
    whether the client is bound by compliance regulations
    the state of employee turnover
    Each of these situations can affect the level and amount of requests you receive. If, for instance, your client has a history of high employee churn, that should signal you to expect future MAC projects like changing user access and adding new users (if they plan on hiring) to accounts.

    Pro tip:
    One of our partners has created a custom ticket list view in his professional services automation (PSA) tool consisting of keywords associated with these one-off projects, like "setup," "upgrade," "terminate," "disable," and "replace." Creating a similar view will help you get a gauge for how many of these tasks you're typically asked to complete.

    Step 2: DOCUMENT MACs in Your MSP Agreement
    It's also worth knowing the majority of these requests surface with newly acquired clients. Many MSPs don't understand that it takes a good six or seven months to sustain profitability, enter cruise control and not have to juggle a million support tickets. Considering that scope creep is a threat from the moment you begin onboarding a new client, you'll want to get to them early enough to establish clear guidelines.

    Scope creep usually occurs when expectations aren't solidified in writing. In other words, you have to document these additional spends in your contracts. Notice how getting to know your clients and their IT environments precedes this step. That's because you can't determine how much work a client will be without getting to know each on an individual basis. Only once you've done this should you move forward with drafting a contract. To refresh you on what should be included in your Master Client Services Agreement (MCSA), here's a list of policy items to cover:

    Scope of Services
    Authorized Contact Person
    Access to Premises
    Warranties; Limitations of Liability
    Uptime; Reporting; Remedies
    and more!

    It is under Scope of Services - also known as Scope of Work (SOW) - that you should clearly articulate that you will support your clients' environments as they exist today at a fixed fee. The number you quote to one client may be different than what you bill another, depending on the volatility of their environment. Adjust your pricing to include the projects you foresee having to complete, and build this figure into the agreement, clearly stipulating how this will alter th cost if performed.

    Once you've had meaningful conversations with clients and understand how much of your services they'll need, you can prevent unwanted surprises down the line by adding these additional projects to your MSP agreement. That way, customers can't complain that they didn't know they were going to get billed for that printer add request they submitted a month later, helping you maintain client satisfaction. At the same time, you'll be able to manage client demands and know how best to deploy your techs for each site. Win win.

    But should ALL projects be added to the scope of the agreement?
    I usually advise MSPs to draw the line for bigger projects like server refreshes or infrastructure upgrades - i.e. server migrations, network upgrades, new firewall installations, new office openings and replacing servers that unexpectedly crash. These are the kinds of change requests that happen every once or few years and so should be excluded from the scope of your agreement.

    Pro Tip:
    I recommend standardizing your documentation and sales conversations around the phrase, "separate billable projects" to classify these heavier lifts. Avoid using terms like "additional fee" or "added expense," which make your services seem like a hidden cost.

    Keep reading!

  • Banned

    Are MSPs struggling with this kind of thing? I thought they would have nailed user account creation and management as part of their bread & butter.

  • One of the inherent dangers of the MSP "fixed price" model versus the time+ model. Neither is perfect, but scope creep is the fear that fixed price shops face.

  • Banned

    But is it really "scope creep" if the owner of a company phones you and says to close down an account?

    "Oh I'm sorry...we'll need to view your Master Client Services Agreement...please hold"

    Besides which, For these examples, would a true MSP not setup automation and systems to make this peanuts easy to do?

  • @Breffni-Potter said:

    But is it really "scope creep" if the owner of a company phones you and says to close down an account?

    Depends, is it clearly written out as part of the scope? If not, then yes, that's exactly what scope creep is.

  • @Breffni-Potter said:

    Besides which, For these examples, would a true MSP not setup automation and systems to make this peanuts easy to do?

    Not all have the right to do so. MSPs are not cookie cutter. Some don't handle things like accounts but only certain applications, for example. So they would have no tooling and this would be outside of scope.

Log in to reply