Enterprise exception resolution for freight waybilling
Norfolk Southern’s revenue-waybilling clerks investigated shipment requests that failed automated validation on a decades-old green-screen mainframe. Over a Fjord engagement, I led the design of a cloud-native concept that turned isolated EDI and waybill errors into a prioritized worklist, a shipment-level investigation view, and live reporting.
Role
UX Lead
Client
Norfolk Southern
Agency
Fjord
Platform
Enterprise web
When
2019 · cloud-native concept
Request overview · Acceptance, rejection, and manual intervention Revenue waybilling operations · Web concept
The 60-second version
A rail “order” is not one record. Customer shipping instructions, interline EDI, the internal waybill, route and rating data, equipment movement, and revenue accounting all have to agree. When they did not, the transaction entered suspense for a clerk to resolve. The challenge was: how do you make that investigation faster and safer without flattening away the rules the railroad depends on?
The green screen was not simply an old order-entry form. It was a waybilling investigation console: work queues, 404 and 417 suspense, waybill inquiry, route and rating data, lading, car movement, comments, turnover, and controlled lifecycle actions such as voiding.
Clerks correlated serial numbers, waybills, equipment IDs, customers, routes, and error messages to reconstruct what the shipper or another railroad intended. Leadership needed the aggregate view: where work was aging, which errors repeated, and how much intervention each customer required.
The queue exposed the failed transaction, but understanding and resolving it meant navigating coded screens, reference data, comments, and related waybill records.
Group errors by shipment request, make route and validation problems actionable, preserve history, and expose queue patterns from the same product.
The insight that drove every screen
A readable EDI message could still fail a business rule. The clerk then had to connect the inbound transaction to the local waybill, equipment, parties, route, lading, and comments; decide whether the issue was safe to fix or required another owner; and confirm that reprocessing completed. The interface had to expose that chain, not merely render the same fields in a browser.
1Make dependencies visible
Bring request identity, errors, route, commodity, history, and customer context together so the clerk can see why the transaction stopped and what else the correction may affect.
Instead of making the user correlate the same shipment across isolated screens and identifiers.
2Make actions safe
An obvious correction, a route change, a customer response, and a waybill void are not equivalent actions. The interface needed to preserve ownership and consequence while making the next step clear.
Instead of collapsing every resolution into an ambiguous update button.
Discovery connected two levels of the same operation. Revenue-waybilling clerks needed to know why a request failed, who could act, and whether reprocessing succeeded. Supervisors needed to know where work was aging, which errors repeated, and where manual intervention was becoming systemic.
Landscape audit
Field observation, workflow mapping, and the legacy screens revealed three gaps that mattered more than the age of the interface itself.
Source transaction, serial number, waybill, equipment, customer, route, and comments described the same case but lived in different views.
A code or message said what rule failed, but not always who owned the correction, what it affected, or which action was authorized.
Updating a record was not the end of the job. Clerks still had to know whether the transaction reprocessed and downstream records accepted it.
The current state · legacy terminals
The legacy environment was a forensic console, not a generic order form: work queues, waybill inquiry, route and lading data, corrections, comments, voids, and shift turnover. These 2019 QA screens document the workflow and domain model, not Norfolk Southern’s current production architecture.
Status quo vs. what we designed
The opportunity was to organize the experience around the exception case while preserving the distinctions and controls embedded in the waybilling system.
The queue, inbound transaction, local waybill, route, lading, comments, and activity history had to be correlated through navigation and institutional knowledge.
Clerks see grouped errors, editable route and request data, history, and customer context; leadership sees intervention volume and recurring patterns.
Two mindsets
Research required different methods for each group, because they needed different truths from the same platform.
Target A
Target B
Into the work environment
Clerks were observed using the terminal under real working conditions. Workflow maps separated ABOL and Error Queue responsibilities, while stakeholder interviews captured the operational reporting the mainframe could not provide.
One queue item exposed the real job
An inbound 417 from CN for equipment FBOX 506330 contained a readable waybill, customer, commodity, destination, and route. It still stopped because a junction was required between NS and CFE.
The transaction was syntactically readable. A routing rule prevented the interline waybill from being safely accepted.
Compare the inbound 417 with the local record, inspect route and junction data, decide who can correct it, reprocess, document the decision, and verify acceptance.
The queue item was only the beginning. The product had to assemble the investigation and make the next safe action clear.
Previous pattern · Cross-record reconciliation · Expertise carried in navigation and memory
The core experience followed the lifecycle of an exception: an inbound transaction fails validation, a clerk correlates it with the railroad’s records, an authorized correction or escalation occurs, and the result must be reprocessed and verified.
A failed customer 404 or interline 417 enters a suspense or error queue. Source, age, customer, equipment, route, and errors determine priority.
Compare inbound and local records, inspect the failed rule, and determine whether the clerk can fix, must escalate, or needs an external response.
Apply the authorized outcome, preserve an audit trail, confirm downstream acceptance, and leave a complete handoff if work remains.
Design principles
We borrowed the useful parts of ticketing, CRM, and task-management products, then adapted them to the controls and record relationships of rail waybilling.
Case model
Organize errors, route, request data, history, and customer context around the shipment request being investigated.
Validation
Translate coded errors into the affected field, the validation problem, and the operational or revenue consequence.
Authority
Make ownership and authority explicit instead of presenting every exception as a locally editable field.
Workflow
Use familiar tables, forms, history, and keyboard-friendly interactions without hiding the domain detail experienced clerks rely on.
Information architecture
Before screen design, a site map separated request-level investigation from aggregate reporting while keeping both grounded in the same processing data.
Site map. A request worklist and investigation path for clerks, with team and customer reporting for supervisors.
Concept wireframes
Four screens covered the processing lifecycle before visual design: request overview, exception worklist, shipment-request detail, and customer reporting.
Request Overview
Exception Worklist
Shipment Request Detail
Customer Reporting
The platform could not pull from the additional 12+ reference, inquiry, and legacy systems clerks used during investigation. Improvements had to work inside real data limits.
Assemble the strongest case view the available data allowed, and leave clear seams to the systems that remained outside it.
A typo, a route change, a customer correction, a hazardous-material issue, and a waybill void carry different consequences and may require different owners.
Make common work easier without implying that every field is safe for every clerk to change.
The concept grouped work by shipment request rather than isolated error records. It combined a processing overview, a filterable worklist, request-level correction and history, and customer reporting—while retaining the route, commodity, lading, and identifier detail the job requires.
Overview
Accepted, rejected, auto-fixed, and manually edited requests create a live processing picture, with error volume broken down by time and type.
Worklist
Open, high-priority, and long-suspended requests sit in one filterable queue with sender, serial, origin, destination, errors, stage, and age.
Request detail
Grouped validation errors sit beside request data, commodity details, an editable route, comments, updates, and versions so the case can be understood in one place.
Reports
Customer reporting separates accepted, auto-fixed, and manually edited work so recurring data-quality problems become visible beyond a single queue item.
From sketch to structure
Early ideation mapped request intake, validation, investigation, correction, history, and reporting into a coherent product structure before visual design locked the brand language.
High-fidelity screens
What I would strengthen now
The 2019 concept established the right case-management direction. With a fuller understanding of revenue-waybilling, I would make four parts of the investigation more explicit.
Identity
Place source 404/417, originating railroad, serial number, waybill, BOL, equipment, and customer reference together so “shipment number” is never ambiguous.
Comparison
Expose field-level differences between the inbound transaction and local record, including the rule, authoritative source, and downstream consequence.
Action model
Decompose “Delete” and “Force Update” into correction, reprocess, request customer action, send back, void, escalate, and turnover paths with clear authority.
Operational context
Add time in suspense, equipment location, movement and hold status, cutoff, and HazMat or special-load indicators, then verify downstream acceptance after reprocessing.
The bar for modernization
‘Safe, measurable resolution.’
Outcome · Concept · handed off at design
A Fjord engagement researched and designed end to end, then handed to Norfolk Southern as a high-fidelity concept for implementation.
The most meaningful measures for the concept:
Resolution speed
Time in suspense
Measure median time from failed validation to an authorized, documented resolution, including the share of requests aging beyond 24 and 48 hours.
Resolution quality
First-pass completion
Track whether a corrected transaction is accepted downstream without repeat failure, duplication, or additional manual rework.
Operational health
Queue health
Monitor backlog, aging, intervention rate, repeat errors by customer or railroad, and handoff completeness across shifts.
The reframe: the product was not replacing an order form; it was supporting a controlled investigation across commercial, operational, and revenue records. The strongest modernization makes that work faster, safer, and verifiable.