Check materials
Enter measured closing quantities. Compare them with the recorded movements, preserve unknowns, and identify differences needing review.
CASE STUDY / FIELD OPERATIONS / WORKING PROTOTYPE
Give the next shift
a clearer place to start.
A field-informed workflow tool that brings material records, assigned follow-ups, and source evidence together for operational and business decisions.
01 / The problem
A physical closing quantity can differ from the balance implied by receipts, transfers, usage, and losses. The next crew needs to see the difference, understand what still needs checking, and know who owns the follow-up.
Matthew’s experience includes inventory reconciliation, real-time data, pricing records, crew supervision, and training engineers in field work. ShiftLedger translates that practical knowledge into a workflow companies can inspect, question, and evaluate alongside their existing systems.
Can a simple sequence help someone close a shift while preserving the depth needed by supervisors, engineering reviewers, and business stakeholders?
WHY THIS EXISTS
Matthew worked as a stimulation technician on a crew that alternated shifts with another. After one handover, a costly mistake surfaced on the following shift: a miscalculation, and steps in the protocol that were not followed, in his account. The company had no way to show who had done what and when. Both technicians were written up.
He was disciplined for something that was not his. That stayed with him. The point was never to shift blame onto someone else. It was that a clear record protects everyone: the person who did the work right, the person who needs help doing it better, and the company that has to know what actually happened.
Matthew did not stop at being frustrated. He treated the gap as a problem to solve: what record would have settled this in minutes? He worked out what a crew actually needs at each handover, then built ShiftLedger around it. That is how he approaches most things: find where work breaks down, name the cause, and build the simplest thing that fixes it for the next person.
Matthew has worked in the oilfield since 2010. That experience covers fracturing, cementing, acidizing, coil tubing and chemical stimulation; pump, blender, sand and bulk equipment; data acquisition and chemical inventory; well-stage pricing and job tickets; safety training and crew leadership; and coordination with drilling teams, customers and vendors. He also holds a Bachelor of Business Administration in Finance from Sam Houston State University, so he looks at each workflow in terms of cost, documentation and billing as well as operations.
Companies also need a fair, consistent way to see productivity and accountability across crews, locations and departments. A shared record lets supervisors, finance, safety and operations answer the same questions from the same facts. A record cannot decide what went wrong, and it does not replace judgment or a proper investigation. It makes sure the investigation starts from what happened.
This account is Matthew’s own, told in general terms. It names no employer or coworker, and none of it is a statement about any specific person’s conduct.
02 / The workflow
Enter measured closing quantities. Compare them with the recorded movements, preserve unknowns, and identify differences needing review.
Give unresolved work a named sample owner and crew. Add context so the next person understands what needs attention.
Review completeness and ownership, record a demonstration acknowledgement, and export a fictional handover record.
03 / The business view
The management view brings job economics, billing stages, delays, and assigned actions together. A job selector narrows the scope; record details expose people, timestamps, and source references.
Ready-to-bill work, documentation holds, outstanding invoices, and collected cash remain separate. Shortages and surpluses are also shown separately. Those distinctions help avoid turning every operational number into a claim of revenue or profit.

PUMP RELIABILITY / FIELD FEEDBACK
The pump module connects a fictional asset and its components with field observations, a named follow-up owner, service records and separate simulated engineering findings. A new service record requires a new review while preserving prior evidence.
Recorded hours, unplanned downtime, repeat observations and known repair costs give the discussion context. Missing costs remain unknown. Observation rates use recorded pump hours and are not presented as verified failure rates or predictions.
Explore the pump workflow ↗04 / Depth without clutter
05 / A business conversation
ShiftLedger is an opportunity to evaluate a focused workflow, adapt it to a company’s approved process, and measure whether it improves the work. Potential engagements include a pilot, product licensing, or a tailored implementation. Commercial terms and integration scope would be defined with the company.
| Business question | Evidence to measure in a pilot |
|---|---|
| Does closeout take less time? | Time to reconcile and prepare a complete shift record, compared with the existing process. |
| Is responsibility clearer? | Unassigned work, overdue follow-ups, and completion or review timestamps. |
| Are records more complete? | Missing readings, missing source references, corrections and rework. |
| Can supported work move through billing? | Documentation holds and time from approved closeout to invoice, keeping billed amounts and cash separate. |
Future contracting opportunities can build on a defined workflow, reviewable deliverables, and demonstrated results. The current prototype is not represented as an awarded government product or a contract-ready production system.
06 / Implementation & evidence
The UI uses HTML, CSS and JavaScript. Reconciliation and management calculations run on the server. A separate sample API serves the fictional preview without exposing calculation source.
The current snapshot passed 61 automated checks, including calculation edge cases, report aggregation, input validation, source exposure, protected-route access, and preview boundaries. Browser checks covered opening the preview, editing a reading, job filtering, inspecting personnel/source details, and the pump service-to-review workflow with a newer record requiring review.
Passing these checks is development evidence, not a production security certification. Report endpoints passed automated checks; browser download capture still needs follow-up.
A second, fully on-site simulation covers data-van style duties with fictional data: parameters recorded and acknowledged by a simulated Performance Center before a stage can start (with store-and-forward when the link is down), threshold alerts, vendor delivery risk against the stage schedule, and a root-cause evidence checklist with named owners. Open the stage console. It is not connected to equipment.
Supervisors schedule crews to locations, crew submit their own time (or clock in and out), and a supervisor can enter missed time with a recorded reason. Corrections never overwrite: the original stays in the record. Each audience gets its own view. Open crew time. It records hours only, not pay.
Domain knowledge translated into a working product: the right fields, meaningful ownership, visible exceptions, and information that supports a decision. Matthew’s contribution centers on understanding the work and the problems worth solving.
07 / Next development milestone
A company evaluation would start with the actual workflow: which information is repeated, what causes a documentation hold, who reviews an exception, and how much time the current process takes. Those findings should guide product development and a measured pilot.
| Current state | Next milestone |
|---|---|
| Session-only records | Persistent records with source retention, revision checks and a durable change history. |
| Sample personnel choices | Verified individual identity and server-enforced company, crew, job and action permissions. |
| Fictional reports and history | Company-reviewed definitions, approved integrations, and measured workflow outcomes. |
| Fictional pump feedback workflow | A working fictional field-feedback prototype; production work needs verified identity, durable component history and company-approved engineering review. |
Created by Matthew Kemp. The implementation was prepared with AI assistance. Matthew Kemp is the named rights owner, to the extent applicable.
CONTINUE EXPLORING
The demo uses fictional records and resets changes on reload.