Connecting field work, approval, and reconciliation

Executive summary. Field Ticket was a field-work management problem, not simply a paper-to-digital conversion. I led the design of a mobile and web workflow connecting service capture, approval, evidence, and reconciliation across four roles and multiple organizations. The existing paper process averaged 22 days between work being performed and an invoice being received. The design made ticket state and responsibility visible from field capture through approval and reconciliation.

Paper delayed payment by 22 days

A field ticket records what a service company did at a well site: hours, equipment, materials. For decades it was a paper form filled in on site, then carried around while the supplier tracked down a supervisor who could sign it.

Every step of that leaks. Handwriting gets misread. Tickets get lost. Data entry introduces errors nobody catches until reconciliation. Oildex measured the gap between a service being performed and an invoice arriving at 22 days on average, which means budget decisions get made against numbers three weeks stale, and the service company waits that much longer to be paid.

Paper persisted for structural reasons. ↘Go down the rabbit holeWhy the form survived

Complex well-site services account for roughly 80% of what these operators spend. The paper ticket sat in front of nearly all of it.

One ticket connected four disconnected roles

The workflow spans four roles with almost nothing in common who rarely speak.

John, field services rep, supplier side. Commission-based, long hours driving, repairs and maintenance in harsh conditions. He writes the ticket, then has to find someone to sign it.

Ken, well site manager, buyer side. Runs safety and efficiency under real pressure, and earned the role through field experience rather than formal education. Ticket management is administrative work sitting on top of more urgent responsibilities. He is the hardest user to win, because the system asks for time he does not think it deserves.

Sally, accounts payable supervisor. Twenty years of reconciliation and audit preparation. Every upstream error lands on her desk.

Mark, finance executive. Approves the spend and needs visibility into it before the quarter closes.

The insight the project turned on: these four are in conflict without ever interacting. John’s rushed ticket becomes Sally’s reconciliation problem. Ken’s deprioritization becomes Mark’s blind quarter. Nobody is behaving unreasonably. The workflow makes them adversaries, and each experiences the others only as friction arriving from elsewhere.

Digitizing the form was the easy half.

Approval became part of reconciliation

The dashboard shows pending tickets. Each is reviewed against service quality, cost, and delivery timelines, then approved, disputed, or forwarded. Validated tickets archive into a traceable history.

Two decisions made it hold up. Images and documents attach directly to the ticket, so evidence travels with the claim instead of arriving later in an email. And each validated ticket joins a timeline alongside its invoice and purchase order, which turns approval into reconciliation rather than a separate job downstream.

We field-tested with a ticketing company in Texas rather than in a usability lab, which is the only way to learn what happens to an interface inside a truck.

The field visit reframed the design constraint. ↘Go down the rabbit holeWhat testing outside the lab revealed

Offline was the workflow, not a feature

We left offline until the end.

We knew about it. It was in the persona and it was in the room. A field services rep drives to a well site with no coverage, writes the ticket there, and depending on the route may not have usable connectivity for days. He is doing it on a company phone, which he did not choose, which is often older than his own, and which he is not swapping out because our software wants something better.

Knowing it and sequencing it are different things. We treated offline as a capability to add once the core flows were settled, which is the standard way to plan it and the wrong one, because offline is not a feature. It changes what a ticket is. If it can sit unsent on a phone for three days, it has to hold its state locally, survive the phone dying, tell John what has actually reached the buyer and what has not, and reconcile when two versions of the truth meet on sync. Every screen he touches has to be honest about which of those it is showing. Designing that from the start produces a different product than adding it at the end does, and by the time we got there the flows had already been built on the assumption of a response.

The missing network was really a state-management problem. ↘Go down the rabbit holeWhy offline changes the product

The irony was not lost on me later. The point was closing a 22-day gap between work performed and invoice received. We had designed as though the gap between work performed and ticket submitted was zero.

I now ask what happens when the network is gone before I ask what happens when the user taps the button. For anyone working outdoors that is the first question, not a phase-two concern.

Fixing the artifact removed the conflict

OpenInvoice Field Ticket launched in August 2016, four months after I left Oildex. I designed the product. I was not there for the outcome data, and the figures above are labelled accordingly.

What I can speak to directly is the design decision underneath all of it: four roles who never spoke to each other, sharing one artifact, each experiencing the others only as friction.

Designing one artifact that served all four is what moved adoption, and it worked because it removed the conflict rather than mediating it. I have looked for that shape in every enterprise product since. When users complain about each other, the workflow is usually the thing at fault.