Where SharePoint Stops Working

Every SharePoint rollout to a frontline workforce we've watched has the same shape.

Month one: it launches with a leadership video and a policy library. The internal comms team is proud. The IT team is relieved. HR is optimistic.

Month three: HR is chasing acknowledgements. The updated bullying and harassment policy needs to be signed off by everyone in the business, and only 30% have opened it. Reminders go out. Then more reminders. Then a spreadsheet.

Month six: someone commissions a report on "low adoption." The report almost always concludes the same three things. That people need more training. That the change management wasn't strong enough. That we'll do a better rollout next time.

Month nine: everyone quietly stops mentioning SharePoint. New announcements go out through Teams. The really important ones still go on paper, taped to the break-room wall.

We've watched this loop repeat enough times in aged care, retail, cleaning, hospitality and logistics that we think the standard diagnosis is wrong. It is not a training problem. It is not a change management problem. It is not even a rollout problem. It is a scope problem, and it started before the platform was ever chosen.

‍

Who SharePoint was actually built for

SharePoint was designed for a specific person. That person sits at a desk. They have a work laptop. They are on the corporate network. They have a company email address. Their manager sends them documents. Their calendar is on Outlook. When a policy changes, they read the email, click the link, and acknowledge on the screen in front of them.

For that person, SharePoint works. Fifteen years of enterprise IT investment has made it a serious platform for desk workers. It handles version control, permissions, integrations, document workflow and knowledge management better than most alternatives. If your job is at a keyboard, it earns its keep.

None of the description above fits most of the people that large employers in frontline industries actually spend their payroll on.

The other eighty per cent

Walk through the loading dock of a regional distribution centre. Walk down the hallway of an aged care residence at three in the afternoon. Walk into the back-of-house of a supermarket at the end of shift. Look at the people who do the actual work of the organisation.

They are on their feet. The phone in their pocket is their own. The network is public wi-fi, or their own mobile data, or nothing. Their email address, if they have one, is checked once a week from a shared desktop in the office nobody uses. English may not be their first language. Their break is five minutes long, and they are more likely to spend it on a message from their kid's school than on a corporate intranet.

This is who most compliance obligations, training requirements and policy communications need to reach. And this is who was never in scope when SharePoint was designed.

There is no version of "better change management" that closes that gap. It is a gap in the tool's original design.

Two workforces, two tools

The reframe worth having with your executive team, and the one worth putting in front of your CTO, is not "SharePoint has failed us." It is: we have two workforces, and we have been trying to serve them with one tool.

Desk workers get served well by the tools they already have. SharePoint, Teams, Outlook, the Microsoft stack broadly. That investment does not need to change. That group is looked after.

Frontline workers need a tool built for the phone in their pocket. That tool has different requirements. It has to open in under two seconds on a five-year-old Android on public wi-fi. It has to work in three languages. It has to make a mandatory acknowledgement a single tap. It has to send a message that a shift lead will actually see between shifts. It has to give HR a report that says "yes, everyone read the new fire safety policy" without a spreadsheet.

Both categories can be true at once. The mistake is asking one tool to do both.

What this looks like when it lands

The best rollouts we've been part of don't tear anything down. They don't replace SharePoint. They don't compete with it. They sit alongside it, and they are honest about which tool does which job.

For the desk-based teams, nothing changes. The intranet, the Teams channels, the document libraries, all keep working.

For the frontline, a new tool goes on their phone. It carries the things that need to reach them. Policy updates, mandatory training, shift-critical messages, forms, quick chats with their team lead. The success signal is boringly measurable. In the deployments we work on, we watch for 90% of frontline staff to open the app in the first week and 60% to still be opening it weekly six months later. If those numbers hit, HR gets its compliance evidence, and the internal champion who pushed for the change gets to be a hero rather than a cautionary tale.

None of that is a claim about SharePoint. It is a claim about what happens when you match the tool to the population.

The internal argument worth making

If you are the HR Director quietly wondering whether to have this conversation with your executive team, here is the shape we'd suggest.

Don't start with "SharePoint isn't working." That reads as blame, and it puts your IT team on the defensive from the first sentence. Start with "we have two workforces, and we have been trying to serve them with one tool." Then walk through the numbers you already have. Policy acknowledgement rates. Training completion for care workers versus office staff. How many of your frontline workers have opened Teams this month. The gap will do the argument for you.

The story stops being about a failed platform. It starts being about a mismatch between tool and audience. That is a story your CTO can back, your CEO can sponsor, and your board can approve without anyone having to admit a mistake.

Which is usually how the good decisions get made.

‍