This file enumerates the intent categories a client message can fall into during Bob's conversational income-protection intake. The public Bitext insurance chatbot dataset (around 39 generic intents) is used only as a starting scaffold; the categories below are re-cut and re-worded for an NZ adviser-in-the-loop context, with NZ-voice example utterances. Three intents are high-stakes and must change Bob's behaviour: a price or quote request (Bob defers, never invents a number), a vulnerability or hardship signal (route to care and a human), and a request for a human handoff (hand to the licensed adviser). Each section is a self-contained RAG chunk describing one intent.
How to read this taxonomy
Each intent has a short definition, an NZ-voice example utterance, and a behaviour note for
Bob. A single client message can carry more than one intent (for example a concern plus a
question), so the classifier should allow multiple labels and always surface the highest-stakes
one first. The high-stakes intents are ask_price_or_quote, vulnerability_or_hardship_signal,
and request_human_handoff: these must override normal flow. Bob gives regulated financial
advice only through the licensed adviser in the loop, so when an intent edges toward a personal
recommendation or a number, Bob captures and defers rather than answering. The example
utterances here are invented NZ-voice samples for labelling, not real client messages.
Source: Bitext insurance chatbot dataset (https://huggingface.co/datasets/bitext/Bitext-insurance-llm-chatbot-training-dataset) · retrieved 2026-06-18 · rights: own-summary · drives: information · status: draft
provide_information
The client volunteers a fact about themselves or their situation that intake needs to capture: occupation, income band, dependents, employment type, health context, the reason they are enquiring, or a correction to something already on file. This is the workhorse intent of intake and most messages contain some of it. Bob captures the structured field, confirms back in plain words, and moves on without over-questioning.
Example (NZ voice): "I'm a self-employed sparky, two kids, been going about six years now."
Source: Bitext insurance chatbot dataset (https://huggingface.co/datasets/bitext/Bitext-insurance-llm-chatbot-training-dataset) · retrieved 2026-06-18 · rights: own-summary · drives: information · status: draft
answer_question
The client is directly answering a question Bob asked, often tersely. This is distinct from
provide_information because it is scoped to the open question and may be a yes/no, a single
value, or a short clarification. Bob should bind the answer to the field it asked about, handle
ambiguity ("a bit" / "depends") by gently confirming, and not re-ask what has been answered.
Example (NZ voice): "Yeah nah, no dependants, just me and the mortgage."
Source: Bitext insurance chatbot dataset (https://huggingface.co/datasets/bitext/Bitext-insurance-llm-chatbot-training-dataset) · retrieved 2026-06-18 · rights: own-summary · drives: information · status: draft
ask_definition_or_explain
The client wants a term, product, or concept explained, with no personal recommendation
attached: what income protection is, what a wait period or stand-down means, the difference
between indemnity and agreed value. Bob can answer these as general education (drives:
information) using the glossary and product knowledge, written plainly, without tipping into a
personal recommendation. If the question quietly asks "what should I pick", treat it as
express_concern_or_objection or defer to the adviser.
Example (NZ voice): "What's a wait period actually mean, like when does it start paying out?"
Source: Code of Professional Conduct for Financial Advice Services (https://www.fma.govt.nz/library/guidance-library/code-of-professional-conduct-for-financial-advice-services/) · retrieved 2026-06-18 · rights: public-govt-attribution · drives: information · status: draft
ask_price_or_quote (HIGH-STAKES, DEFER)
The client asks what cover will cost: a premium, a quote, a monthly figure, or "roughly how much". This is high-stakes. Bob must never invent, estimate, or imply a number, because pricing is underwriting and regulated advice territory, not something the conversational layer decides. Bob acknowledges the question, explains that an accurate figure depends on details the licensed adviser confirms, and defers: it captures the question and routes pricing to the adviser or the proper quoting step. No range, no "ballpark", no anchoring number.
Example (NZ voice): "Just give us a rough idea, what would this run me a month?"
Source: Bitext insurance chatbot dataset (https://huggingface.co/datasets/bitext/Bitext-insurance-llm-chatbot-training-dataset) · retrieved 2026-06-18 · rights: own-summary · drives: information · status: draft
express_concern_or_objection
The client raises a worry, doubt, or push-back: cost worry, distrust of insurers, "do I even need this", a bad past claims experience, or scepticism that a payout would ever come. This intent is the front door to either reassurance (general, factual) or an adviser handoff if it needs a recommendation. Bob should acknowledge the concern genuinely, address the factual part where it can, and avoid both dismissing the worry and over-promising. Concerns that turn on "what should I do" become adviser territory.
Example (NZ voice): "Honestly these things never pay out when you actually need them, do they?"
Source: Code of Professional Conduct for Financial Advice Services (https://www.fma.govt.nz/library/guidance-library/code-of-professional-conduct-for-financial-advice-services/) · retrieved 2026-06-18 · rights: public-govt-attribution · drives: information · status: draft
request_human_handoff (HIGH-STAKES)
The client explicitly asks to talk to a person, an adviser, or a human, or signals they have lost trust in talking to a bot. This is high-stakes: a stated wish to reach a human must be honoured promptly, not deflected or buried in more questions. Bob confirms it is connecting them to the licensed adviser, preserves the context captured so far, and sets a clear expectation of what happens next. Honouring a handoff request supports fair treatment of the client.
Example (NZ voice): "Can I just talk to an actual person about this?"
Source: What to expect from your financial provider, FMA (https://www.fma.govt.nz/news/all-releases/media-releases/the-fma-what-to-expect-from-your-financial-provider/) · retrieved 2026-06-18 · rights: public-govt-attribution · drives: information · status: draft
change_or_correct_answer
The client revises something already captured: a wrong income figure, a changed job, a
dependant they forgot, or "actually, scrap that". Distinct from provide_information because it
overwrites prior state rather than adding to it. Bob should locate the existing field, update it,
confirm the change back in plain words, and make sure downstream summaries reflect the latest
value, not the stale one.
Example (NZ voice): "Actually nah, change that, I said 80k but it's more like 95 now."
Source: Bitext insurance chatbot dataset (https://huggingface.co/datasets/bitext/Bitext-insurance-llm-chatbot-training-dataset) · retrieved 2026-06-18 · rights: own-summary · drives: information · status: draft
ask_about_process_or_timing
The client wants to know how the process works or how long something takes: what happens next, how long an application or claim takes, what they will need to provide, when the adviser will be in touch. Bob can answer these factually from process knowledge (drives: information), set honest expectations, and avoid promising timeframes it cannot stand behind. Early, direct information about next steps and rights is part of treating the client well.
Example (NZ voice): "So what happens after this, how long till it's all sorted?"
Source: Supporting customers in financial difficulty, FMA and Commerce Commission joint messaging (https://www.comcom.govt.nz/__data/assets/pdf_file/0036/328689/FMA-ComCom-joint-messaging-18-Sep-2023.pdf) · retrieved 2026-06-18 · rights: public-govt-attribution · drives: information · status: draft
vulnerability_or_hardship_signal (HIGH-STAKES)
The client shows signs of vulnerability or hardship: financial difficulty, recent job loss, serious illness or bereavement, mental-health distress, low confidence or comprehension, language barriers, or pressure and urgency that suggest they are not in a position to make a considered decision. The FMA treats a vulnerable consumer as someone who, because of their personal circumstances, is especially susceptible to harm, and vulnerability can arise from an event such as losing a job. This is high-stakes. Bob must slow down, drop any sales pressure, respond with care, and route to a human and, where relevant, point to support such as a licensed adviser or a financial-mentoring service. Detecting and supporting vulnerability is an explicit FMA expectation of providers across the whole customer journey.
Example (NZ voice): "I just lost my job and I'm really struggling, I don't even know if I can afford this."
Source: Customer vulnerability, our expectations for providers, FMA (https://www.fma.govt.nz/library/guidance-library/customer-vulnerability-our-expectations-for-providers/) · retrieved 2026-06-18 · rights: public-govt-attribution · drives: information · status: draft
decline_to_answer
The client declines to share a requested detail, or pushes back on why it is needed: "I'd rather not say", "why do you need that", or simply skips the question. Bob should respect the decline, explain briefly why the field matters if asked, never pressure, and where possible continue with what it has rather than blocking. Repeated probing of a declined field reads as pressure and undermines fair treatment.
Example (NZ voice): "I'd rather not put my income in writing to be honest."
Source: Customer vulnerability, our expectations for providers, FMA (https://www.fma.govt.nz/library/guidance-library/customer-vulnerability-our-expectations-for-providers/) · retrieved 2026-06-18 · rights: public-govt-attribution · drives: information · status: draft
off_topic_or_chitchat
The client says something social, tangential, or unrelated to intake: a greeting, a joke, a comment about the weather or the rugby, or a question outside Bob's scope. Bob should respond briefly and warmly, keep rapport without being robotic, and steer gently back to the intake when appropriate. This intent should never be misread as substantive content to capture.
Example (NZ voice): "Bit of a mission this, eh. Crazy weather out there today."
Source: Bitext insurance chatbot dataset (https://huggingface.co/datasets/bitext/Bitext-insurance-llm-chatbot-training-dataset) · retrieved 2026-06-18 · rights: own-summary · drives: information · status: draft
consent_or_disclosure_acknowledgement
The client agrees to, queries, or declines a consent or disclosure step: acknowledging Bob's disclosure about who is advising them, agreeing to a privacy or data-use statement, consenting to be contacted, or agreeing to share information with the licensed adviser. NZ rules require an adviser to make disclosure available when the nature and scope of the advice becomes apparent, covering the licence held, the service and its limits, fees and conflicts, and the complaints process. Bob should record the acknowledgement clearly, not bury it, and treat a refusal of consent as a real signal that may limit what can proceed.
Example (NZ voice): "Yep, all good, I'm happy for you to pass my details to the adviser."
Source: Financial Markets Conduct (Regulated Financial Advice Disclosure) Amendment Regulations 2020 (https://www.legislation.govt.nz/regulation/public/2020/0132/latest/whole.html) · retrieved 2026-06-18 · rights: public-govt-attribution · drives: information · status: draft
Labelling guidance and high-stakes precedence
When a message carries several intents, label all that apply but act on the highest-stakes one
first. Precedence for action: vulnerability_or_hardship_signal and request_human_handoff
come first (route to a human with care), then ask_price_or_quote (defer, never price), then the
informational and capture intents. A decline_to_answer or a change_or_correct_answer always
overrides a stale captured value. When an intent drifts toward a personal recommendation or a
number, downgrade Bob's role to capture-and-defer so that regulated advice stays with the
licensed adviser. This precedence keeps the conversational layer inside general information
(drives: information) and out of regulated advice.
Source: Code of Professional Conduct for Financial Advice Services (https://www.fma.govt.nz/library/guidance-library/code-of-professional-conduct-for-financial-advice-services/) · retrieved 2026-06-18 · rights: public-govt-attribution · drives: information · status: draft