Most teams already have the answers written down. There's a folder, a wiki, or a tab in Notion that nominally covers how the work is done. The questions still come anyway, because the information isn't reachable inside the moment someone needs it. New hires ask the person sitting closest. Senior staff lose hours a week to the same five conversations. The bottleneck isn't writing the SOPs. It's getting them into someone's head.
Case Study, not Delivered Project.
How we'd approach this kind of problem. See delivered projects →
You probably have this problem if…
- New starters spend their first few weeks shoulder-surfing senior colleagues to learn how things work.
- The same procedural questions get asked over and over. Different hires, different months, same answer.
- You have a Notion or Confluence space, but people still default to asking in Slack because it's faster.
- When someone is off, three people will do the same task three different ways from memory.
- Your operations lead spends more time training new hires than running operations.
Any two of those is a strong signal. All of them and you're paying full salary for weeks of partial output while senior staff lose focus to drive-bys.
How the pattern works
Imagine a colleague who has read every SOP, every training note, and every handbook the business has ever written, and who sits next to the new hire on day one. When a question comes up, they answer in plain language and point to the exact section of the exact document the answer came from. That's the system.
Four things have to work for it to be useful.
1. It loads every procedure, once
Procedure documents, training notes, handbook sections, and internal wiki pages are loaded from wherever they already live. Notion, Confluence, SharePoint, Google Drive, a folder of Word files, all of the above. The system splits each document along its natural structure, so an SOP about handling a returned delivery stays grouped step by step rather than chopped into arbitrary fragments. The system can only explain a procedure cleanly if its steps live in the same retrieved passage. This bit sounds dull and matters most.
2. It learns the meaning of each step, not the wording
For each chunk of procedure, the system creates a numerical fingerprint that captures what the step means, not the exact words it uses. A new hire asking "where do I put the after photos?" gets matched to an SOP titled "Site sign-off photography checklist", because the system understands the question and the document are about the same thing. It is matching ideas, not keywords.
The technical name for the fingerprint is a vector embedding. They live alongside the original text in a standard Postgres database, which keeps the stack boring on purpose.
3. It listens like a colleague, not a search box
The interface is conversational. A new hire asks the question the way they'd say it to the person next to them, in their own words and at any level of detail. The system creates a fingerprint for the question, then returns the procedure passages closest in meaning. Typically five to ten, drawn from across the document set. The match is by meaning, so the new hire doesn't need to know the right keyword, the right folder, or the right title.
4. It writes a step-by-step answer and shows the source
Those passages, plus the question, go to a language model that writes a direct answer in plain English. Where the procedure is a sequence, the answer is numbered. Every step carries a citation back to the SOP it came from, so the new hire can read the full document when they want the long version. If the answer isn't in the documents, the model says so rather than inventing one. That refusal is what makes the system trustworthy on procedural questions, where a confident wrong answer is worse than no answer.
Why this is safe for internal-only work
Onboarding content is some of the most sensitive material a company owns. Org charts, escalation playbooks, pricing logic, supplier relationships, security procedures. The well-publicised Samsung incident, where engineers pasted proprietary code into a public LLM and ended up with a company-wide ban, is what most heads of operations have in mind when they hesitate. Four properties of the pattern remove that failure mode.
Runs inside your network if you want it to. The pipeline can deploy on infrastructure you control. An open-weight embedding model and an open-weight answer model run on a single GPU host, or on a managed internal endpoint. SOPs never leave your network. No third-party logging, no training-data ambiguity, no shadow IT through the browser tab.
Cited sources on every answer. Every reply carries a link straight to the procedure it came from. A new hire can verify the step before they act on it. A manager can spot when an answer is drawing on a document that's three years old.
Closed-book by default. The model only answers from text retrieved from your own procedure library. Its general knowledge is switched off for these queries. If the answer isn't in the SOPs, the response is "I don't have a procedure for that, ask your team lead" rather than a plausible guess.
Version-aware. When a procedure changes, the new version is re-ingested in minutes and old answers update. The system flags procedures that haven't been touched in over a year, so review backlog stops being invisible.
The default stack
Two choices that matter most.
Conversational interface over a search results page. A search box that returns links sends the new hire on another hunt. A chat-style answer with citations gives them a procedure they can act on now and a source they can verify later. The behavioural difference shows up in adoption. People will type a question. Most won't type a query.
A Slack or Teams bot alongside the web app. New hires don't sit on a knowledge-base tab all day. They sit in the channel where their team is. A bot that answers from the SOP library inside the channel catches the question before it interrupts a senior colleague.
When this isn't the right fit
The pattern is strong, but it's the wrong tool for a few situations.
You don't have written procedures yet. If the knowledge genuinely lives only in people's heads, the first job isn't a retrieval system. It's a few weeks of structured interviews and writing. The pattern can still help, but the pre-work is the value. We often run that ourselves as part of the audit.
Tiny teams with a single onboarder. Below roughly ten people, an updated wiki and a checklist usually beats the cost of the build. The pattern starts to pay back when you're hiring more than two or three people a year.
Compliance-graded training that needs a signature. Health and safety inductions, regulated qualifications, anything where the legal record of "the person was trained" matters. Use the pattern to teach. Keep the formal sign-off in your LMS.
Questions that aren't really procedural. "Who owns this customer right now?" or "what's the live status of order 4392?" is a data question, not a documents question. A query against the right system will always beat a retrieval against a stale doc.
What to expect
If this pattern fits your team
A Pare Audit is the way to find out whether it does, and what a delivery would look like in your specific situation. We spend a focused few days with you, look at the real onboarding journey and the questions new hires actually ask, and come back with a written recommendation, a scoped build, and a costed plan.