An AI IVR identifies the member before any lookup and only gives the status of an authorization request it read in the source system, through the API. If identification fails, the lookup fails or the request is out of scope, the call goes to the right queue with what was already collected. The AI does not generate or infer a status. Checking a status is also not deciding whether to authorize care. This is how Júlia works in the Unicall IVR, in the Sistema Unimed Paraná. In the automated flows, average handling time went from 8 to 2 minutes. In the first month, 12% of calls were fully resolved by the AI.
The problem: the call arrives before the context
At a health plan operator, many calls repeat the same requests: a duplicate payment slip, the status of an authorization request (guia), a pending authorization. When all of them go straight to a representative, the queue grows and the member repeats the same information at every transfer.
Putting a language model in the IVR does not solve this on its own. A voice agent that answers fluently but without reading the system can invent a plausible status. In an authorization lookup, that error reaches the member as if it were official information.
The design has to start from three questions: who is calling, which system answers the request, and what happens when the answer cannot be confirmed.
Traditional IVR × conversational AI IVR
In a traditional IVR, the member navigates a menu of options and, for anything outside it, waits for a representative. In a conversational IVR, the member says what they need in their own words, and the agent recognizes the request and routes it.
The difference is in how the conversation starts. The operation’s rules stay the same: who can look up what, in which system and with which identification. A conversational IVR without integration only recognizes the request; it cannot complete it. That is why designs should be compared by the flows that end with confirmed information, not by how natural the voice sounds.
What a health plan IVR can safely automate, and what it cannot
Good candidates are requests with a clear start and end, a defined data source and an answer that does not depend on judgment. For example: identifying the member with the data the flow requires, sending a duplicate payment slip, looking up and giving the status of an authorization request recorded in the system, and recognizing the request to route it to the right queue.
Deciding whether to authorize care stays outside the agent. Checking the status of an authorization request is different from authorizing a procedure. The decision remains with the operator’s responsible people and processes.
Diagnosis, clinical guidance and clinical or regulatory acts also stay outside. The agent does not assess symptoms or replace a professional’s analysis.
Generating or inferring a status it did not read is not an option. If the lookup does not return confirmed information, there is no answer to give the member. There is a transfer to make.
Requests outside the covered flows go to the right queue. Expanding to new flows depends on new integrations and another validation cycle.
Voice, IVR or chat: which channel for which request
The channel follows the habits of the people who contact the operation and the type of request. Before choosing, check which channel each request arrives through at your operation today. When the phone call is the entry point for requests such as authorization status and payment slips, the IVR is the place for the first flow.
To choose, assess where the request arrives today, whether the answer fits in a spoken sentence or needs a document, link or attachment, and how transfer works in each channel. The identification, lookup and transfer rules in this guide apply to every channel.
Member identification
Identification comes before the transaction. The agent collects and validates the data the operation requires for that flow and only then looks up or sends anything.
Define with the operation which data identifies the member in each flow and where it is validated. Also define what happens when validation is not completed, whether a new attempt, a request for other data or a transfer, and which collected information goes with the call if a person needs to take over.
Without confirmed identification, the agent does not look up or disclose member data. The call goes to human service with what has already been collected.
Status lookup through the source system (grounding)
The status the member hears must be what the source system returned through the API during that call. The model organizes the conversation and the answer. The information comes from the lookup.
The call transcript shows what was said, but it does not prove that the lookup happened. The evidence is the record of the API call and of the source system’s response.
- One source per question
For the status of an authorization request, the source is the operator’s system that records that situation, accessed through the API defined in the project.
- No response, no status
If the API does not respond, returns an error or returns a result the flow does not recognize, the agent does not fill the gap. It says it could not confirm and transfers the call with context.
- A distinguishable record
Monitoring separates a completed lookup, a lookup without confirmation and a transfer. That distinction shows where the flow works and where it needs adjustment or integration.
When to transfer to the team, and with what context
Transfer when identification is not completed, when the lookup does not confirm the information, when the request is outside the covered flows and when the member asks to speak to a person.
Transferring is not sending the call back to the start. The representative receives the identification and the collected information, and the call goes to the queue that fits the request. The goal is to reduce transfers between departments and spare the member from repeating what they already said.
Agree with the team which queues receive each type of request, which information the representative sees at the moment of transfer and how to record the reason: incomplete identification, lookup without confirmation, out-of-scope request or member request. These definitions have a process owner, who decides when to adjust queues, reasons and scope.
A transfer that has started does not confirm that the request was resolved. Also record whether the call reached the queue and was picked up. The interactive voice and IVR example shows a routing with transfer confirmation, in a fictitious scenario.
How to measure without inventing numbers
Define the measure before deployment and compare equivalent conditions.
Same scope. Compare the handling time of the automated flows with the same type of request before the change, not with the average of all calls.
Resolved is not the same as answered. Count as resolved only a call that ended with the request fulfilled and without a transfer. Keep lookups without confirmation and transfers separate.
Declared period and source. Every published number must state the period, the flows included and who measured it.
No baseline, no comparison. When there is no previous measure, the first deliverable is building that baseline. Do not use an estimate as a result.
Where the call data flows
A call with identification goes through telephony, speech recognition and synthesis, the model, the operator’s APIs, recording and dashboards. For each stage, map which data passes through it, where it is processed and stored, who has access and how long the data is retained.
Bring this map to the operator’s data protection officer before the pilot. The guide on Shared SaaS and Dedicated shows how to record requirements, data routes and owners in each deployment option.
Evidence: Unicall / Sistema Unimed Paraná
Júlia was integrated into the Unicall IVR, in the Sistema Unimed Paraná. She identifies the member, sends the duplicate payment slip and looks up the status of authorization requests through the APIs of the operation’s systems. When needed, she transfers the call with context to the right queue.
Results reported in the automated flows. Average handling time went from 8 minutes to 2 minutes, a 75% reduction per call. In the first month of operation, 12% of calls were fully resolved by the AI.
Scope of the numbers. These are indicators of this operation and of the automated flows described. They do not represent all Unicall calls or a guarantee for other contexts. The operation covers a base of 850K members and 18 integrated Unimed cooperatives. The 850K figure describes the member base, not the number of people served by the agent.
Press coverage. Gazeta do Povo reported the delivery of the project in an article published on October 28, 2025. The indicators above come from the case published by Starya.
Frequently asked questions
Can the AI give the status of an authorization request without looking it up in the system? No. The status given must be what the source system returned through the API. If the lookup does not confirm the information, the agent does not answer with an estimate. It transfers the call with context.
Is checking the status of an authorization request the same as authorizing a procedure? No. The lookup reads a recorded situation. The decision on authorizing care remains with the operator’s responsible people and is outside the agent’s scope.
What happens when the lookup API fails? The agent says it could not confirm and transfers the call to the right queue, with the identification and the collected information. The record separates this occurrence from a completed lookup.
What can an AI IVR automate at a health plan operator? Requests with a clear start and end and a defined data source, such as member identification, duplicate payment slips, authorization status lookups and routing to the right queue. Care decisions, clinical guidance and regulatory acts stay with the team.
What results did Unicall report? In the automated flows, average handling time went from 8 to 2 minutes. In the first month, 12% of calls were fully resolved by the AI. These are indicators of that operation and those flows.
Where should another operator start? With one or two flows with a clear start and end, such as duplicate payment slips and authorization status. For each one, define the required identification, the source system, the API and the transfer destination.
Illustrative example · no customer data
Two flows to start a health plan operator’s IVR
Fictitious example: a health plan operator wants to bring two frequent requests to an AI IVR, duplicate payment slips and authorization status. All other calls still go to human service, now with the request recognized and the right queue.
The table shows how each request would be designed before the pilot. Identification, sources and queues are proposals for the example, not the configuration of a real operator or an offer commitment.
| Request | Required identification | Source of the answer | When to transfer and where |
|---|---|---|---|
| Duplicate payment slip | Member data validated in the operator’s records | Payment slip API of the billing system | Incomplete validation or slip not found: billing queue, with the identification and the request |
| Status of an authorization request | Member data validated and the authorization request reference | Lookup API of the system that records the authorization request | Lookup without response or unrecognized result: authorizations queue, with what has already been looked up |
| Coverage question or request for an authorization decision | Member data validated | Outside the agent’s scope; the decision stays with the operator | Always: authorizations queue, with the reason recorded as an out-of-scope request |
| Request outside the covered flows | According to the destination queue | None; the agent only recognizes the request | Always: the queue that fits the request, with the request recognized |
| Member asks to speak to a person | Whatever has already been collected | None | Immediately: general service, with the identification and the call history |
Fill in one row for each request in your operation. A row without a defined source indicates a request the agent can recognize but not complete. A row without a transfer destination indicates a call that may go back to the start of the queue.
When the approach needs to change
If the source system does not yet offer an API for the request, start with recognition and routing to the right queue, and leave the lookup until after the integration. If the required identification cannot be validated by the IVR, keep the flow with a transfer right after the request is recognized. If there is no previous measure of handling time, build that baseline before comparing results.
A point to watch: Judging the IVR by how natural the voice sounds, without checking whether the status given came from the source system.
The worksheet is ready to move forward when…
- Each flow has a defined required identification, source system, API and transfer destination.
- The agent does not give a status it did not read in the source system, and this was tested with failing lookups.
- The record separates a completed lookup, a lookup without confirmation and a transfer, with the reason for each transfer.
- Call data, access and retention were mapped and brought to the operator’s data protection officer.
Bring the flow map to the customer service team and to the owners of the systems. Compare it with the Unicall case and with the guide on handing over to the team before releasing the pilot.
Your worksheet
Complete it with your team.
Record what you know and what still needs confirmation. Answers stay in memory and are not submitted.
References for further reading
- Gazeta do Povo · Article on the delivery of the project for Unimed Paraná ↗
Coverage of the project delivery, published on October 28, 2025 (in Portuguese). The indicators cited in this guide come from the case published by Starya, not from the article.