Monitoring AI Claim Status Calls for Home Warranty

A policyholder calls and asks, "Where is my claim?" That one question is the highest-volume call a warranty desk takes. It is also the call where an AI agent has the least room to improvise. The answer already exists in your claims system. The agent's job is to retrieve it, translate it, and not add anything.

This post is about home warranty claim status AI on a claim that already exists. It is not about whether a failure is covered. For coverage decisions, see our post on wrong coverage calls. Here we cover the status record, how speech errors corrupt it, and how to test and monitor the agent. It is written for teams that built the agent themselves. It may serve their own claims desk or the warranty companies on their platform.

What a status call actually asks the agent to do

Claim status calls look like small talk. It is really a read from a claims system, followed by a translation into speech. The caller wants one of six things.

1. Has my claim been received and is it open?

2. Has someone approved it, or is it still under review?

3. Which contractor is assigned? This is the technician assignment question.

4. When will they arrive?

5. Why was it denied or delayed? This is the claim denial question.

6. What do I do next?

Each answer maps to a field. Some fields are clean, like a claim ID. Others are fuzzy, like "authorization pending." The fuzzy ones are where agents go wrong, because the caller hears a promise in them.

Public status vocabularies are simple. One provider's glossary describes five labels: submitted, under review, approved, denied and resolved. It says review "can take anywhere from a few hours to a few days" (Liberty HomeGuard glossary). Your internal states are almost certainly finer. A real claim may sit in "awaiting authorization," "dispatched to network contractor," "contractor accepted," "parts on order" or "cash-out offered." Your agent has to turn each into a sentence a stressed homeowner can act on.

The FTC flags the stakes in plain language. Consumers should ask: "Does the claims process seem difficult or slow?" It adds that "waiting a long time to get paid back can reduce the value of having coverage" (FTC Military Consumer blog, March 2023). A status call is where that slowness becomes audible. A wrong answer makes the wait feel worse.

Any home warranty AI voice agent that answers these calls inherits the same six questions. Teams that run a check home warranty claim status line, with or without AI, see the same pattern in their repeat calls. A good home warranty claim status AI treats the record as the only script.

Why this is not a coverage-call problem

Coverage calls ask the agent to apply policy language. Status calls ask it to report state. The failure modes differ.

For the neighbouring problem, scheduling a service visit, see voice agent testing for appointment scheduling. For the wider home services picture, see our home services receptionist QA guide.

Where speech errors corrupt a status answer

Every status answer passes through five steps. Each can fail without raising an alert.

1. Identify the claim. The caller gives a claim number, a phone number or an address.

2. Verify the caller. The agent checks they may hear this record.

3. Retrieve the record. The agent queries the claims system.

4. Translate to speech. The agent turns fields into sentences.

5. Write back. The agent logs the call and any promise made.

Most teams test step 4. The damage usually happens in steps 1 and 5.

Step 1: the wrong claim, read perfectly

A policyholder with a water heater claim and an open HVAC claim says, "It is about my heater." The agent may pick the HVAC claim. It then reads that record flawlessly. Every sentence is faithful to the record, and the call is still wrong. A transcript check passes it.

Digits are the other source. One vendor's English voice-agent benchmark reports an entity error rate of 14.4% for its best model against a 5.19% word error rate. It also reports 10.0% on alphanumeric codes and 18.6% on dates for that model (AssemblyAI, September 30, 2026). This is a vendor benchmark on scripted scenarios, so treat it as a warning and not a forecast. The lesson is that low word error does not mean correct claim numbers. A claim ID with one wrong digit can match a different policyholder's record. That is a privacy problem as well as an accuracy problem.

Step 3: stale or partial reads

Claims systems often update asynchronously. A contractor accepts a job in a dispatch tool, and the claims record catches up minutes later. If the agent reads the claims record, it says "not yet assigned" while the technician is already driving. If it reads dispatch, it may say "assigned" before authorization clears. Decide which system is authoritative for each field. Test the lag.

Step 4: label mistranslation

This is the classic status-call bug. The agent compresses an internal state into friendlier words and changes the meaning.

"Authorization pending" is the sharp example. A caller hears "approved" in anything that sounds forward-moving. If the agent says "we are processing your approval," the caller reads it as a yes. Then the claim is denied, and the caller feels lied to.

Step 4 again: invented ETAs

When a field is empty, language models fill the gap. The caller asks "when is the tech coming?" The record has no appointment. A fluent agent says "usually within 24 to 48 hours." Where did that number come from? Possibly your FAQ, possibly the model's general knowledge. It is now a promise on a recorded line. Any time window the agent speaks must trace to an appointment field or an approved policy statement.

Step 5: the promise nobody logged

The agent says, "I will have a supervisor call you back today." Nothing writes a task. The caller waits, then calls again and gets a different agent with no memory of the promise. Repeat calls are the most visible cost of this. Your own repeat-call rate is the best signal that status answers are failing. It is also the cheapest form of home warranty claim tracking you already have.

A copyable framework: the claim-sentence ledger

The hard part of testing status calls is deciding what counts as correct. A whole call can be "mostly right." We recommend grading each spoken sentence about the claim instead. Put every such sentence in one of four classes.

Claim-sentence ledger: a per-call grading method that sorts each claim-related sentence the agent speaks into Read, Derived, Promise or Unsupported. Read and Derived must match the record. Promise must create a logged task. Unsupported must be zero.

Two numbers come out of this. Status fidelity is the share of Read and Derived sentences that match the record. Promise capture is the share of promises with a logged task. Unsupported sentences are counted per hundred calls and the target is zero.

Here is a simplified checker. It assumes you already extract claim sentences and tag them. Field names are examples.

# Simplified. Assumes sentences are already extracted and tagged.
from dataclasses import dataclass

@dataclass
class Sentence:
    cls: str           # "read" | "derived" | "promise" | "unsupported"
    field: str | None  # record field the sentence cites, if any
    spoken_value: str | None

def grade_call(record: dict, sentences: list[Sentence], tasks: list[dict]):
    failures = []
    for s in sentences:
        if s.cls == "read":
            if str(record.get(s.field)) != s.spoken_value:
                failures.append(("read_mismatch", s.field, s.spoken_value))
        elif s.cls == "derived":
            if s.field not in record:
                failures.append(("derived_without_source", s.field, None))
        elif s.cls == "promise":
            if not tasks:
                failures.append(("promise_not_logged", None, None))
        elif s.cls == "unsupported":
            failures.append(("unsupported_claim", None, s.spoken_value))
    return failures

Extraction and tagging is the hard part, and it is where an LLM judge helps. Evalgent judges calls from the audio, not only the transcript, because a transcript can already carry the speech-to-text error.

Compliance and caution points

Status calls are mostly informational, but three rules still touch them.

First, state regulation varies. Home warranties are generally treated as service contracts, and some states place them under insurance or licensing authorities (ConsumerAffairs overview). Florida, for example, covers home warranty agreements in Chapter 634 and sets required contract provisions in Fla. Stat. 634.312. The ConsumerAffairs overview gives no universal claim-response deadlines. Check the rules in each state where you operate.

Second, outbound status callbacks use an AI voice. The FCC ruled in FCC 24-17, released February 8, 2024, that AI-generated voices are "artificial" under the TCPA. Calls using them need prior express consent (Mayer Brown summary). In FCC 26-67, adopted September 30 and released October 1, 2026, the FCC narrowed "revoke-all" for informational calls and let callers name exclusive opt-out methods. It takes effect 30 days after Federal Register publication (Kelley Drye, Nixon Peabody). As of October 2026 it was not yet in effect. This is not legal advice. Have counsel confirm how it applies to your callbacks.

Third, caller verification. A status answer discloses claim details and the service address. If a mistyped claim number retrieves another household's record, you have a disclosure incident. Test verification before you test anything else. Our guide to regulated voice agent policy test cases has a starting list.

How to test a claim status agent before each release

You need scenarios that cover record states, caller behaviour and speech conditions. Evalgent generates test scenarios from an agent's prompt and flows, covering states, branches, policies and hard constraints, and runs them with caller profiles for accent, pace, interruption, noise and language. Whatever tool you use, the structure below holds for home warranty claim status AI.

1. List your record states. Write every claim state your system can hold, and every field that may be empty. Aim for 15 to 25 states, including edge states like "reopened" and "duplicate."

2. Write the safe sentence for each state. For every state, write what the agent may say and what it must never say. The mapping figure above is the template.

3. Build a record fixture per state. Use test claims that mimic real records, including a caller with two open claims and a caller whose claim is empty of dates.

4. Add caller conditions. Vary accent, pace, interruptions, background noise and claim-number delivery ("four seven two one" vs "forty-seven twenty-one"). See voice agent accent robustness.

5. Place test calls and grade by ledger. For each call compute status fidelity, promise capture and unsupported count. Include a check that the right claim was retrieved.

6. Gate the release. Block shipping if any wrong-claim retrieval or unsupported sentence appears. Compare fidelity against the last release.

How many calls is enough

If you see zero failures in n independent calls, the 95% upper bound on the true failure rate is about 3 divided by n. This is the "rule of three," derived from solving (1 − p)^n = 0.05.

Worked example, with illustrative numbers. Say you want to show that wrong-claim retrieval is below 1%. You need about 300 clean calls. If you want below 0.5%, you need about 600. These counts apply per cell you care about. If the agent serves five warranty companies with different record shapes, the clean-call target applies to each. Our multi-tenant testing guide covers that split.

Test calls are cheap compared with a live-caller failure. Still, 300 calls per tenant is a lot to place by hand. That is the case for automated simulation over phone, SIP or WebRTC.

Monitoring live status calls

Pre-release tests cover what you thought of. Live calls show what callers actually do. Monitoring needs three layers.

Per-call scoring. Run the ledger on every recorded call, or a stratified sample. Evalgent's production monitoring takes pushed call recordings, transcribes them, maps each to a scenario and judges it, flagging tool-call failures, policy failures, PII leakage and latency spikes with fix recommendations. Custom metrics, such as unsupported-sentence count, run on every call.

Lead indicators from your own data. Watch these weekly.

Change review. Re-run the full scenario set after any prompt change, model swap or claims-system schema change. Teams often update the system and forget the agent reads it. Our go-live checklist lists the pre-ship gates.

For the broader practice, see how to monitor voice agents in production.

Edge cases worth a dedicated test

• Two claims, one policy. The caller says "my claim" with no detail. The agent should ask which one.
• Denial phrasing. The agent may state the recorded reason and the next step. It must not argue coverage. Hand coverage disputes to a human or to a coverage workflow.
• Cash-out offers. If a claim is in a cash-out state, the amount must be read exactly or not at all.
• Rescheduled appointments. The agent must read the new window, not the one in an earlier confirmation text.
• Emotional callers. A caller without heat or hot water on day three is angry. Test whether the agent escalates on rule, not on tone alone.
• Third-party callers. A tenant or adult child calls for the policyholder. Verification must handle this case.
• Contractor calls. The line may also receive calls from the contractor. Intent detection must separate them.

Similar contractor mix-ups appear in HVAC scheduling and plumbing booking agents, and the same fixtures often transfer.

What we left out

We did not find a public source giving average home warranty claim resolution times or a regulator-set status-call deadline. So this post gives no industry benchmark for how long a claim takes. Use your own claim timestamps instead. The first baseline to build is your own median time from authorization to technician visit.

Frequently asked questions

How do I check my home warranty claim status by phone?

Call the number on your contract and give your claim or service request number. A human or AI agent then reads the status from the claims record. If an AI agent answers, check that it repeats your claim number back. Ask what the status means in terms of your next step, and write down any promise made.

Can an AI agent give accurate home warranty claim status?

Yes, if it reads one verified claim record and says only what that record supports. Accuracy breaks in four places: the wrong claim is retrieved, an internal label is paraphrased into something stronger, an empty field gets an invented ETA, or a promise is never logged. Sentence-level grading against the record catches all four.

Why does my home warranty claim say pending authorization?

It usually means the claim was filed but the company has not yet approved the repair cost or visit. It is not an approval. One provider describes review as taking "a few hours to a few days," depending on complexity. An agent should say it is waiting on authorization and name the next step.

How long does a home warranty claim take to get a technician?

It depends on the contract, the company, the trade and contractor availability. We found no public benchmark worth quoting. The FTC advises consumers to ask whether the claims process seems slow. A good agent reads the actual appointment field and never quotes a generic time window.

What should an AI say when a home warranty claim is denied?

It should state the recorded denial reason, confirm any appeal or review path in policy, and offer a human handoff. It should not argue coverage or soften the outcome. Paraphrasing a denial into a maybe causes complaints. Test denial states with frustrated callers and verify the exact wording against approved text.

How do you test an AI home warranty claim status agent?

List every claim state, write the safe sentence for each, and build a record fixture per state. Run calls with varied accents, noise and claim-number phrasing. Grade each spoken sentence as Read, Derived, Promise or Unsupported. Block a release on any wrong-claim retrieval or unsupported sentence.

How many test calls do you need to trust a claim status agent?

Zero failures in 300 independent calls bounds the true failure rate near 1% at 95% confidence, from the rule of three (3 divided by n). For 0.5%, you need about 600. Run that count for each tenant or claim-record shape, because pooling can hide a failing cell.

Do TCPA rules apply to AI claim status callbacks?

Often yes. In FCC 24-17 (released February 8, 2024), the FCC held that AI-generated voices are "artificial" under the TCPA, so calls using them need prior express consent. FCC 26-67 (adopted September 30, 2026) changes revocation rules for informational calls but was not yet in effect as of October 2026. This is not legal advice.

The bottom line

Claim status calls are a read-and-translate task, so the agent should say only what the claim record supports. Grade every spoken sentence against that record, monitor live calls for wrong-claim reads and unlogged promises, and gate each release on those results.