How to Get Your Team to Actually Use Your New Intranet (Without the Eye-Rolls)

Here's a truth that doesn't get said enough in conversations about intranets: the technology is the easy part.

I've seen beautifully built intranets — well-designed, fully featured, technically solid — quietly gather dust because nobody planned for adoption. Staff log in once, click around, and drift back to their old habits. The intranet becomes a monument to good intentions, and the business owner wonders why they spent all that money on something nobody uses.

Adoption isn't an accident. It isn't guaranteed by a good interface. It requires deliberate planning, the right launch strategy, and — honestly — a bit of organisational change management. None of that has to be complicated, but it does have to be intentional.

Here's what actually works.

Start With Staff, Not Specs

The most common mistake I see is building an intranet in isolation — the owner or manager decides what to include, the builder builds it, and then it gets "launched" to staff who had no input whatsoever. Those staff often feel like the intranet was done to them, not for them.

Before you finalise what goes in your intranet, talk to your team. Not a formal survey — just conversations. Ask them: what takes too long? What information do you spend time hunting for? What processes feel broken? What would make your day easier?

You'll get two things from this. First, genuinely useful input that improves the product — staff know their own pain points better than any manager does. Second, and more importantly, you'll get buy-in. People support things they helped shape. When the intranet launches, they'll see their own suggestions in it and feel ownership over it.

Even asking two or three representative staff members from different roles is enough to make a real difference. It doesn't have to be a big process.

Identify Your Champions Before Launch

In every workplace, there are people others turn to when they need help with something. They're not necessarily the most senior — often they're not — but they're trusted, helpful, and tech-comfortable. These are your champions.

Find two or three of these people before your intranet launches. Give them early access. Walk them through everything. Ask for their feedback (and actually incorporate it where possible). Make them feel like insiders.

When the intranet goes live, these champions become your first-line support — colleagues who can show people around, answer questions, and model the right behaviour. Leadership telling staff to use a new system carries less weight than a peer saying "no, honestly, it's actually really useful for X."

Champions also give you early warning if something isn't working. If they're struggling with a part of the intranet, everyone is. Fix it before it becomes a wider problem.

Make It the Only Place to Find Things

This is the single most important structural decision you'll make about your intranet: it must become the only place to find certain things, not just another place.

If your leave request form is on the intranet but staff can still email their manager to request leave, most of them will email. If the latest version of the employment agreement is in the intranet document library but also sitting in a shared folder, people will use whichever they find first — and you'll end up with the version problem you were trying to solve.

When you launch, you need to actively retire the old systems in parallel. Take the leave form off the shared drive. Stop accepting email leave requests. Tell HR not to send documents directly — they go in the library, and people get the link. Archive the old shared folder so people can't fall back on it.

This sounds harsh, but it's actually kind. Every time staff can bypass the intranet, they will — not out of malice, just habit and convenience. The only way to form a new habit is to make the new path the easy path.

Plan a Launch That Creates a Moment

A quiet rollout — "we've built something, here's the link, off you go" — rarely works. Staff need a reason to pay attention. They need to understand what the intranet is, why it's there, and most importantly, what it does for them.

A good launch doesn't have to be a big production. For a small business, a 30-minute all-hands (in person or via video call) where you walk through the intranet live is enough. Show people where the document library is. Pull up the staff directory. Submit a fake leave request and show how it works. Make it concrete.

Frame the launch around the problems it solves, not the features it has. "You told me you were sick of hunting for the latest version of the H&S induction form — it's right here now, always up to date." That's more compelling than "we now have a document library with version control."

For larger teams, consider a phased rollout — department by department — so each group gets proper attention rather than a mass email.

Deliver Quick Wins in Week One

The first time someone uses the intranet and thinks "oh, that was actually easier than what I used to do" — that's the moment adoption begins. Get people to that moment as fast as possible.

Think about what your staff do every week that currently involves friction. Finding a form. Looking up a phone number. Submitting a leave request. If any of those are genuinely faster and easier via the intranet from day one, the value is immediately obvious.

One tactic that works well: in the first week, put an announcement on the intranet that's genuinely useful and time-sensitive. A roster change, a reminder about something due, news about the business. Give people a reason to log in immediately — and when they do, they'll poke around and discover the rest.

What Kills Adoption — Be Honest About These

I want to spend some time on this because I see the same failure modes repeatedly, and most of them are avoidable at the design stage.

Too Many Clicks

If it takes four clicks to find the form someone needs, they'll stop bothering. Every extra click is a drop in motivation. The intranet homepage should be designed around the things staff need most often — the leave form, the document library, recent announcements — not around what looks impressive in a demo.

Test the navigation with real users before launch. Ask someone to find a specific document and watch what they do. If they look confused at any point, something needs to change.

A Difficult Login Experience

This is more important than people think. If staff have to remember a separate username and password for the intranet, a meaningful percentage won't bother — especially people who already struggle with password management. Single sign-on (SSO) — logging in with the same credentials as their Google Workspace or Microsoft 365 account — removes this friction entirely.

The intranet should also work properly on mobile. A lot of staff — especially in trades, hospitality, retail, and field-based roles — will try to access it on their phone. If it looks broken on mobile, you'll lose those people immediately.

Information That Goes Stale

Nothing kills trust in an intranet faster than finding outdated information. If someone looks up a policy and it references a process that changed six months ago, they'll stop trusting the intranet as a source of truth. And once that trust is gone, it's very hard to get back.

Before launch, build a maintenance plan. Every section should have an owner. Documents should have review dates. There should be a regular (quarterly, at minimum) sweep to check that everything is current.

Building the Wrong Things

An intranet full of modules that nobody actually needed is just clutter. Clutter is demoralising and makes it harder to find the things that do matter. Build what staff asked for, not what seemed like a good idea in a planning meeting.

No Executive Modelling

If senior leaders in the business don't use the intranet, staff will notice. If the owner is still sending documents by email while expecting staff to use the document library, the message is clear — this is optional. Leadership needs to model the behaviour they want to see. This means posting announcements through the intranet, using the leave system themselves (if relevant), and visibly referencing the intranet in conversations.

After Launch: Keep the Momentum Going

Adoption isn't a one-time event. It's a curve. Most businesses see strong initial uptake, a slight dip a few weeks later as novelty wears off, then a gradual increase as habits form and the intranet proves its value repeatedly.

A few things that help sustain momentum:

Regular announcements. If the noticeboard is updated at least weekly, staff have a reason to check in. A quiet intranet feels abandoned. An active one feels like the heartbeat of the business.

Act on feedback. If staff flag that something doesn't work the way they expected, fix it and tell them you fixed it. This demonstrates that the intranet is maintained and that their input matters.

Add content progressively. The knowledge base shouldn't be empty on day one. But it also shouldn't be overwhelming. Add genuinely useful guides as they're needed — the first time someone asks "how do I do X," write a guide and put it in the knowledge base. Over time, it fills up organically.

Celebrate usage milestones. "We just processed our 100th leave request through the system — no more email back-and-forth!" Sounds minor, but recognising that the intranet is working reinforces the habit.

The Bottom Line

The best intranet in the world fails if nobody uses it. The average intranet succeeds if adoption is taken seriously. Don't put all your energy into features and leave nothing for rollout and change management.

The businesses I've seen get the best results from their intranets are the ones that talked to their staff first, made the intranet the only path for key processes, and kept showing up to maintain and improve it after launch. None of that requires a big budget or a change management consultant — it just requires intention.

If you're in the planning stages of an intranet and want to build an adoption strategy in from the start, let's have a conversation. I've helped a number of NZ businesses get this right, and I'm happy to share what's worked.