Airline Complaint Digitization: Handwritten Forms and Web Intake to Zendesk with OCR and GPT-4

A note on timing: this is a proof of concept we built in September 2023, in the first year of GPT-4, and we present it as a dated snapshot rather than a current recommendation. The architecture lessons still hold; the tooling has moved on considerably, and the final section covers how we would build the same pipeline today.

Challenge: When an airline mishandles a bag, the passenger files a written complaint. Under the Montreal Convention, that written complaint is not optional paperwork: it must be filed within seven days for damaged baggage and 21 days for delayed baggage, or the claim lapses. So every airport keeps a stack of paper complaint forms at the baggage service desk, and passengers fill them in by hand, often in a hurry, often upset. (Treaty-mandated paper has shaped aviation processes for a century; we unpack that lineage in why airline IT looks the way it does.)

The carrier's complaint intake had two channels, and both leaked time and data:

• Paper forms at the airport. Handwritten complaints were collected at the desk, then someone at headquarters read each form and re-typed it into the service system. Handwriting from a stressed passenger who just lost a suitcase is not calligraphy. Transcription was slow, error-prone, and unsearchable until someone got around to keying it in.
• Online complaints arriving as email. Web submissions landed in operator mailboxes, where legacy email clients struggled to display attached photos and documents, and finding a specific complaint later meant scrolling and guessing search terms. The attachments passengers sent as evidence (the bag tag, the boarding pass, photos of the damage) were the hardest part to work with.

None of this is unusual. The industry mishandled 4.9 bags per 1,000 passengers in 2025, and mishandling still costs airlines an estimated $6.3 billion a year according to SITA's Baggage IT Insights. Every one of those bags generates a written complaint that someone has to read, classify, and act on.

We built and demonstrated a working proof of concept: one pipeline where paper and web complaints converge into the same structured Zendesk ticket stream, with the original documents attached and searchable.

Solution

The design principle was convergence: no matter how a complaint enters, typed into a web form or scribbled on paper at the airport, it should exit as the same structured ticket, in the same queue, with the same fields and the same audit trail.

Step 1: A Structured Front Door for Digital Complaints

We replaced the email-based intake with web forms rendered inside the carrier's own site design, pixel-faithful to the production pages, so the demo looked native from the first click.

The forms collect what a baggage agent actually needs to resolve a claim. The baggage complaint form requires a photo of the bag tag and the boarding pass, the two artifacts every downstream tracing process depends on. The flight complaint form captures the full context: flight number, route from a dropdown of the carrier's real destinations, travel date, loyalty tier, and a complaint category matching the airline's official taxonomy. The full GDPR consent text and data-protection contacts were carried over intact.

Because submissions become structured tickets instead of emails, there is nothing for an outdated mail client to garble: attachments are stored on the ticket, and every field is searchable.

Step 2: Read the Paper with OCR

Scanned paper forms enter through a back-office processing screen. The scanned PDF goes to AWS Textract, which handles both the printed portions of the form and the handwriting. We deliberately pinned Textract to an EU region, since these documents carry passenger personal data under GDPR.

A separate OCR stage was not an aesthetic choice. In September 2023, GPT-4 could not yet accept images through the API, so a dedicated OCR service had to turn pixels into text before the language model could reason about it. That constraint no longer exists, which is the single biggest thing we would change today (see the final section).

We did no image preprocessing and built no zonal templates. That was a conscious architecture decision, and it is what made the next step interesting.

Step 3: GPT-4 as the Semantic Parser

Classic form digitization maps field positions on the page: zone coordinates, regex, fuzzy matching. It breaks the moment the form layout changes or the handwriting drifts outside its box.

Instead, we flattened Textract's output into plain text and handed it to GPT-4 with a domain-specific prompt written in the carrier's language. The prompt:

• warns the model that the source is handwritten and the OCR output contains spelling, spacing, and formatting errors, and instructs it to correct them;
• maps the text onto the form's ten fields, using the bilingual field labels printed on the physical form as anchors;
• classifies the complaint into the airline's eight official complaint categories, inferring the ticked checkbox from the narrative, because OCR reads a checkbox row as an undifferentiated list of options;
• returns strict JSON, with an empty string for anything genuinely missing, and a literal "cannot be understood" marker when a passage is illegible, a guard against the model inventing a complaint the passenger never made.

A retry loop re-queries the model if the JSON does not parse, so the endpoint always returns a well-formed result. We built this in September 2023, six months after GPT-4 shipped and before structured outputs, JSON mode, and extraction frameworks made this pattern standard. The real sample forms justified every guard: one test document's OCR came back as mangled fragments of Romanian handwriting that no regex would ever have parsed, yet the model correctly recovered the flight number, date, airport, and the substance of the complaint.

Step 4: A Human Confirms Before Anything Is Written

The extracted fields never create a ticket on their own. They pre-populate an editable review form, and an operator corrects and confirms before submission. Illegible or missing values arrive clearly marked rather than silently guessed.

The operator's confirmation posts to the same endpoint the public web form uses: paper and digital complaints share one code path, one validation layer, and one ticket format. The original scanned PDF rides along as a ticket attachment, so the audit trail always leads back to the physical document the passenger signed.

Step 5: Zendesk as the Single System of Record

We integrated rather than rebuilt. No database, no file store, no custom email sender: Zendesk holds the tickets, the attachments, the passenger contact record, and the status workflow:

• Each passenger is auto-created as a Zendesk requester, so acknowledgment and follow-up emails ride Zendesk's native notification thread.
• Tickets are tagged by complaint type (baggage vs. flight), giving operators filtered queues instead of a shared mailbox.
• A status API validates transitions through Zendesk's ticket lifecycle, and a resolution-time metric over closed tickets sketched the beginnings of an operations dashboard.
• The passenger leaves the confirmation page with a real ticket number they can reference, a level of transparency the email process never offered.

Results

This was a proof of concept, built to demonstrate the approach end-to-end. It was not taken to production, and we present it as what it is. But the demo closed the full loop, on real documents:

• A complete working pipeline from both intake channels to live Zendesk tickets, built in roughly ten days by two engineers, in about 350 lines of Python.
• Real handwritten complaint forms, including genuinely degraded handwriting, were scanned, extracted, corrected, and turned into structured tickets with the source PDF attached.
• Paper and web complaints converged into a single searchable queue with visible attachments, replacing both the manual keying-in and the email-client bottleneck.

Key Takeaways

The LLM is the parser. Zonal OCR templates assume tidy handwriting inside printed boxes; distressed passengers do not cooperate. Treating extraction as a language problem (correct the errors, find the fields by meaning, infer the category from the narrative) is what made messy real-world forms processable. In 2023 this was a bet; it has since become the standard pattern for document intake.

Converge channels on one code path. The back-office OCR screen submits through the same endpoint as the public web form. One validation layer, one ticket schema, one queue, and no second system for paper complaints to drift out of sync in.

AI accelerates, humans confirm. In a consumer-rights process governed by the Montreal Convention and GDPR, the model's job is to eliminate typing, not judgment. Mandatory review, explicit "cannot be understood" markers instead of guesses, and the signed original attached to every ticket kept the automation honest. Three years later, this same human-gate discipline turns out to be the common denominator of every AI travel agent that actually transacts in production; see our survey of live deployments.

Delegate to the system of record. Letting Zendesk own storage, notifications, and workflow meant the entire solution stayed small enough to build in days and simple enough to hand over without an operations manual.

What We Would Build Differently Today

The 2023 design holds up architecturally, but three years of tooling would simplify almost every stage:

• One model instead of two stages. The only reason we ran OCR and GPT-4 separately was that GPT-4 had no vision capability at the time. Today we would send the scanned form directly to a vision model like GPT-5.6 Luna, which reads the page, corrects itself, and extracts the fields in a single call, at a small fraction of GPT-4's 2023 price, with better accuracy and a far simpler integration: no separate OCR service, no text flattening, one less failure point.
• Structured outputs with schema enforcement instead of a JSON retry loop.
• Confidence scores surfaced per field, so operators review the uncertain values first instead of re-reading everything.
• Multilingual extraction as a first-class feature: the same pipeline covers every language the airline serves by changing the prompt, not the code.
• An agent layer over the ticket queue: deduplicating repeat complaints, matching baggage claims to flight-disruption data, and drafting responses for operator approval, using the same investigate-then-confirm pattern we later shipped in production order-entry automation.

Technologies and Tools

Python, FastAPI, AWS Textract, OpenAI GPT-4, Zendesk API, Jinja2, Bootstrap, Docker