Playbook · Team communication
How to Launch an Intranet That People Actually Use
An intranet launch succeeds when employees open the site on their own because it saves them time, not because a leader announced it. That outcome is decided mostly before the software is switched on: by a clear goal, a named owner, a trimmed set of content, a structure people can guess and a plan for switching off the old tools. This playbook walks through those steps in order, from goals to the first 90 days, and does not recommend any vendor.
Key takeaways
- Write down one or two business problems the intranet must solve, and name one owner who answers for them.
- Audit and cut existing content before moving anything: launching with less, accurate material beats launching with everything.
- Organize by task and topic rather than by department, so the structure survives reorganizations.
- Decide who may publish, who approves and how often content is reviewed before the platform is chosen.
- Treat adoption as a change-management job: people need to understand why, want to switch, know how and be reinforced afterwards.
What should the intranet be for, and who owns it?
Start with the problem, not the product. Most failed intranets were launched to "improve communication", a goal nobody can measure and nobody feels personally. Pick one or two concrete problems instead: new hires cannot find the leave policy, shift workers hear company news from rumors, managers answer the same HR question every week, or three teams keep three versions of the same procedure.
For each problem, write a single sentence that states what will be different after launch and how you will notice. That sentence becomes your success measure later and keeps scope arguments short.
Then name one owner. The owner is a person with time allocated, not a committee. In most organizations the role sits in internal communications or HR, with IT as the technical partner.
Gallup's Q12 engagement survey (2024 edition) includes the items "I know what is expected of me at work" and "I have the materials and equipment I need to do my work right". A well-run intranet is one of the ways an organization supplies both, and the owner is accountable for that outcome.
- Problem statement: one sentence per problem, written in the employee's words.
- Owner: one named person plus a deputy.
- Sponsor: an executive who will use it visibly and unblock decisions.
- Technical partner: someone from IT for identity, permissions and integrations.
- Success measure: one number per problem, chosen before launch.
Who is the audience, and what content do they need first?
Define audiences by what they do, not by their title. Office staff with a laptop, field staff with a shared tablet and shift workers with only a personal phone use an intranet in very different ways. List each group, the device they will use, how often they are at a screen and the three questions they ask most often.
Interview a handful of people from each group for twenty minutes. Ask what they looked for last week, where they looked first and what they gave up on. Support tickets, HR inbox topics and the search history of your current file share are cheaper evidence and often more honest.
Frontline groups deserve explicit attention because they are the most commonly forgotten. If they cannot log in at work, the intranet is not an intranet for them. Settle access (company device, kiosk, personal phone, sign-in method) before you write a line of content.
How do you audit content before moving it?
Migrate less than you think you need. An old file share or wiki usually holds years of outdated, duplicated and abandoned documents. Moving all of it recreates the problem on a new platform.
Export a list of existing pages and documents with owner, last modified date and, if available, view counts. Sort each item into one of four decisions and record it in a spreadsheet that the whole project team can see.
- Keep: accurate, used and owned. Move it and assign a review date.
- Rewrite: still needed but outdated or unclear. Assign a named author and a deadline.
- Merge: several documents answer one question. Combine them into one page.
- Retire: unused, wrong or ownerless. Archive it outside the intranet and do not migrate it.
Content with no owner is the clearest signal. If nobody will put their name on a page, nobody will keep it current, and it should stay behind. Expect to retire a large share of what you find.
How should you structure the navigation?
Organize by task and topic, not by department. Nielsen Norman Group's analysis of 77 intranet information architectures across 13 countries found that task-based structures better withstood organizational change, and that by 2014 86% of the new intranets in its sample were task-based or mostly so. Department names change in a reorganization; the question "how do I book leave?" does not.
The same research reports an average of 7.6 top-level categories (median 7) and notes that very broad menus with more than 12 categories had disappeared from its sample. Aim for a short top level with distinct labels. Avoid catch-all headings such as "For Employees", jargon and internal product names, and avoid two labels that sound alike.
Test the structure before you build it. Card sorting shows how employees group your content; tree testing shows whether they can find specific items in a draft menu. Both can be run on paper or with a free spreadsheet and ten participants, and both surface ambiguous labels cheaply.
Add breadcrumbs and a visible current-section marker, because many visitors arrive from a search result or an emailed link and land deep in the site.
Who may publish, and how do you keep content current?
Governance is a short list of rules, written down before launch. Without it, either everything goes through one bottleneck editor or anyone posts anything and the site fills with noise. Decide three things: who may publish where, who approves what, and how often each page is reviewed.
A workable pattern is a small group of trained publishers per area (HR, IT, finance, each location), a central editor who sets style and handles company-wide news, and a review date on every page. When the review date passes, the page owner gets a reminder; if nobody confirms it, the page is archived rather than left to mislead.
- Publishers: named people per area, trained in a one-hour session.
- Approvers: required only for policy, legal and company-wide news; not for routine updates.
- Review cycle: every page carries an owner and a next-review date.
- Style guide: one page covering titles, tone, length and how to write for a phone.
- Retention: a rule for what is archived and when.
- Escalation: a way for any employee to report an error and a promise of a reply time.
Governance also covers access: who sees what, how leavers are removed and which content is restricted. Involve IT and, where employee data is involved, your privacy officer early.
How do you pick a platform without starting from a vendor list?
Choose the platform last, against requirements you already wrote. By this point you know your audiences, devices, content volume, structure and governance, so the shortlist is judged against facts rather than demonstrations. Intranets come as standalone products, as modules of a collaboration suite and as parts of employee communication apps; the right type depends on your answers, and this guide does not pick one.
Turn your decisions into a scorecard. Weight the criteria that matter to your goals, and ask every vendor to run the same scripted scenarios: a publisher posts a policy update, a shift worker finds it on a phone, an editor retires an outdated page, an administrator removes a leaver.
- Access: sign-in method, mobile reach and options for staff without company email.
- Search: quality of results on your own content, tested with your real questions.
- Authoring: how easily a non-technical publisher produces a clean page.
- Permissions: audience targeting and restricted areas.
- Analytics: what you can measure without a custom project.
- Data exit: export formats and what leaves with you if you switch.
- Total cost: licenses, implementation, migration, training and admin time, not just the headline price.
For a deeper evaluation framework, see our guide to choosing HR software and our overview of employee communication apps. If your main need is reference material rather than news, read how to build an internal knowledge base first.
Why run a pilot, and what should it test?
A pilot finds the problems that a project team cannot see. Pick one or two groups that differ from each other, for example a head-office team and a site with shift workers, and give them the intranet with real content for a few weeks before anyone else.
Define what the pilot must prove: people can find the ten most common answers, sign-in works on the devices they use, publishers can post without help, and the structure makes sense. Watch people use the site instead of asking whether they like it. Where they hesitate, the label or layout is probably wrong.
Fix what you find, then decide go or no-go against the criteria you set at the start. A pilot that cannot end in a no-go is a rehearsal, not a test.
How do you plan the launch communication?
Launch communication has to answer one question: what is in it for me, this week? Prosci's ADKAR model describes individual change in five stages: awareness of why the change is needed, desire to take part, knowledge of how to change, ability to do it in practice and reinforcement to make it stick. Use those stages as a checklist for your plan. An announcement email covers awareness at best.
Give every audience a reason in its own terms: managers get fewer repeat questions, new joiners get one place for their first week, field staff get news without waiting for a team briefing. Support desire by letting managers and a group of early users speak first, because colleagues trust peers more than a corporate message. Support knowledge and ability with a two-minute walkthrough, a short guide and a visible way to ask for help.
Make the intranet the first place something happens. Publish a piece of content people want on day one, such as the leave booking steps, the pay calendar or the shift swap form, and link to it from every launch message. For channel mix and cadence, our team communication plan guide covers how to avoid adding another noisy channel.
What should you measure in the first 90 days?
Measure whether the problems you named are shrinking, not only whether pages are viewed. Page views show curiosity; the success measures you wrote at the start show value. Set a baseline before launch so you can compare, and review the numbers at fixed points rather than whenever someone asks.
Gallup's Q12 item "I know what is expected of me at work" is a reminder that clarity is the outcome. Use a short pulse question of your own after 30 and 90 days, such as "I can find what I need to do my job", and track the answer by audience group.
- Reach: share of employees who signed in at least once, and at least weekly, by audience group.
- Findability: search terms with no result or no click, and the pages searched for most.
- Task success: a small test where new users find five common answers, repeated at 30 and 90 days.
- Content health: share of pages with a named owner and a review date in the future.
- Deflection: change in repeat questions to HR and IT, taken from ticket categories you already track.
- Publisher activity: number of publishers who posted something in the last 30 days.
- Employee pulse: the one-question survey above.
Hold a review at day 30 and day 90. Fix labels and search first, retire what nobody opens and coach publishers whose pages are not being read.
How do you retire the old tools?
An intranet that coexists with the old file share and the old mailing list will lose. People use whichever route is easier and already habitual. Set dates for each old tool, announce them at launch and keep to them.
A common sequence is to freeze new content in the old place first, add a redirect or banner pointing to the new page, move to read-only and finally archive. Keep an export of the old system for legal and audit needs, stored outside the intranet. Reinforcement, the last ADKAR stage, means leaders use the new site themselves and stop answering questions that the intranet already answers: reply with the link.
What mistakes should you avoid?
Most intranet failures are organizational, not technical. The patterns below recur and each has a plain fix.
- Launching with everything: migrate only what the audit approved.
- No owner after go-live: budget the owner's time for at least the first year.
- Structure that mirrors the org chart: it breaks at the next reorganization.
- Forgetting frontline staff: settle access before content.
- Choosing software first: requirements and governance come before demos.
- One big announcement: plan reinforcement over weeks, not a single email.
- Ignoring search: check results for real questions every month.
- Leaving old tools running: set shutdown dates and keep them.
Frequently asked questions
How long does it take to launch an intranet?
It depends on size and scope, so treat any fixed figure with caution. The work divides into goals and audit, structure, governance, platform selection, pilot and launch. Platform selection and content cleanup usually take the longest.
A smaller organization with a tight scope can work in stages, launching a core set of pages first and adding sections after the first review.
Who should own the intranet?
One named person should own it, usually in internal communications or HR, with IT as the technical partner and an executive sponsor. A committee can advise, but it should not be the owner. The owner needs protected time, the authority to retire content and a clear success measure agreed with the sponsor before launch.
How do we reach employees who have no company email?
Decide access before content. Options include personal phones with a simple sign-in, shared kiosks or tablets at the site, and short briefings from team leads that point to the same pages. Test sign-in on the devices these employees actually use during the pilot, because that is where most access problems appear.
What is the difference between an intranet and a knowledge base?
An intranet is the broader entry point: news, people, tools and links to everything employees need. A knowledge base is the part focused on how-to and reference articles. Many organizations run the knowledge base inside the intranet.
If your main problem is repeated questions, start with the knowledge base and grow the intranet around it.
How many people should we pilot with?
Choose by variety rather than headcount. Two or three groups that differ in role, location and device give more useful findings than a large group of similar people. Make sure at least one group includes staff who are not at a desk, and include a few publishers so authoring is tested too.
What if adoption is low after launch?
Look at the cause before adding announcements. Check whether people can sign in, whether search returns useful results and whether the content they need exists. Then confirm that the old tools are really switched off, and ask managers to point to the intranet instead of answering directly.
Low reach in one group usually means an access problem.