The 1.5-Hour Checklist Was Written Where the Work Happens

At a Williams compressor station in Virginia, preparing a preventive-maintenance checklist for electrical equipment had taken a full working day and, at times, two. Williams says employees reduced that work to about 1.5 hours by using approved AI tools and refining the prompts they used.

The number is narrow. It is Williams’ own reported result for one type of preparation work at one site, not an independently audited productivity study or a general maintenance benchmark. It does not show that AI inspected equipment, diagnosed faults, selected maintenance actions, or replaced a technician’s judgment. But it does reveal something more useful than another adoption percentage: the workflow was shaped by the people closest to the equipment.

That is the important operating lesson. Broad AI access is not the same thing as useful AI work. Where the work product is bounded, inspectable, and still reviewed by a responsible person, the people who carry out the job are often best placed to turn general-purpose tools into a workable process. The central team’s task is not to write every field instruction. It is to make safe, supported experimentation possible and to help successful workflows travel beyond their original location.

The result was faster preparation, not autonomous maintenance

It is worth being precise about what Williams has described. The company says frontline teams use AI to produce repeatable artifacts such as preventive-maintenance lists and troubleshooting guides. These are useful work products because they can be read, challenged, corrected, and used by people who remain accountable for the physical work.

Microsoft’s September customer case adds implementation detail. Williams enabled employees to create workflows and connect them so that they could be made available more broadly. A Williams operations supervisor said that field personnel—not the central Copilot team—develop the relevant instructions and knowledge bases. The central function provided training and support; the field supplied the operational content.

That division matters. A central AI team can establish approved tools, offer enablement, and help connect a workflow to the systems around it. It cannot reliably reconstruct every local condition, recurring exception, equipment convention, or sequence of checks that experienced personnel carry in their working practice. A centrally designed template may be necessary, especially for common controls. It is rarely sufficient as the complete operating method.

Williams also described an employee-built workflow that reads equipment reports sent to an Outlook distribution list, compares them with baseline statistics, and alerts on deviations in measures such as temperature, oil pressure, or vibration. This is a different example from the checklist and should not be combined into one return-on-investment figure. It is nevertheless consistent with the same pattern: workers identify a repeatable information task, encode a bounded workflow, and retain responsibility for the operational response.

Workflow authorship is a distribution decision

Many AI programmes distribute licenses first. They measure activation, monthly users, or the share of employees who have tried an assistant. Williams reported in June 2026 that more than 90% of employees were using Microsoft Copilot or other approved AI tools. That is a substantial adoption figure, but it is not itself a productivity or safety result, and the sources do not establish frontline authorship as its cause.

The Virginia case points to a more demanding measure: can the people who own a recurring task revise the instructions, knowledge, and sequence that turn a tool into a dependable work product? If the answer is no, a license may help with isolated drafting while leaving the actual workflow unchanged. If the answer is yes, local expertise can be made more repeatable without pretending that it has become fully automatic.

This does not mean every employee should build anything they want. Field authorship works best when the unit of work has clear edges. A maintenance list, troubleshooting guide, report triage routine, or comparison against an established baseline can be inspected before use. The input materials can be identified. The output can be checked against the equipment, procedure, and local operating conditions. The human who acts on it is visible.

By contrast, a vague instruction to “automate maintenance” collapses preparation, diagnosis, prioritisation, authorization, and physical execution into one unsafe abstraction. Those activities carry different risks and require different controls. The available evidence from Williams supports faster preparation of human-reviewed work. It does not support handing a model the authority to service infrastructure independently.

Start with artifacts that can be inspected

For operations leaders, the practical starting point is not a companywide catalogue of AI use cases. It is a small inventory of recurring artifacts whose quality can be reviewed before they affect work. Look for documents and routines that consume experienced time because they require gathering known information, reconciling it with local context, and presenting it in a usable form.

• Choose a bounded artifact: a preventive-maintenance list, troubleshooting guide, shift handover summary, report triage routine, or exception brief.
• Name the field owner who can define a useful output, identify missing context, and reject a poor draft.
• Use approved tools and known source material. Make the inputs, prompt or instructions, and output available for review and improvement.
• Keep the operational decision with the responsible person. An AI-produced list or alert can prepare attention; it does not decide what physical action is safe or required.
• Share mature workflows deliberately. Broader availability should follow local refinement and review, not replace them.

This is a modest architecture, and that is its strength. It does not require an organization to claim autonomous operations before it has reliable, reusable artifacts. It creates a route from individual craft knowledge to a shared operating asset while preserving a clear human decision point.

Central support should remove friction, not absorb the job

There is a common false choice between central standardisation and local invention. Williams’ account suggests a more productive division. Central support can provide the approved environment, training, technical help, and a path for connecting and sharing workflows. Frontline teams can maintain the instructions and knowledge bases that make a workflow credible in the field.

Each side does work the other cannot easily substitute. Without central support, local experiments may remain isolated, use unapproved tools, or lack a route to wider reuse. Without field authorship, a central programme can scale generic capability while missing the operational detail that makes a checklist usable on a specific station and shift.

The consequence is organizational rather than merely technical: workflow ownership should sit close to the work, while platform support and reuse mechanisms sit where they can serve many teams. Managers should ask whether their AI programme gives experienced workers a practical way to improve the artifacts they rely on—not merely a chat window and an encouragement to experiment.

Williams’ 1.5-hour result should not be inflated into a claim about autonomous infrastructure or universal maintenance productivity. It is more valuable as a disciplined case. A field team used approved tools to improve a defined, reviewable preparation task. The people who understood the work authored the relevant instructions and knowledge. That is a concrete design choice other operations teams can test: distribute workflow authorship before assuming that distributing AI access will change the work.