An intranet succeeds or fails in its first fortnight. The launches that work seed real content before anyone is invited, pilot at one site, brief managers ahead of their teams, and move something people need into the app so there is a reason to open it twice.
Most intranet projects are treated as a technology rollout. They are not. The software is the easy part — the hard part is giving several hundred people a reason to change where they look for information.
Why intranet launches fail
Four patterns, and they recur across almost every failed rollout.
| Failure | What it looks like | Why it happens |
|---|---|---|
| The empty room | Launch day, three posts, no activity | Nobody wants to be first. An empty feed signals nobody uses this |
| No reason to return | Downloads high, week-two usage near zero | Nothing in the app that people actually need |
| Managers found out with everyone else | Team asks a question, manager cannot answer | No advance briefing, so managers cannot advocate |
| Parallel channels | Same info on the app, email and noticeboard | People default to whichever is easiest, which is not the app |
Notice that none of these are software problems. They are all sequencing and content problems, and all four are avoidable.
The eight-week launch sequence
Launching to an empty feed. If the first thing a new user sees is three posts and no activity, they conclude nobody uses this and they are right — because they have just decided not to either. Seed at least twenty genuine posts and ask managers to comment before anyone else is invited in.
Choosing the pilot site
The instinct is to pilot at the biggest site or the most problematic one. Both are wrong.
Pick a site with a manager who will actually use it. The pilot is not testing the software — the vendor already knows it works. It is testing your content, your audience structure and your rollout approach, and you need a manager who will tell you honestly what is not working.
Pick a site of representative size. A twelve-person venue teaches you more about the median experience than a hundred-person distribution centre.
Run it for two full weeks. One week only tells you about the novelty period. The second week tells you whether it holds.
What to put in before launch
The single strongest predictor of adoption is whether the app contains something people need. Not something they might find interesting — something they would otherwise have to ask a manager for.
Must be there on day one
- The roster link or roster itself
- The policies people most often ask about
- Pay and leave process information
- Who to contact for what
- At least 20 genuine news posts
Strongly recommended
- Employee directory populated with photos
- Onboarding checklists for new starters
- Site-specific procedures
- Recognition seeded by managers
- Anything currently on a staff room noticeboard
Briefing managers
Managers are the difference between a rollout and an announcement. A team whose manager uses the app will use the app; a team whose manager shrugs will not.
Brief them at least a week ahead, in person or on a call rather than by email, and cover three things: what it is for, what changes for them specifically, and what to say when someone asks why we are doing this. Give them the answer to the last one explicitly — most managers will otherwise improvise something lukewarm.
Our frontline manager toolkit covers the broader question of what managers need from the organisation to lead well.
The switch-off step
This is the step organisations most often defer, and deferring it is why adoption plateaus at 40%.
If the roster is on the app and emailed and printed in the staff room, people will use whichever requires least effort. That is almost never the app, because the app requires a behaviour change and the noticeboard does not.
Pick two or three things and make the app the only place they exist. The roster is the strongest candidate in most frontline businesses — it is the single thing everyone checks.
Move the roster into the app in week eight and adoption typically resolves itself within a fortnight. It is the one piece of information every employee needs every week, and it converts an optional app into a necessary one without a single reminder email.
What to measure in the first 90 days
| Metric | Day 30 | Day 90 | What it tells you |
|---|---|---|---|
| Activation (% signed in) | Above 70% | Above 90% | Whether access is genuinely frictionless |
| Daily active users | Above 35% | Above 60% | Whether there is a reason to return |
| Read rate per post | Above 50% | Above 70% | Whether communication is landing |
| DAU variance between sites | — | Under 25 points | Whether it is consistent or manager-dependent |
Activation is a setup metric — a low number means access is too hard, not that people are uninterested. Daily active users is the real measure, and we cover it in depth in intranet adoption.
Frontline-specific considerations
Sign-in must take under a minute. A casual on their first shift will not persist through a password reset. Code-based sign-in with no company email address is the practical requirement — more on this in reaching employees without company email.
Launch outside peak season. Rolling out to a hospitality group in December or a retailer in November guarantees failure. Nobody has capacity.
Account for shift patterns. A launch briefing at 10am on a Tuesday reaches the day shift. Run it several times or record it.
Expect the personal device question. Someone will ask why they should install a work app on their own phone. The honest answer — it replaces the WhatsApp group, holds the roster, and does not share your number — usually settles it.
Common mistakes
Launching everywhere at once. No opportunity to learn, and every problem hits every site simultaneously.
Treating it as an IT project. The blockers are content and behaviour, not technology.
No content owner. An intranet with no one responsible for keeping it current is a document graveyard within six months. See what to put on your intranet.
Measuring downloads. Downloads tell you about launch communication. Daily active users tell you whether it worked.
Never switching off the alternatives. The most common reason adoption stalls.
Frequently asked questions
Around eight weeks from start to full rollout for most organisations — two weeks to connect and configure, one to seed content, one to brief managers, two for a pilot, and two for waved rollout. The technical setup is usually about two weeks of that.
The roster or roster link, the policies people most often ask about, pay and leave process information, a contact directory, and at least twenty genuine news posts. An empty feed is the most common cause of failed adoption.
One with an engaged manager and a representative headcount — not the largest site and not the most problematic. The pilot tests your content and rollout approach, so you need a manager who will tell you honestly what is not working.
Put something in it they genuinely need — usually the roster — and then remove the alternatives. Adoption follows necessity rather than enthusiasm, and parallel channels are the most common reason it plateaus.
No. Roll out in waves of two or three sites so each wave benefits from what the last one surfaced, and so a problem does not hit every location simultaneously.
Decisive. A team whose manager uses the app will use it; a team whose manager shrugs will not. Brief every manager at least a week before their team, and give them a specific answer to "why are we doing this?"
Activation (percentage signed in) at day 30, daily active users at day 90, read rate per post, and the variance in adoption between your strongest and weakest site. Downloads alone tell you very little.
During your peak trading period. A hospitality group launching in December or a retailer in November will fail, because nobody has capacity to change how they work.
Launch an intranet your team will actually open
Prosper connects to your payroll system, syncs every employee with their role and site, and works on a personal phone without a company email address — so activation is not the thing that stalls your rollout.