Case Study

a leading commercial foodservice equipment manufacturer

Technician support and warranty claims AI.

Two related systems shipped in sequence: first a technician assistant grounded in service documentation, then a claims workbench that recommends outcomes with reasons, confidence, and human review.

RAGAI AgentsAWSCRM IntegrationFixed-Scope Delivery

Abstract workflow showing records, review steps, and approved decisions

The Challenge

Fast answers and consistent claims review, inside the tools teams already used.

Field technicians needed fast, accurate answers from dense service documentation. Manual lookup was slow, uneven, and hard to keep consistent across the field.

Warranty claims review had a similar problem. Incoming claims took human time, outcomes could vary by reviewer, and repeated decisions created fatigue.

A leading commercial foodservice equipment manufacturer needed production systems, not a demo. The work had to fit into the existing support environment and move without a long consulting program.

What We Built

Two systems, shipped in sequence.

System 1

Technician Support Assistant

Field technicians could ask natural-language diagnostic questions and get answers grounded in the manufacturer's own service manuals and documentation.

The system ran on a serverless AWS architecture. A submitted question entered a queue, a worker retrieved relevant manual context from a vector knowledge base, and an LLM generated a grounded answer.

The assistant was integrated into the existing CRM/support platform, so technicians did not need to learn a disconnected tool.

Amazon BedrockVector knowledge baseQueued worker flowGrounded answers

System 2

Warranty Claims Intelligence

The second system evaluated incoming warranty claims and recommended Approve, Deny, or Investigate.

Each recommendation included High, Medium, or Low confidence plus written reasoning. It was designed for review, not blind automation.

The system compared each claim with device error history and similar past claims using Aurora Serverless with pgvector as a precedent store.

Approve, Deny, InvestigateConfidence scoringAurora Serverlesspgvector precedent store

Question or claim

Submitted inside the existing support platform

Queue

Work is routed without blocking the user experience

Context

Manuals, device history, and past claim precedent are retrieved

Model

Amazon Bedrock generates an answer or recommendation

Workbench

Humans review, confirm, or override with a reason

Human Review

AI recommends. People decide. The system learns.

The claims workbench was designed to build trust. Reviewers see the recommendation, confidence level, and written reasoning before they act.

Confidence is visible

Every recommendation is marked High, Medium, or Low, so reviewers know where to apply more judgment.

Bulk review stays controlled

Reviewers can confirm recommendations they agree with in batches, but overrides require a documented reason.

Overrides improve the system

Every override is logged and fed back into the precedent layer, so future reviews reflect real human judgment.

Rollout was reversible

Feature flags, smoke tests, and rollback notes kept the live technician assistant protected during the second launch.

Results

Practical numbers, not inflated claims.

5-12 sec

Typical claim evaluation time once the claim enters the AI review flow.

$0.01-$0.03

Approximate AI cost per claim evaluation, depending on claim size and context.

Full audit trail

Every recommendation, confidence level, reason, and override is recorded.

Zero disruption

The claims system shipped as an additive layer beside the live technician assistant.

What We'd Flag For Anyone Doing Similar Work

A few things worth knowing before you scope something similar.

Ship the smaller system first

The technician assistant alone was worth shipping on its own. Treating it as a standalone win, not just a stepping stone to the claims system, made the second project easier to sell internally.

Precedent data needs a real owner

The pgvector precedent store is only as good as the claims fed into it. Someone on the client side had to be responsible for flagging bad precedent early, or the system would have learned from its own mistakes.

Confidence scores need calibration time

Early High and Medium confidence thresholds were adjusted twice in the first month, once reviewers had real cases to react to. Plan for that adjustment period instead of treating the first version as final.

Why It Matters

This is the kind of AI work that survives contact with the real business.

The value was not a model in isolation. It was a focused build that fit inside real support work, gave people reasons they could review, and improved from every override.

Talk to us about your use case