Keep a small company wiki current

Do not begin by scheduling a review of every page in the workspace. List the pages people use to price work, make a customer promise, give access, complete a recurring task, or answer a question that would be expensive to rediscover. Put the owner and the current review state beside each page. A short list of high-impact pages is easier to maintain than a large catalogue that nobody checks.

Separate reference pages from drafts, meeting notes, and old project material. If a page is no longer a current instruction, label or archive it according to your existing workspace rules. Move outdated material to a clearly labelled archive so current instructions remain easy to find.

Assign a role or person who can confirm the page and make a correction. The author may be the right owner, but authorship alone does not guarantee that someone still maintains the content. If ownership changes, update the register and the page itself so the next editor knows who to ask.

Notion's wiki documentation says the creator of a wiki page is its owner by default, and that the owner can be changed. It also describes verification for a set period or indefinitely, with a notification to the owner when verification expires. Those are Notion-specific features. The page owner still needs to check the actual instructions.

Choose a review interval based on how quickly the information changes and what a stale page could cause. A page about a frequently revised customer handoff may need a shorter cycle than a stable description of the company. Also name event triggers, such as a policy change, a new tool, an owner leaving, or a repeated question that reveals a missing step.

Treat a review date as a reminder to inspect the page. Update it sooner if the process changes. If nothing changed during a scheduled review, record who checked it and when so the next reader can distinguish a current reference from an untouched one.

The owner should compare each instruction with the source that currently governs the work. Check links, names, conditions, and the order of actions. Ask someone who uses the page to follow the steps when the process is easy to misunderstand. If they cannot complete the task, revise the page before marking it current.

Keep a brief change note with the date, editor, and reason. When a change affects how another team works, tell those people where the updated instruction lives. A verification icon or a green status is a useful signal only if the team understands who performed the check and what was checked.

In this fictional example, the Client kickoff checklist still points to a retired intake form. Its owner is the Client Operations Lead, and the page is marked Overdue because the intake process changed in September. The owner checks the current intake source, replaces the link, asks a coordinator to follow the revised steps, and records the change date. The page becomes Current after the test, while the register preserves who checked it.

Limit the review to the named checklist. If the same link appears in a proposal template or team FAQ, add each page to the follow-up list and assign its own owner.

At a regular team check-in, look only at pages due for review, pages affected by a known change, and pages that someone has flagged as confusing. Track the next action if a review cannot be completed. Do not label a page current simply because its owner has not reported a problem.

Notion's help page notes that verification for individual pages outside a wiki is available on Business and Enterprise plans. Product access can vary, and another workspace may use a different method. A basic spreadsheet or page index can still record ownership and review dates if your current tool has no verification feature.

Ask Areinum Assistant to prepare a review list from the page inventory you provide, including owners, review dates and changes that may need attention. The page owners check and update their own instructions.