Every MSP website in the country says proactive. Go read five of your competitors right now. Proactive monitoring, proactive maintenance, a proactive partner. The word appears so often it has stopped carrying information, which means a prospect comparing three providers has no way to tell them apart except on price, and you already know how that comparison ends for you.
This month we are replacing the services-flavored version of that page at Boston Managed IT with one that says what actually runs. What happens every week, what happens every month, what happens every quarter, and what the first ninety days of a takeover look like phase by phase. It is a much better page for a prospect. It is a worse page for us on the day we miss something, because it is now written down where anyone can read it.
The marketing case for doing this is easy and I am going to spend very little time on it. The operational consequences took me longer to work out and they are the reason I would recommend it.
What went on the page
The weekly block is patching, backup verification, alert triage, and ticket review. Patching includes the third-party software that actually gets exploited rather than just the operating system. Backup verification means last night's job completed on every machine that is supposed to be covered, not that backup is configured. Ticket review means someone looks at the week's tickets for patterns, because four calls about one application is a project nobody has named yet.
The monthly block is a report the client can actually read, an account review, and a restore test. The account review is who joined, who left, who changed roles. The restore test is the one that matters: we pick something, a file or a mailbox or a server, and we restore it.
The quarterly block is a business conversation rather than a ticket conversation, a revised roadmap with rough timing and rough cost, and a risk review.
Then four onboarding phases with day ranges on them. Discovery in days one to fourteen. Stabilize in fifteen to forty five. Document in thirty to sixty, deliberately overlapping stabilize, because the act of fixing something is when you learn how it is put together. Plan in sixty to ninety, ending in a roadmap conversation with actual numbers.
None of that is clever. You probably do most of it. The question is whether you would put the day ranges in public.
What a published cadence actually costs
I went through the page line by line and asked whether I would defend each item to a client holding a printout of it. What that exercise turns up is that an item only survives a real month if somebody owns it by name, and "the team" is not a name. It needs a recurring calendar block treated like a client appointment. And it needs to produce something you can point at afterward, because an item with no artifact quietly turns into an item that did not happen, and you find that out when a client asks rather than when it stops happening.
The restore test is the clearest example. Saying you verify backups is cheap, and most of us genuinely do check that jobs completed. Saying in public that you restore something every month is a different commitment, because it consumes real technician time on a recurring schedule for a task that produces no visible client value in the month where nothing goes wrong. That work is the first thing to get eaten when the week goes sideways. Publishing it is a way of making it harder to eat.
Same with the weekly ticket review. Pattern analysis across a client's week is genuinely useful and it is completely invisible. Nobody calls to thank you for noticing that four tickets were one problem. It gets dropped constantly. Once it is on the website, dropping it is a different kind of decision.
That is most of the internal value. Publishing the cadence moves the argument about whether you can afford to do this work from a post-incident review, where it is too late and everyone is defensive, into a staffing conversation you have before the page goes live.
Three decisions that were not obvious
The first was whether to put day ranges on the onboarding phases. Takeovers vary enormously and a bad one can blow through ninety days for reasons that have nothing to do with you. The ranges went in anyway, because vague onboarding language is exactly what makes a prospect afraid of switching, and removing that fear is the whole job of the page. What makes it survivable is that the phases describe what we do rather than promise a completion date, and two of them overlap on purpose.
The second was naming the seat range. The page says we run between five and one hundred seats per client, with most around twenty five. That tells a two hundred seat prospect not to call, which is the intended effect. The cadence is only honest at that size, and a page that promises it to everybody breaks on the first client too big for it.
The third was a section listing what we will not do. Four items, including that we will not quote managed services for an environment we have not looked at, and that a client's documentation goes with them if they leave. That section is the only part of the page a competitor cannot copy in an afternoon, because copying it means operating that way.
The number we took off the page
We have a response time figure that has been on the homepage for a while. When we rewrote the page, my first instinct was to carry it across, since it was already published and reprinting it is not a new claim.
We ran the numbers first. What went back on the page: 76 percent of email requests answered in under 30 minutes, email only. We field calls through a voicemail relay that does not log callback times, so phone response is genuinely unmeasured. The page says so.
The old claim was fifteen minutes framed as an average. A single average collapses channel, outliers, and method into one number, and it costs you the entire page when a prospect's IT-literate board member asks how you measure it. A true number you can produce a report for is worth more than a round one you are quietly hoping nobody audits.
If you are going to publish a cadence, that is the discipline it demands. Everything on the page is either something you can evidence or something you should take off.
Where I think this can go wrong
The failure I would bet on is technicians finding out about the published cadence by reading the website. If delivery has not agreed to every line before it goes live, marketing has written somebody else's job description for them, and the resentment that follows is completely earned. The order matters more than the content.
Second, sales can turn the page into a checklist they read aloud on calls. That converts a credibility document into a script, and a script is the thing prospects were tuning out in the first place.
Third, the page goes stale. A process page is a promise with a date on it even when the date is not printed. Change how you work without changing the page and you have produced evidence against yourself.
For anyone who has published something like this already: did it change how delivery actually ran, or did it end up as marketing that operations quietly routed around? The second outcome is the one I would rather hear about, since it is the one I still have time to prevent.