Administration, governance, monitoring and ongoing development for your SharePoint environment, including the custom code most support providers will not touch. Whether we built it or somebody else did.
SharePoint rarely fails dramatically. It degrades. And it usually becomes urgent at the moment somebody realises nobody is actually looking after it.
An intranet, a portal or a business application built two or three years ago by an agency you no longer work with, or a developer who has since left. It still works, mostly. Nobody internally can change it, nobody knows what it depends on, and there is no documentation. Every request becomes a risk assessment.
The platform went live, the project team dispersed, and nothing has been maintained since. Microsoft has shipped dozens of platform changes in the meantime. Components are behaving oddly, a workflow stopped without anyone noticing, and the content has not been reviewed in a year.
Someone internally became the SharePoint person, usually by accident. They are now a single point of failure for something the business depends on, and they cannot take a holiday without a contingency conversation. This is a risk that only becomes visible when they resign.
Hundreds of sites, permissions granted ad hoc over years, orphaned content owned by people who have left, and no audit anyone can produce on request. Individually harmless; collectively a governance and security exposure.
The project delivered, the platform is live, and there is no plan for running it. The most common cause of a successful SharePoint project failing in its second year is that nobody was made responsible for it in its first.
An intranet, a portal or a business application built two or three years ago by an agency you no longer work with, or a developer who has since left. It still works, mostly. Nobody internally can change it, nobody knows what it depends on, and there is no documentation. Every request becomes a risk assessment.
The platform went live, the project team dispersed, and nothing has been maintained since. Microsoft has shipped dozens of platform changes in the meantime. Components are behaving oddly, a workflow stopped without anyone noticing, and the content has not been reviewed in a year.
Someone internally became the SharePoint person, usually by accident. They are now a single point of failure for something the business depends on, and they cannot take a holiday without a contingency conversation. This is a risk that only becomes visible when they resign.
Hundreds of sites, permissions granted ad hoc over years, orphaned content owned by people who have left, and no audit anyone can produce on request. Individually harmless; collectively a governance and security exposure.
The project delivered, the platform is live, and there is no plan for running it. The most common cause of a successful SharePoint project failing in its second year is that nobody was made responsible for it in its first.
Day-to-day running of the environment and a route for your people to get help. Site provisioning against agreed standards, permission and access changes, storage management, licence assignment, and a ticket channel your users can actually use, through email, a portal or Teams, whichever fits how your organisation works. Requests are logged, tracked and reported rather than handled informally, so you can see what your people are actually asking for and where the recurring friction is.
Keeping the environment defensible as it grows. Permission audits with a report you can hand to an auditor, retention policy application and review, external sharing controls, naming and provisioning standards enforced rather than documented and ignored, and identification of orphaned sites and unowned content. For regulated organisations we align this to your existing framework rather than imposing a generic one.
Watching the environment so problems surface before your users report them. Health monitoring, storage and usage trend tracking and, the part that distinguishes this from a standard support contract, testing custom components against Microsoft's release roadmap before changes reach your tenant. When a platform update is going to affect something you rely on, you should hear it from us rather than from a user.
Your platform will need to change, because your business does. Every agreement includes development capacity for new modules, workflow changes, form updates and improvements to what already exists, delivered by the same engineers who maintain it, not handed to a separate vendor with no context. This is what turns a support contract into something that keeps adding value rather than merely holding a line.
They administer the tenant competently, run a helpdesk, and apply governance policy. That is genuine work and much of the time it is enough. It stops being enough at a predictable moment: when something custom breaks.
We handle all four, because the people supporting your environment are the same engineers who build these solutions for a living. There is no escalation to a different company, no second contract, and no gap where your problem sits while two suppliers agree whose it is.
That is the reason to choose us over a cheaper helpdesk. If your environment is entirely out of the box and always will be, a helpdesk may genuinely be the better-value option, and we will say so.
If you are considering handing over a platform nobody can currently explain, the question is not what we will do once we are running it. It is how we get to the point of being able to run it at all.
We inventory what exists (sites, customisations, integrations, workflows, permissions) and identify what is undocumented, what is at risk, and what depends on something that has been deprecated. You get this as a written report whether or not you proceed.
We produce the documentation that should already exist: architecture, custom components, dependencies, deployment process and known issues. In most takeovers this is the single most valuable early deliverable, because it converts undocumented risk into something manageable.
Where there is still someone who knows the environment (an internal person, a departing developer, the previous supplier), we get what we can from them while the opportunity exists. Where there is not, we work it out from the code.
A defined period of addressing the issues the assessment surfaced, before steady-state support begins. Trying to run an environment you have not first stabilised sets a support agreement up to fail in its first quarter.
Regular support, monitoring, governance and enhancement under the agreed tier, with scheduled service reviews.
A provider who makes themselves hard to leave is managing your dependency, not your platform.
A support agreement has to be justifiable internally at renewal. That means evidence, not assurances.
That last item is the one clients tell us they value most, and the one almost no support provider produces.
Platforms our engineers designed and built, the same people who would be supporting yours.
What teams ask us before handing over an environment.
Before committing to any agreement, find out what you actually have. We will assess your environment (what exists, what is undocumented, what is at risk, what needs attention first) and give you a written report.
It is useful whether or not you go on to work with us. If your environment turns out to be in better shape than you feared, we will tell you that too.
Written report, whether or not you proceed.
