build.allanninal.dev

Part 1 of 7 · Staff policy answerer series ~5 min read

A staff policy answerer on AWS for a few dollars a month

Every small business answers the same handful of staff questions over and over. How many sick days do I have left? What’s the rule on travel expenses? Can I carry leave into next year? Who approves overtime? Today those questions land in HR’s inbox, or a manager’s DMs, or they get a half-remembered answer from a colleague who read the handbook once in 2023. This post walks through the design of a small assistant that answers them in chat — in plain words, from your own real policy docs — links the exact section it used, and says “I’m not sure, ask HR” when the answer isn’t in the handbook. It never makes up policy. Think of it as the inside-the-company twin of the website chat assistant: same idea, but pointed at staff and the handbook instead of customers and the website.

Key takeaways

  • Staff ask in Slack; answers come from your own handbook, never from the model’s own opinions.
  • Every answer ends in one of three moves: a grounded answer with a section link, “ask HR,” or a clean handoff.
  • The handbook lives in Drive. Edit a policy doc and the answerer re-reads it within minutes — no deploy.
  • If the answer isn’t in the docs, the assistant says so. It does not guess.
  • Designed on AWS for about $3/month at typical small-business volume.

The whole system on one page

Before any code, here’s the shape of what we’re designing.

System shape: three sources, three pieces inside AWS At the top, three external boxes in a row. Far left, "Handbook" — a Google Drive folder holding your real policy docs: the employee handbook, the leave policy, the expense policy, the code of conduct, and any other source-of-truth documents. Centre, "Rules and voice" — a Drive folder with a rules doc covering what the assistant may and may not answer, the escalation contacts per topic, and a voice doc with the tone and phrasing templates. Far right, "Staff" — the employees who ask questions; they ask in a Slack DM or a shared channel, and the answer lands back in the same thread. Each connects via an arrow to the AWS account container below. The handbook has an outgoing arrow into AWS, where it is read and indexed. Rules and voice feed in to ground every answer and keep the tone right. Staff send a question in and receive a plain-words answer with a link to the exact handbook section, or an honest "ask HR" when the handbook doesn't cover it. Inside the AWS account are three components in a row, mirroring the layout above. On the left, the Indexer — reads the handbook docs, splits them into sections, and stores each section so it can be searched by meaning, not just keywords. In the middle, the Answerer — takes a staff question, finds the few handbook sections most likely to hold the answer, and asks the model to answer using only those sections. On the right, the Reply — sends the grounded answer back into Slack with the section link, or sends "ask HR" and a clean handoff when nothing matched. Internal arrows flow left to right. A note at the bottom reads: every answer is grounded in a real section — the answerer never invents policy. Handbook your real policy docs Rules and voice limits, escalation, tone Staff where they ask docs in grounds answer with link AWS account Indexer split docs into searchable sections Answerer find sections, answer from them only Reply answer + link, or “ask HR” sections answer Every answer is grounded in a real section — the answerer never invents policy.
Fig 1. Three sources outside, three pieces inside AWS. The handbook, the rules, and the staff. The Indexer makes the docs searchable. The Answerer answers from those docs only. The Reply sends a grounded answer with a link, or an honest “ask HR.”

What you set up once (the outside)

  • The handbook. A Google Drive folder holding the policy docs you already have: the employee handbook, the leave policy, the expense policy, the code of conduct, the remote-work rules, whatever your business actually runs on. These are the only source of truth the assistant is allowed to answer from. You don’t rewrite them for the machine. You drop the same documents your team already reads into one folder and point the assistant at it.
  • A rules folder. Two short Google Docs in a Drive folder. The rules doc sets the boundaries: which topics the assistant may answer (leave, expenses, hours, conduct) and which it must always hand to a human (anything about pay disputes, terminations, grievances, or legal questions). It also names the escalation contact per topic — who “ask HR” actually points to. The voice doc holds the tone: short, kind, plain words; always link the section; never sound like a lawyer.
  • Staff. The people who ask. They ask the way they already talk to each other — a Slack DM to the assistant, or an @-mention in a shared #ask-hr channel. The answer comes back in the same place, with a link to the exact handbook section so anyone can check the source for themselves.

What runs on every question (the inside)

  • The indexer. Reads the handbook docs from Drive, splits each one into small sections (usually a heading plus its paragraphs), and stores every section in a way that can be searched by meaning, not just exact words. This matters because nobody asks a question using the handbook’s exact words. Somebody types “how many sick days do I have left”; the handbook section is titled “Paid Personal Leave Accrual.” The indexer is what lets the right section come back anyway. It re-runs whenever a doc changes, so the assistant is always answering from the current version.
  • The answerer. Takes the staff question, finds the few handbook sections most likely to hold the answer, and asks the model to write an answer using only those sections. The prompt is strict: answer from the provided sections, quote the rule, and if the sections don’t contain the answer, say so plainly. The model never gets to fall back on what it “knows” about leave policy in general — only what’s in your docs counts.
  • The reply. Sends the answer back into the same Slack thread. A grounded answer comes with the plain-words explanation and a link to the section it used. When nothing in the handbook matched, the reply is honest: “I couldn’t find this in the handbook — here’s who to ask,” with the right HR contact for that topic. Every question and answer is logged so HR can see what staff are actually asking.

In plain words

It’s Tuesday and Dev wants to book Friday off but isn’t sure he has the days. He DMs the assistant: “how many vacation days do I have left this year?” The assistant can’t answer that one from the handbook — his personal balance isn’t a policy, it’s a number in the HR system — so it says: “I can’t see your personal balance, that lives in the HR portal. But the policy is 20 days a year, accrued monthly, and up to 5 can carry into next year — [link: Leave Policy §3]. For your exact remaining balance, ask Priya in HR.” Honest about what it knows, useful about what it can.

An hour later someone else asks “can I expense an airport lounge pass?” The handbook does cover that — the expense policy lists lounge access as not reimbursable unless a flight is delayed over three hours. The assistant answers exactly that, in one short paragraph, with the section link. No back-and-forth, no waiting for HR to get to the email, no guessing.

The cost of running this is about $3 a month at SMB volume. The cost of not running it is HR answering the same twenty questions every week, and the slow drift where half the team operates on a policy that changed a year ago.

Design rules that shaped every decision

  • Answers come only from your handbook. The model is told to ignore its own general knowledge.
  • Three moves, always. Grounded answer, “ask HR,” or a clean handoff on off-limits topics. There is no fourth.
  • Every grounded answer links the exact section, so staff can check the source themselves.
  • “I’m not sure” is a valid, encouraged answer. Guessing about policy is the one thing it must never do.
  • The handbook lives in Drive. Editing a policy doesn’t need a deploy — the indexer re-reads it.
  • Every question is logged. HR sees what staff ask and where the handbook has gaps.

Why this shape

Most teams answer policy questions in one of three ways: HR fields them one at a time, a manager guesses, or somebody searches a 40-page PDF and gives up. HR fielding them works until HR is busy, on leave, or fielding the same question for the fortieth time. A manager guessing is how two people on the same team end up with two different answers about carry-over leave. And the 40-page PDF is technically the source of truth, but nobody reads it — it’s a search problem wearing a document costume.

The setup above keeps the source of truth where it belongs — in the policy docs HR already maintains — but adds a small system that reads those docs every time someone asks, and answers only from them. Answers come back in seconds, in plain words, with the exact section attached so anyone can verify. When the handbook genuinely doesn’t cover something, the assistant says so instead of inventing a plausible-sounding rule. The assistant is invisible most of the time; useful the moment somebody has a question they’d otherwise have to interrupt a person to answer.

The next four posts walk through each piece in turn: how a staff question reaches the answerer, how a policy answer gets grounded in the right section, how a policy answer stays honest, and how the handbook stays current. One diagram per post. A cost breakdown and a final engineering reference at the end.

All posts