From messy field notes
to documents a client can act on.

A field report is not a set of notes. It's a decision-grade record — the durable artifact that sits between the work that happened on site and the decisions that have to be made because of it. Done right, it's the document a supervisor, a client, a regulator, or a court can read six months later and know exactly what occurred, what was done, and what's still open.

Every field report has three jobs at once. Get any one of them wrong and the report fails:

• Preserve what happened — the facts on the ground, timestamped and attributable, before memory fades or people rotate out.
• Enable the next decision — a supervisor, a client, or a scheduler has to be able to act from this document without calling the technician back.
• Satisfy the record — compliance, warranty, audit, insurance, contractual deliverable. Whatever boxes have to be checked, check them in writing.

The reports this module covers

The same discipline applies across every form of structured field documentation:

• Work orders — service, repair, install, inspection
• Field service reports — customer-facing summaries of site work
• Incident / near-miss reports — safety, quality, or operational events
• Daily field reports — construction, maintenance, contract operations
• Inspection and commissioning reports — acceptance, QA, turnover

Different industries, same anatomy. If you've written one of these well, you can write all of them.

Before we build a good one, it's worth naming the failure modes plainly. Every operator who has received a hundred field reports has seen every one of these. They're not stylistic complaints — each one costs somebody money, time, or a second truck roll.

Every one of these is solvable with a structured template and a disciplined workflow. The rest of this module is that workflow.

A good field report has seven sections. The names vary across industries; the structure does not. If any section is missing, the document has a hole.

What a finished section looks like

Here's a rendered example. This is the "after" — in Section 6 you'll see where the raw material came from.

Illustrative only — redacted example for format.

Technicians don't write reports the way reports need to read. A good technician spends the visit solving the problem, not drafting prose. What they leave behind is raw material: voice memos, phone photos, scribbled readings, a half-typed work order. The job of the office — or of the technician at the end of the day — is to compile that raw material into a structured document.

This is exactly where Claude earns its keep. Claude is excellent at taking fragmentary, informal input and restructuring it into a defined schema. What Claude is not allowed to do is invent facts the technician didn't capture.

• 1

  Capture raw input in the field

  Voice memos between stops, photos with timestamps on, scribbled readings, the original work-order language. Don't try to write the report in the field — capture, don't compose.

• 2

  Transcribe voice and dump raw material

  Voice memos → text (any modern phone or transcription tool). Photo captions, handwritten readings, controller outputs — all into one raw dump. Messiness is fine at this stage. Completeness matters.

• 3

  Hand Claude the dump plus your template

  Paste the raw input and the seven-section schema. Tell Claude to populate only what the input supports, and to flag any section where the input is insufficient. This is the prompt that matters — see the template below.

• 4

  Review and plug the gaps

  Read Claude's draft with the raw input beside it. Every flagged gap is either a missing input to go chase down, or a decision to leave the section short rather than fake it. Never fill a gap with guessed content.

• 5

  Convert to the client-ready register

  Ask Claude to translate any remaining technician-voice phrasing into professional register while preserving every factual claim. Verify. Sign. File.

The field-report prompt template

ROLE: You are a senior operations documentation specialist. You turn raw field input into structured, audit-ready field reports without fabricating content.

CONTEXT: [The asset, the customer, the type of visit — service, install, inspection, incident. What this report will be used for — invoicing, warranty, compliance, client deliverable.]

RAW INPUT: [Paste everything: voice memo transcripts, photo captions, controller logs, readings, the original work order, technician scribbles. Unorganized is fine.]

TASK: Populate a field report using the seven-section structure:
  1. Header (fixed facts)
  2. Problem (reported symptom, reproducibility)
  3. Findings (observations and measurements on arrival)
  4. Actions (what was done, in order, with parts and labor)
  5. Outcome (verified state, how verified)
  6. Follow-up (open items, recommendations, next service)
  7. Evidence (photos and attachments, numbered and tied to sections)

STANDARD: Only include facts that trace back to the raw input I provided. For any section where the input is insufficient, write "[GAP — need: X]" rather than inventing content. Translate technician-voice phrasing into professional register, but do not alter a single factual claim. Keep prose tight: readings, times, part numbers, actions, verified state, next steps. No adjectives. No editorializing.

That prompt is the entire workflow packaged. The two lines that matter most: "Only include facts that trace back to the raw input" and "write [GAP — need: X] rather than inventing content." Every professional-grade field report you produce with Claude lives or dies on those two instructions.

The single most visible difference between an amateur field report and a professional one is voice. Technicians speak one way on site — vivid, informal, sometimes profane. The report has to speak a different way — neutral, factual, professional — without losing a single technical fact.

Translate the register, preserve the content

Notice the pattern. The technician's uncertainty survives into the report — "suspected," "not confirmed," "recommend" — because that's a fact too. What doesn't survive is the phrasing, the asides, and any unintentional editorializing about the customer. Every time.

Photo discipline — a caption or it didn't happen

Photos without captions are not evidence. They're decoration. Every photo in a professional field report has three things: a number, a caption, and a tie to a section of the report.

• Photo number — 01, 02, 03, in the order they're referenced in the report body.
• Caption — what the photo shows, where on the asset, why it matters. "Photo 02: condenser coil, facing evaporator, showing lint accumulation pre-cleaning."
• Tie-back — the section of the report that references it. "(photo 02)" inline, or listed explicitly in the Evidence section.

Claude can draft photo captions from technician descriptions — that's one of its cleanest use cases. Paste the raw description, give it the asset context, and ask for a three-sentence caption in the professional register. Review for accuracy, then attach.

ROLE: You are writing evidence captions for a field service report.

CONTEXT: [Asset, location, visit date, photo number, which report section this photo supports.]

TECHNICIAN'S DESCRIPTION: [Raw description of what the photo shows.]

TASK: Produce a one-to-three-sentence caption in professional register. State what the photo shows, where on the asset, and why it supports the report section. Do not describe anything beyond what the technician said is visible.

STANDARD: Neutral, factual, specific. No adjectives beyond measurable ones (e.g., "heavy lint loading" is acceptable; "disgusting" is not).

To close the loop, here's a realistic set of technician field inputs from a single call, and the finished report that Claude would draft from it with the prompt above. This is the same walk-in cooler visit from Section 3 — now you can see where the polished document came from.

The raw input

Everything below came off a technician's phone at the end of the visit: two voice memos transcribed, three photo captions, and a scrawled readings sheet. This is what you paste into Claude.

That's the input. Messy, informal, but complete. Every fact that the finished report in Section 3 contains is present here. Nothing is invented in the final document — Claude is compressing and translating, not authoring.

What Claude does with it

Given the raw input above, the seven-section schema, and the prompt template from Section 4, Claude produces the finished report shown earlier. The flow:

1. Extracts the header facts (asset, customer, date, technician).
2. Pulls the manager's complaint verbatim, cleaned to professional register.
3. Organizes findings chronologically — log review, coil inspection, amp reading.
4. Orders actions with times and part numbers.
5. States the verified outcome with the method of verification.
6. Surfaces the technician's two follow-up recommendations as explicit next steps.
7. Ties each photo back to the section that references it.

The whole pass, including your review, takes ten to fifteen minutes. A technician who tried to write that report from scratch at the end of a six-stop day writes it in twice the time and half as well. That's the leverage.

Do this ten times and you will have a library of reports you can point a new technician at as the standard. Do it fifty times and you'll have built the most valuable asset an operations business can have — a durable record of how the work actually gets done, in a voice a client wants to keep paying for.