Wim Kerkhoff built TopLeft because his own MSP kept hitting this wall. Projects that should have taken 200 hours were clocking 800. Clients were happy, but the team was underwater and the margins had quietly disappeared. Sound familiar?
If you have ever finished a project and wondered where the profit went, scope creep is almost certainly the answer.
Scope creep is not one big catastrophic decision. It is a hundred small yeses that nobody tracked. A technician stays an extra hour to fix something that was not in the contract. A client sends a Slack message asking for "just one more thing" and your engineer handles it because it feels faster than escalating. A migration that was scoped for a clean environment turns out to be anything but, and the team absorbs the extra work without anyone raising a flag.
Steve Psaradellis, an MSP owner who went through TopLeft's Agile Bootcamp, found that his projects were averaging 130% of budget before he made his work visible. That number is not unusual. What is unusual is finding out before the project closes.
The move from break-fix to managed services blurred the line between what is in the contract and what is just being a good partner. Clients expect fast responses. Technicians want to be helpful. And when work lives inside a PSA that requires 15 clicks to find a status update, nobody has the visibility to catch the drift until it is too late.
The requests do not feel like scope creep in the moment. They feel like good service. That is exactly what makes them dangerous.
The most effective scope creep prevention is not a policy document. It is visibility. When every piece of work is on a Kanban board that your whole team can see, out-of-scope requests cannot hide. There is no junkyard column where extra tasks quietly accumulate. There is no ambiguity about what is in flight, what is approved, and what is waiting on a change request.
Here is how to build that foundation:
Write a service catalog that spells out what is included, what is not, and what triggers a change request. Keep it plain enough that a technician can reference it in a client conversation without needing to call a manager.
Build a change control habit, not just a change control form. Every out-of-scope request gets logged in your PSA, reviewed for time and budget impact, and approved in writing before work begins. The habit matters more than the paperwork.
Teach your team a redirect phrase they will actually use. Something like "Let me log this as a change request so we can get it to you properly" lands better than no, protects the relationship, and creates a paper trail.
Break projects into smaller visible chunks. When work is broken down far enough using tools like Gantt charts, it becomes obvious the moment a new request falls outside the original scope. Vague phases hide creep. Specific tasks expose it.
Run a short retrospective after every project. Where did the boundary break down? Who caught it and who missed it? Recognizing the technicians who held the line builds the culture over time.
Steve's team went from projects finishing 30% late to finishing 30% early. That shift did not come from stricter contracts. It came from making work visible so problems surfaced before they became crises.
Chase Effler at Appalachian Network Services improved SLA adherence from 60% to 90% within six months using the same approach. Te'neyl Hagman-Simpson at Morgan Birgé reduced the ticket queue from 180 to under 100 while improving technician utilization from 30% to 60%.
These are not edge cases. They are what happens when an MSP stops guessing and starts seeing.
Scope creep is work that gets absorbed without review or approval. A real change request goes through a defined process with documented impact and client sign-off before work begins.
Frame it as protecting the quality and timeline they care about. "Let me capture this properly so we can deliver it right" is more effective than a flat no and it keeps the conversation professional.
Yes. Automated workflows inside your PSA can flag potential out-of-scope requests, route them to the right person for review, prompt client approval, and convert approved changes into billable tasks with a full audit trail.
James Davis and Wim Kerkhoff have covered this problem in detail on the TopLeft podcast. If you want to hear how other MSP owners have navigated scope control with real teams and real clients, these episodes are worth your time:
How to Finish Well on Projects
Episode discussion on project budgets and scope
Episode discussion on MSP project delivery
TopLeft connects directly to ConnectWise, Autotask, and HaloPSA to give your team a single pane of glass across every project and service ticket, so scope creep surfaces before it costs you.
Schedule a fit assessment to see how it works with your current stack.