"What's the wifi password in the meeting room?" "How do I book leave?" "Do we give refunds after 30 days?" "Who approves invoices when Dana is away?"
Every small business has a set of questions like these, asked over and over, always answered by the same two or three people. Each one costs only a minute or two, but they land as interruptions, and they always land on your most experienced people. Twenty interruptions a week is a real chunk of your best person's attention, spent retyping answers the business already has.
An internal FAQ fixes this, but only if people actually use it. Plenty of teams have written one, shared it once, and watched the questions keep coming. This guide covers how to write an internal FAQ that becomes the place people check first: which questions to include, how to write answers people trust, and how to keep it from going stale.
What a company FAQ is for
An internal FAQ is a single document that answers your team's recurring questions in plain words. It sits somewhere between a policy manual and a hallway conversation: more reliable than asking around, far lighter than formal documentation.
It is not the place for step-by-step procedures. "How do I process a refund?" deserves a proper procedure with numbered steps. The FAQ is for the smaller stuff: facts, policies, who-do-I-ask answers, and pointers to the longer documents. Think of it as the front desk of your team's knowledge. It answers the quick questions itself and directs everything else to the right place.
Step 1: Collect real questions for two weeks
The fastest way to write an FAQ nobody uses is to sit down and invent the questions. You will write the questions you think people should ask, not the ones they do.
Instead, run a two-week collection. Every time someone asks you or anyone else a question that has been asked before, add it to a shared list, worded exactly as it was asked. Ask your two most-interrupted people to do the same. Check the team chat for questions that appear more than once.
After two weeks you will have 15 to 30 real questions. That list, sorted by how often each one comes up, is your FAQ. You are no longer guessing what the team needs to know. They told you.
Step 2: Write answers people can trust
An FAQ lives or dies on the quality of its answers. Four rules keep them useful.
Answer first, context after. The first sentence must contain the answer. "Yes, refunds are available up to 30 days after purchase" and then the details. People are mid-task when they look this up.
Keep the question in the asker's words. Write "how do I book leave?" not "leave request procedure". People search with the words in their heads, and the FAQ should match them.
Name names. "Ask Dana, and if Dana is away, ask Priya" beats "contact the finance function". Named answers are the difference between an FAQ and a policy manual.
Link, don't duplicate. If a full document exists, give a one-line answer and link it. Duplicated detail goes stale in two places at once.
A ready-made structure saves you laying all this out from scratch:
A worked example
Here is a slice of a real-shaped internal FAQ. Notice how each answer leads with the answer.
Q: How do I book annual leave?
Request it in the payroll app at least two weeks ahead. Your manager approves it there. For leave longer than two weeks, talk to your manager first. Full details in the leave policy, linked below.
Q: Do we give refunds after 30 days?
No, 30 days is the cutoff. Exceptions need Maria's approval, and she answers same day. The refund procedure covers the steps.
Q: Who approves invoices when Dana is away?
Priya. Send the invoice to her with "Dana away" in the subject so it is not missed.
Q: What's the wifi password in the meeting room?
HarborGuest2026, on the "Harbor Guest" network. It changes every January.
Four questions, four immediate answers, two links to deeper documents. Nobody was interrupted.
Step 3: Put it where questions get asked
An FAQ in a forgotten folder answers nothing. Two placement rules make the difference.
First, it lives in your team's shared space, alongside your policies and procedures, findable by search. The moment someone has to ask where the FAQ is, the FAQ has failed. It works best as the front door to a proper team knowledge base, where the quick answers link into the deeper documents behind them.
Second, answer questions with links. When someone asks a documented question in chat, reply with the link to the answer, kindly and without ceremony. It is not passive-aggressive, it is training. Within a month, "check the FAQ" becomes "I checked the FAQ", and the interruptions drop. Teams that keep their FAQ in Penno get a further shortcut: anyone can ask the question in plain words and get the answer drawn from the team's own documents, with the source shown, so trust never depends on memory.
Step 4: Keep it alive with one habit
FAQs go stale one small change at a time. The wifi password rotates, Dana leaves, the refund window changes, and each unnoticed change teaches the team the document cannot be trusted. Distrust, not laziness, is why FAQs get abandoned.
One habit prevents it: every new recurring question gets added the day it is answered, and every changed answer gets fixed by whoever made the change. Give the FAQ a single owner whose job is not to write everything but to say "yes, this is still true". A light quarterly skim, half an hour at most, catches whatever slipped through.
Common mistakes to avoid
- Inventing questions instead of collecting them. An FAQ built from imagination answers questions nobody asks.
- Writing policy language. "Leave requests must be submitted via the appropriate process" helps no one. Write the way people talk.
- Burying the answer. Three paragraphs of background before the answer teaches people to stop looking things up.
- Letting it sprawl. Fifty questions with detailed answers is not an FAQ, it is an unsorted manual. Keep answers short and link out for depth.
- No owner. An FAQ everyone can edit and no one is responsible for drifts wrong within a quarter.
Frequently asked questions
What should an internal FAQ include?
The questions your team actually asks repeatedly: policies in plain words, who-to-ask answers, logins and locations, and pointers to longer documents. Collect real questions for two weeks rather than guessing, and start with the 15 to 30 most frequent.
How is an internal FAQ different from a knowledge base?
The FAQ is one document of quick answers. A knowledge base is the whole library: procedures, policies, templates, and the FAQ itself. The FAQ usually comes first because it is the fastest to build, and it naturally becomes the front door to the rest.
How many questions should an FAQ have?
Start with 15 to 30 and let real usage grow it. Below ten, it rarely earns the habit of being checked. Beyond fifty, split it by topic before it becomes a place answers go to hide.
Who should write the company FAQ?
The most-interrupted people write the first draft, because they already know the questions and the answers. Then one named owner keeps it current. Writing is a one-off task. Ownership is the ongoing job.
How do I get my team to actually use the FAQ?
Answer real questions with links to it, every time, until checking first becomes the norm. And keep it trustworthy: one wrong answer costs more usage than ten missing ones.
Ready to stop answering the same question twice? Start from the FAQ template and have your first twenty answers live this week.
