A hotel team from Germany needed one place for their SOPs, manuals and staff know-how. Their hotel-specific tool had no page verification, limited formatting, no way to suggest edits and no way to share a page with someone outside the tool. The team compared six alternatives, including building their own wiki, and chose Perfect Wiki inside Microsoft Teams.
The hotel's director shared why they left their old tool, what they ruled out, and what tipped the decision.
At a glance
Challenge: The team's hotel-specific wiki couldn't keep content verified and current, and pages couldn't be shared with people outside the tool.
Options compared: Notion, Slite, GitBook, Outline, a self-hosted wiki, and a custom build with Astro Starlight and Claude.
Why Perfect Wiki: Page verification, rich formatting, suggestions from readers, sharing with non-users, and sign-in through Microsoft Entra ID, all inside Microsoft Teams.
Setup: An annual plan with two editors to start, with more editors planned.
What was the challenge?
Question: What were you using before, and why did you start looking for something else?
Answer: “We used Hotelkit in the past as our hotel-specific wiki and manuals. It lacked crucial features: no verification, no richer formatting options, no suggest-edit feature and no sharing of pages with non-users. There are other hotel-specific tools, but they all run into similar issues.”
Each gap hits hotel operations directly:
- No verification: nobody can tell whether a check-in or housekeeping procedure still reflects how the hotel works today.
- Weak formatting: SOPs need tables, checklists and images, not plain text.
- No suggest-edit: the front-desk agent who spots an outdated step has no simple way to flag it to the page owner.
- No sharing with non-users: contractors, seasonal staff and partners can't open a page without getting an account.
The team also had two practical requirements. They expected heavy use of an AI chatbot for staff questions, and they wanted protection against a wiki being deleted by mistake or on purpose.
Which alternatives did they consider?
The team looked at general-purpose wikis, a self-hosted option and a custom build. Here is why each one lost out, in the director's words.
| Option | What they liked | Why it lost |
|---|---|---|
| Notion | “I am a fan in general” | “Too much overload for this use case” |
| Slite | Less overload and cheaper than Notion; great design; a good review and verification workflow; AI fact-checking with suggested fixes | Too many formatting options for some staff: “some users are overwhelmed with advanced formatting options” |
| GitBook | — | “Too little in the free plan, too much in Essential and Ultimate” |
| Outline | “Looks good” | No suggest-edit feature |
| Self-hosted wiki | — | “More maintenance than a cloud provider, less customisability than in-house development” |
| Build in-house (Astro Starlight + Claude) | Full control; a quick mock-up was already running | Not worth the director's time at this stage |
Question: You seriously considered building your own wiki. Why didn't you?
Answer: “Another real option was to build a simple wiki in-house and route all changes through Claude or through me. I would have used Astro Starlight, and I had a quick mock-up. If I wasn't the director and had fewer things to do, I probably would have built something in-house. At this stage, it's not worth it, and a lot of the features, including the Microsoft Entra integration, are well done with Perfect Wiki.”
Why did they choose Perfect Wiki?
Perfect Wiki closed all four gaps the old tool left open, without the overload of a general-purpose workspace.
- Verification: each page can be marked as verified, so staff can see that an SOP has been checked and is current.
- Formatting: the editor handles tables, checklists, images and callouts, while staying simple enough for staff who only read.
- Suggestions from readers: any reader can send feedback on a page; it arrives as a comment on that page for the editors to act on.
- Sharing with non-users: a page or a whole knowledge base can be shared by link with people who don't have a Microsoft Teams account.
- Free readers: only editors are paid; everyone who only reads is free.
- Microsoft Entra sign-in: staff sign in with the Microsoft accounts they already have. There are no separate passwords to manage, and access ends when IT disables an account.
How does the team use Perfect Wiki?
The team started on an annual plan with two editors, who write and maintain the content. Everyone else reads, so the rest of the staff don't add to the cost. More editors will join as departments take ownership of their own pages.
- One place for operations: SOPs and manuals that used to live in the old hotel tool now sit in a knowledge base inside Microsoft Teams.
- AI answers for staff: the team expects staff to ask the Perfect Wiki AI chatbot questions rather than search pages, so AI usage was part of the plan from day one.
- A safety net: the whole wiki can be exported as a backup at any time, which covered the team's worry about a page or knowledge base being deleted.
Question: What is the hardest part of running a hotel wiki?
Answer: “Maintaining a wiki takes effort, and every employee hates it.”
That is why verification and reader suggestions mattered most. Editors see which pages need a check, and the staff who use an SOP every shift can flag what has changed.
What can other hotels learn from this?
- Check for verification first. A hotel SOP that nobody has confirmed is a liability at the front desk.
- Let readers flag problems. The people on shift know first when a procedure changes.
- Pick a tool sized to the job. A general workspace can overwhelm staff who only need to read a procedure.
- Use the sign-in you already have. With Microsoft Entra ID, new hires get access on day one and leavers lose it the day IT closes their account.
Starting from scratch? Our free hotel SOP templates cover guest check-in, front desk, housekeeping and more.
