Complaint Response Agent
Triages every patient complaint the moment it lands, flags the clinical-safety ones, and drafts a policy-grounded acknowledgement for staff to approve.
Reads each complaint, classifies intent and urgency against the patient record, routes it, and drafts an acknowledgement citing your own complaints policy — a person approves before anything is sent.
Where this works well
The slow, invisible problem this surfaces is the lag between a complaint arriving and a human realising it is actually a clinical-safety event. In a busy practice, "I changed my medication and now I feel faint, I rang twice and no one called back" sits in the same inbox as a parking gripe and a records request, and it waits its turn. This pattern reads every complaint as it lands, and the one that mentions a new symptom after a medication change jumps to the top with a High-urgency flag and a route to clinical governance — before anyone has triaged the queue by hand.
It earns its keep where complaint volume is high enough that triage is a real cost, where complaints arrive as readable text (email or web form), and where there is a written complaints policy and a routing map it can ground against. The practice manager or complaints officer is the person who benefits most: they stop starting from a cold inbox and start from a classified, verified, routed draft. It also helps the clinical-governance lead, because the messages that need them are surfaced rather than discovered late.
Where it works badly
It works badly when the signal isn't in the text it can read. A complaint left as a voicemail with no transcript, or one whose substance is in a scanned letter attached as an image, gives it almost nothing — it will classify on the thin covering note and be confidently incomplete. It also struggles with complaints that are clinically serious but written calmly: a patient who describes a worsening symptom in flat, polite language may not trip the urgency it deserves, because urgency partly rides on the words used. The honest test: read your last twenty complaints and ask how many would classify correctly from their text alone, and how many needed a phone call or a record you'd have to open anyway.
It is also poorly suited to a practice whose patient record and medication list are not current. The clinical-safety flag is only as good as the data behind it — if the medication list lags the GP's notes, the tool can flag against the wrong drug, or miss a flag entirely. In that situation the flag is worse than no flag, because it looks authoritative.
What it doesn't do — and shouldn't
It surfaces and drafts; it does not decide and does not send. It classifies intent and urgency, verifies the patient by date of birth, cross-references the record, flags a possible adverse drug reaction, and drafts an acknowledgement that cites your complaints policy. It does not decide whether an event is reportable, whether open disclosure under the Australian Open Disclosure Framework is triggered, whether a notification to AHPRA or the relevant health complaints commissioner is warranted, or what clinical advice the patient should receive. Those are human judgements with legal and ethical weight, and the boundary is deliberate.
The draft is never auto-sent. For a clinical-safety complaint the draft is explicitly an acknowledgement only — it books a clinician callback and tells the patient what to do if symptoms worsen; it does not tell them whether to keep taking a medication. A clinician reviews before it goes. This is the line between accelerating the thinking and replacing the thinker, and in healthcare it is not negotiable.
What your data has to look like for this to work
Four things have to be in good shape. First, complaints have to arrive as text the tool can read — an email body or a web-form submission, not a voicemail or an image. Second, the patient record has to support identity verification, so a name and date of birth in the message can be matched to a record rather than guessed. Third, the medication list and recent call logs have to be current to the day, because the clinical-safety flag depends on what the patient is taking now. Fourth, you need a written complaints policy with clause-level structure (so an acknowledgement can cite the relevant section, the way the demo cites the policy's acknowledgement-timeframe clause) and a routing map that says which category goes to clinical governance, the practice manager, reception or records.
Most practices have some of this and not all of it. The complaints policy exists but isn't structured so a clause can be cited; the routing rules live in someone's head; the medication list is current in the clinical system but not reachable by the inbox. Getting these into shape is usually the real first job, and it is mostly about how information is captured and connected, not about buying a tool. That groundwork is the work we help with, and it is usually larger and more valuable than the AI layer that sits on top of it.
Could it draft a reply that misses a clinical-safety problem, or reassure a patient it shouldn't?
It is built to do the opposite of reassure when a message hints at clinical harm. A complaint that mentions a new symptom after a medication change — like a dry cough on perindopril, a known ACE-inhibitor reaction — is flagged High urgency, routed to clinical governance, and the draft is an acknowledgement only that books a clinician callback. It never offers clinical advice or tells a patient whether to keep taking a medication. The draft is held for staff approval, and the escalation flag is the loudest thing on the screen.
Our complaints arrive as forwarded emails, voicemail transcripts and half-finished web forms. Will it cope with that mess?
It copes better with text it can read than with what it can't. A forwarded email thread or a pasted web-form body classifies well; a voicemail with no transcript, or a complaint buried in a scanned PDF attachment, gives it little to work with and the classification confidence drops. When confidence is low it says so rather than guessing, and the item still lands in front of a person. It accelerates the clear cases so your staff have more time for the genuinely ambiguous ones.
Does this replace our practice manager or complaints officer?
No. It does the first read — classify, verify, route, draft — so the person who owns the complaint starts from a structured summary and a draft instead of a cold inbox. Every judgement that matters (is this an adverse event, does this trigger open disclosure, should this go to AHPRA or the health complaints commissioner) stays with a named human. It recaptures the time spent triaging and first-drafting, and points it at the complaints that need real handling.
How current does the patient data have to be? We don't want it reading a medication list from before a change.
Currency is the whole game for the clinical-safety flag. The medication list and recent call logs need to reflect today's state, because the flag depends on what the patient is actually taking now. If your clinical system syncs in real time the cross-reference is trustworthy; if the medication list is updated in batches or lags the GP's notes, the flag can be stale — and a stale flag in this setting is a real risk, so we'd scope the data freshness before going near live complaints.
Where does the complaint and patient data go — does it leave our systems or train an external model?
It runs against your own records and your own policy library, and the content is not used to train any external model. Patient identifiers and complaint text are sensitive health information under the Privacy Act and the Australian Privacy Principles, so where the data sits and who can see it is part of the build, not an afterthought. We scope hosting and access with you before any real complaint touches it.
Who is accountable if the draft acknowledgement gets something wrong?
The person who approves and sends it — exactly as today. The tool drafts and cites; it does not send. Because every draft carries the policy clauses it relied on and the records it cross-referenced, the approver can see why it said what it said and correct it before it goes out, which is a better audit trail than a reply typed from scratch under time pressure.
Estimated build: 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.