I didn’t set out to work with SharePoint. At the time, I’d been brought in as an Exchange Subject Matter Expert — a contractor, part of a newly formed second-line team intended to stabilise a service that was already struggling.

Before I arrived, the situation had started to unravel. A large managed services contract had been won, along with responsibility for an onsite infrastructure team and a contact centre inherited — at least in part — through TUPE. A lot of the original staff chose not to come across. Others moved roles or left entirely. What remained was a contact centre that could log tickets, but not resolve them, and an onsite team that was drowning under the volume being passed through.

  • People were leaving.
  • SLAs and KPIs were being missed.
  • Financial penalties were being paid every month.

By the time I joined, the fix in motion was to build a remote second-line team to absorb some of that pressure. The idea was straightforward enough.

  • Exchange tickets would come to me.
  • Everything else would be routed appropriately across the team.

In practice, it didn’t work like that. The contact centre didn’t always recognise what an Exchange issue looked like, so tickets landed in the wrong queues. The system itself was too rigid to automate meaningful re-routing, so the only real option was to fix the problem at source. So we went to them.

I took the second-line engineers down to the contact centre floor for a week, and we worked alongside them ticket by ticket. Not taking over — guiding. Helping them recognise patterns, understand tagging, and decide where something should go. It wasn’t a one-off fix. We had to repeat it. But over time, it worked.

  • Better ticket classification led to better routing.
  • Better routing led to improved SLA performance.
  • Fewer angry customers meant less pressure on the contact centre.
  • Less pressure meant less churn.

And slowly, the whole system started to stabilise.

Somewhere in the middle of that, SharePoint started appearing.

At that point, I’d barely touched it. The tickets, though, looked familiar. Patterns emerged quickly — most of them tied to permissions. So I started digging. The implementation wasn’t especially complex. Underneath it all, it was largely driven by Active Directory groups. That was the key. Once you understood that, most of the issues stopped being mysterious. Permissions would break because they were being set manually in SharePoint and then overwritten by AD synchronisation. Users would lose access seemingly at random, but it wasn’t random at all. It was just conflicting models.

On the client side, a small number of power users had effectively been given free rein over the platform. They could create sites, assign owners, manage access — but without a clear understanding of how AD groups interacted with SharePoint permissions. So the problems kept repeating. Fixing it wasn’t about rebuilding the platform. It was about guiding the people using it.

Helping them understand why things broke, and how to avoid it happening again. Before long, I was handling most of the SharePoint tickets. Not because I was a SharePoint expert — but because I understood the system it depended on.

That pattern followed me.

When the same organisation decided to build an internal knowledge base to improve first-time fix rates, it landed on SharePoint. By then, our own internal IT team had adopted it as an intranet platform as well. And I was the obvious person to take it on. This time, we did things more deliberately.

  • Permissions were structured properly from the start.
  • We avoided the free-for-all that caused so many issues on the client side.
  • It wasn’t perfect, but it was controlled.

The goal wasn’t elegance. It was usefulness. Something that helped engineers resolve issues faster, reduced repeat tickets, and improved the metrics that actually mattered.

SharePoint War Stories

Over the years, I ended up building and supporting several SharePoint implementations. Never as my primary role. Always because I’d seen enough go wrong to know how to avoid the obvious pitfalls. That was usually enough.

More recently, I worked alongside a dedicated SharePoint administrator. It became very clear, very quickly, that there was a lot more depth to the platform than I’d ever needed to touch.

  • Taxonomies.
  • Content types.
  • Governance models that went far beyond what I’d worked with.

It was a useful reminder. What I’d built previously wasn’t comprehensive expertise — it was practical understanding, shaped by real problems and constrained environments. Enough to be useful. Not enough to be complete.

Looking back, this wasn’t really about SharePoint.

It was about stepping into gaps. Understanding systems by following the problems through them. Realising that sometimes the issue isn’t the technology, but how people are using it. And recognising that improving a service often means improving the flow around it, not just the tools inside it. SharePoint just happened to be where that lesson landed first.

Tags: