Warranty claim triage inside the OEM SLA

The problem

OEM warranty claims are triaged by hand; 40% of the claims engineer's time goes to translating CS / DE / EN PDFs. Cases close in 18 days against a 10-day OEM SLA — a daily 0.5% penalty on the running volume. Repeat defects are solved from scratch because the team has no institutional memory beyond SharePoint folders that are named however each engineer felt that quarter.

What we'd ship

An Azure OpenAI claim-triage copilot pulls the PDF straight from Outlook, translates it, extracts defect codes, and surfaces similar historical cases from SAP QM and SharePoint. The engineer keeps working inside Outlook — we wire everything through an MCP server over the existing M365 + Azure footprint, honouring the "Microsoft first" rule. Every draft reply cites its source document so the human review step actually means something.

Stack

• Azure OpenAI (GPT-4o) for extraction + reply drafting
• Azure AI Translator for CS / DE / EN
• Azure AI Document Intelligence for structured OEM PDFs
• MCP server wrapping SAP QM + SharePoint search
• Outlook add-in (Microsoft 365) as the engineer's only surface

Guardrails & compliance

• Full audit trail to ISO 9001 + IATF 16949 — every AI-drafted reply is human-reviewed before send
• Source citations pinned to the original OEM PDF on every suggestion
• No custom UI — stays within M365 per the customer's "Microsoft first" rule
• GDPR: personal names in claim PDFs masked before model prompting

Typical timeline

1. Week 0–2 Data-contract + access

   Inventory OEM portals, set up PDF intake, agree on SharePoint taxonomy for historical cases, review audit-log requirements with quality.

2. Week 2–6 Pilot on one OEM, one claim type

   Ship the Outlook add-in to two engineers, measure triage time and reply quality against current baseline, iterate on prompt + retrieval.

3. Week 6–12 Rollout across all three OEMs

   Expand to the full claims team, hook SAP QM reads for full historical lookup, close the loop on ISO/IATF audit evidence.