Unstructured Booking Intake Parser

Freight bookings still arrive as messy artifacts: forwarded emails with free-text instructions, scanned PDF rate confirmations, carrier EDI 204s with sparse segments, and attachments that mix load details with unrelated thread noise. A clerk opens each message, hunts for origin, destination, commodity, weight, equipment, dates, and reference numbers, then re-keys those values into the TMS. That loop is slow, error-prone, and invisible until a bad address or missing hazmat flag surfaces downstream.

An unstructured booking intake parser flips the work. A language model reads the source document or message, maps extractable fields into the TMS booking schema, and leaves blanks blank when evidence is weak. Every populated field carries a source span (the exact phrase or segment that justified the value) and a confidence score. A clerk reviews the draft, corrects what needs correcting, and confirms. The outcome is speed: less time spent hunting and typing, more time spent on exceptions that actually need judgment.

Visibility platforms such as project44 and FourKites excel once a load is live on the road. Booking intake is earlier in the lifecycle. Parsing into MercuryGate or Oracle TMS is about getting a clean order on the books before tracking and exception management begin.

The system treats intake as extraction with provenance, not as free-form generation. Inputs typically include email bodies and headers, PDF BOLs and rate confirmations, and EDI payloads (often 204 / 990 style booking and response traffic). The model is constrained to a fixed field set that matches the TMS booking form: shipper and consignee, pickup and delivery windows, locations, product description, weight and cube, equipment type, service level, special instructions, and customer or PO references.

For each field, the output should include three parts: the proposed value, the character or segment span that supports it, and a confidence estimate. If the email says “pickup Wed 6am–10am at Chicago DC” and the PDF lists a different window, the parser should surface the conflict rather than silently picking one. If weight appears only as “approx 42k,” confidence should drop and the field may stay empty or flag for review instead of inventing a precise number.

Empty fields stay empty by design. Guessing a missing appointment window or inventing a commodity code creates false certainty that is worse than a blank. Clerks already know how to chase missing data; they should not have to undo hallucinated defaults.

Downstream steps still matter. Once booking data is structured, related checks such as hazmat classification or customs pre-clearance document generation can run on consistent inputs instead of scraping the same email twice.

Auto-fill without provenance trains people to distrust the system. When a field is wrong and there is no link back to the source, the clerk re-reads the entire PDF anyway. Source spans reverse that: click or highlight shows the sentence or EDI segment that produced “48' dry van” or “PO 88421.” Review becomes verification, not rediscovery.

Confidence scores set the review budget. High-confidence, single-source fields can pass with a glance. Medium-confidence fields get a quick check against the span. Low-confidence or conflicting fields stay empty or land in an exception queue. That triage is how intake stays fast without pretending the model is a booking clerk.

This pattern also protects auditability. When a customer disputes what was booked, the organization can show which span justified each field at confirmation time, not reconstruct intent from memory weeks later.

MercuryGate and Oracle TMS remain the system of record for the booking itself: orders, tenders, ratings, and execution plans. The intake parser is an upstream assistant that writes candidate field values into those systems (or a staging layer that posts on confirm). It does not replace rating engines, carrier selection, or appointment scheduling.

project44 and FourKites typically enter after the shipment exists and is moving: location events, ETAs, and exception signals. Clean intake helps those products indirectly. Bad addresses, missing equipment codes, or wrong stop sequences create noisy tracking and false alerts. Speeding structured booking reduces the garbage that visibility layers inherit.

In practice, the architecture is simple: ingest channel (email, SFTP for EDI, document upload) → parse and normalize → propose TMS payload with spans and scores → human confirm → create or update the booking in MercuryGate, Oracle TMS, or the carrier-facing tender flow. Visibility subscriptions attach later, once identifiers and stops are reliable.

Rate work is adjacent but separate. After structure exists, teams can compare quotes with an AI rate benchmarking engine or push toward autonomous spot-rate negotiation. Parsing does not negotiate; it removes the re-key bottleneck that delays those steps.

The clerk remains accountable for the booking. The model drafts. That boundary should be explicit in UI and process: no silent auto-post of low-confidence fields, no overwriting confirmed values without a new intake event, and a clear “confirm” action that freezes the accepted field set and stores span/confidence metadata with the booking audit trail.

Training and change management stay light if the UI mirrors the TMS form clerks already know. Highlighting source spans next to each field beats a separate “AI report” pane. Exception queues should group by reason: missing required field, conflicting sources, low confidence, unsupported document type. Measuring success as time-to-confirmed-booking and correction rate per field is more honest than raw extraction accuracy alone.

Edge cases will persist. Multilingual emails, poor scans, nested forwards, and partial EDI will keep some loads in manual mode. The win is shrinking the share of bookings that require full re-key, not eliminating human judgment on ambiguous freight.

Start with one high-volume channel and a narrow field set. Email intake for a single customer segment, or PDF rate confirmations for a lane group, is enough to prove speed gains. Define required versus optional fields up front so empty-optional is allowed and empty-required always queues. Wire confirm into the TMS create-order API you already trust in MercuryGate or Oracle TMS before expanding to more document types.

Instrument field-level correction rates. If “equipment type” is almost always accepted and “delivery appointment” is often rewritten, raise the threshold for appointments or leave them blank more aggressively. Keep visibility integrations (project44, FourKites) out of the pilot until booking identity and stop data are stable; intake quality is the prerequisite, not the afterthought.

The durable result is a booking desk that spends less time typing what the document already said, and more time resolving what the document never said clearly. Structure with provenance, leave gaps visible, and let the clerk own the final yes.