Tier-1 HR Query Assistant
Answers staff leave, pay and policy questions from your own handbook, enterprise agreement and awards — quotes the clause it relied on, and routes anything not in the documents to a person.
Grounds every answer in your approved HR documents, cites the clause, and refuses (rather than guesses) when the answer isn't there — so People & Culture only see the questions that genuinely need them.
Where this works well
The underrated insight this surfaces is how much of an HR inbox is the same dozen questions asked in slightly different words — personal/carer's leave accrual, when payday falls, notice periods, what salary-sacrifice arrangements exist. None of these are hard; they are just answered from documents your team already maintains, and answering them one by one is invisible work that never shows up as a project. This pattern earns its keep when that volume is real and the answers genuinely live in approved documents: an enterprise agreement, a leave and entitlements policy, payroll SOPs, a staff handbook.
The role that benefits most is a People & Culture team of one to a handful, in an organisation of a few hundred staff, where the same person fields routine queries and the genuinely sensitive ones. Deflecting the routine layer — with the §4.2 clause shown so the asker trusts it — is what hands that person their week back for the cases that actually need a human.
Where it works badly
It works badly anywhere the answer isn't already written down. If your "policy" on a question lives in a manager's head, in a five-year-old email, or in custom and practice rather than the enterprise agreement, the tool can't retrieve it — at best it refuses, at worst it answers from an adjacent document that doesn't quite apply. It is also only as right as the corpus is current: feed it last year's enterprise agreement after a new one is ratified and it will confidently quote a superseded clause, because it has no way to know the document is stale.
The honest test: pick your ten most common HR questions and ask whether each has a single, current, written, approved answer you could point to a clause for. If most do, this fits. If most resolve to "it depends, ask me", the tool will spend its time refusing, and the real first job is writing the policy down — not buying an assistant.
What it doesn't do — and shouldn't
It surfaces what your documents say and cites where; it does not decide what the answer should be when the documents are silent, contradictory, or wrong. A staff member's specific circumstances — a disputed carer's-leave claim, a redundancy question, a grievance — are escalated to People & Culture by design, not answered. When two documents conflict, it flags both rather than ruling; a person decides which governs.
That boundary is deliberate. HR and payroll answers carry legal and financial consequence, and the worst outcome isn't "no answer" — it's a confident wrong one that a staff member acts on. So the tool is built to refuse loudly and route to a human on anything outside the approved corpus, and to keep a person on every flagged answer. We accelerate the reading of your policy; we don't replace the person who owns it.
What your data has to look like for this to work
Concretely: the documents that govern entitlements need to exist as approved, versioned files — an enterprise agreement with clause numbers (e.g. cl. 22.3), a leave policy with sections (§4.2), payroll SOPs, a current staff handbook — each carrying a version and a date so currency is visible. The content has to be specific enough to answer from: "10 days paid personal/carer's leave accruing progressively, casuals 2 days unpaid per occasion" is answerable; "leave is provided in line with the relevant standards" is not. And there needs to be a named owner and a re-index step so that when a policy changes, the corpus changes with it.
Most organisations have some of this in good shape and some of it scattered, out of date, or quietly contradictory across documents. Getting the corpus to a state where every common question maps to one current, approved, citable passage is usually the larger and more valuable piece of work — and it's about how your policy is captured and governed, not about buying a tool. That's the part Real Minds AI helps with, and it's typically bigger than the AI layer on top.
Could it give someone wrong advice about their leave or pay and land us in a dispute?
It only answers from the documents you have approved and loaded, and it shows the exact clause it relied on — for example "Leave & Entitlements Policy v6, §4.2" — so the asker and People & Culture can both check it. When a question isn't covered in the corpus it refuses and escalates rather than guessing, which is the opposite of the failure mode that causes disputes. It is a first-line reader of your own policy, not a source of new advice.
Our enterprise agreement, policies and handbook don't always agree with each other. What happens then?
This is the most common real-world problem and the tool surfaces it rather than hiding it — if two documents address the same question differently, both passages come back cited and the answer flags the conflict instead of silently picking one. That visibility is useful, but it does not resolve the conflict; a person in People & Culture decides which document governs and the corpus is corrected. Reconciling those documents is usually part of the setup work.
Does this replace our People & Culture / HR team?
No. It deflects the high-volume, low-variation questions — leave accrual, payday, notice periods — that fill the inbox every Monday, so the team's time goes to the judgment calls, grievances and edge cases the tool deliberately escalates. Capacity is recaptured and redirected, not removed. Every refusal and every "needs work" flag lands with a person who owns the answer.
How current does the policy content have to be? We update our agreement and policies during the year.
Answers are only as current as the documents in the corpus, so currency is the whole game. Each document carries a version and date (e.g. "v6, updated Feb 2026"), and when you ratify a new enterprise agreement or reissue a policy the corpus has to be re-indexed for the change to take effect. A stale corpus is the main way this gives a confidently outdated answer, so a defined re-index step on every policy change is part of running it.
Where does our staff data and these questions go? Is anything sent to train a public model?
The corpus is your own documents in a private retrieval index, and questions are answered against that index — nothing is used to train a public model. Staff questions can touch personal circumstances (a carer's situation, a pay query), so the conversation log is treated as HR data with the same access controls and retention rules as the rest of your People & Culture records. Who can see the logs and how long they're kept is a decision you set, not us.
What stops it from just making up a plausible-sounding answer?
Two things. It retrieves before it answers, and the answer is built from the matched passages with the sources shown, so a claim with no source behind it doesn't get made. And the refusal path is a first-class behaviour, not an error — "salary-sacrifice into cryptocurrency" returns an amber "not in your approved documents" card and an escalation, because guessing on a payroll matter is exactly what it must not do.
Estimated build: 2–4 weeks. Most of it is template work we've already done.
Fixed scope, fixed price, fixed dates.
The cost band reflects the engagement shape, not a per-feature line item. We work on fixed scope, fixed price, fixed dates — see the services catalogue for what falls inside each band.
Considering this for your org?
The honest place to start is a bite-sized first piece — one contained change, low risk. Tell us where it hurts; we’ll play it back, scope it, and show you what’s possible.