# Field Observation — Voice Debrief to Report A simple, repeatable way to turn a spoken field-visit debrief into a clean, structured written report. Do the visit, talk through what you saw, run it through an AI tool, and get a tidy report back. *This is a starting template — adapt it freely and add your own branding.* --- ## What's an .md file? It's just a plain text file (the "md" stands for Markdown). Think of it as a Word document with no fancy formatting — only simple symbols like `#` for headings and `-` for bullet points. You don't need special software: you can open it in Notepad or TextEdit, or simply copy everything in it and paste it straight into an AI chat. The AI reads the symbols and structure without any trouble. --- ## How to use this 1. **Do your field visit.** Spend the time observing the work and talking to the people doing it — that's the whole point. The mic is just there to capture good audio afterwards. 2. **Record a short voice debrief** when you're done, covering the questions below. A lapel mic is ideal — better field audio means a cleaner transcript. 3. **Turn your audio into text for free in Microsoft Word.** In Word (Word for the web is easiest), go to the **Home** tab → click the arrow next to **Dictate** → **Transcribe** → upload your recording. Word writes it out for you and you copy the text. (Your phone's voice-to-text or any transcription tool works too.) 4. **Run it through an AI tool.** Paste this whole document into **Microsoft Copilot** (or Claude, Gemini — whichever you use), then paste your transcript at the bottom under **Transcript**. Copilot will follow the instructions in this file and build the report. 5. You'll get back a structured report in the format shown in the worked example. --- ## Just talk — don't script it You don't need to be formal or get it in the right order. Ramble. Be colloquial. Trail off and come back to things. Say "um" and "the thing over there." That's completely fine — structuring the mess is the AI's job, not yours. Your job is to notice things and say them out loud. The rougher and more honest the debrief, the more useful the report. --- ## What to cover in your debrief These pull double duty: a prompt sheet for what to talk about on site, and the structure the report follows. 1. **The task** — what work were you observing, and how is it set up and resourced? 2. **Location and people** — where were you, how many people, and who was doing what (crew, supervisors, apprentices)? 3. **Hazards** — what could cause serious harm or a fatality here? 4. **Controls** — what was in place? Call out the *critical controls* (the ones that on their own prevent a fatality) separately from the supporting controls (signage, briefings, posted speed limits, and the like). 5. **What's working well** — good practice, good habits, and smart ways the work has been set up or designed. 6. **Areas for improvement** — what could be better? 7. **Follow-up actions** — what needs to happen next, including any good work worth sharing more widely. --- ## Before you paste a transcript This report can capture real names, people and site details. Before putting a transcript into an AI tool: - Remove or anonymise individual names, client names and exact site identifiers unless you have consent to process them. - Use your organisation's approved AI tool for anything work-related. --- ## Make it yours Add your own context anywhere it helps — your project name, the site, what you want the AI to focus on, extra report sections, or your own branding. You can also tell the AI things like "focus on critical controls" or "write it for a leadership audience." And once you're comfortable with how this works, **everything above the line below is just guidance for you and can be deleted.** Everything from there down is what the AI actually needs. --- > **▼ Keep everything below this line.** Everything above is for you. Paste any of your own context right here, before the instruction. --- ## Instruction to the AI You are helping turn a spoken field-observation debrief into a clear, structured written report. Read the transcript provided under **Transcript** at the end of this document, and reorganise what the observer said into the **Report format** below. Rules: - Use **only** what's in the transcript. Do not add hazards, controls, observations or actions that weren't mentioned. - If a section wasn't covered, write *Not covered in this debrief.* — don't fill the gap. - Lead with anything that could cause serious harm or a fatality. Don't pad the report with low-consequence routine items unless the observer raised them. - **Separate critical controls from supporting controls.** A critical control is one that, on its own, prevents the fatality or materially reduces its consequence — if it failed or was missing, the event could still happen even with everything else in place (for example, physical separation or an exclusion zone between people and the energy that could kill them). Warning, awareness and administrative measures — signage, inductions, posted speed limits, briefings, general supervision, stop/slow control — are supporting controls. They reduce likelihood or exposure but do not on their own prevent the fatality, so do not list them as critical. - Keep it concise and factual. Plain language, short bullet points, no editorialising or inflating. - Tidy up filler, repetition and false starts from the spoken audio, but keep the observer's meaning intact. - Keep any names or site details exactly as the observer gave them (or as they anonymised them). Then output the report using the **Report format** below. --- ## Report format ### Field Observation Report **Task:** **Location:** **Date:** **People present:** **Observed by:** #### Task description A short description of the work observed and how it was set up. #### Hazards - The things that could cause serious harm or a fatality. #### Critical controls - The controls that on their own prevent the fatality (for example, physical separation or an exclusion zone), and whether each was in place and effective. #### Supporting controls - The measures that reduce likelihood or exposure but don't by themselves prevent the fatality (signage, briefings, posted speed limits, traffic control, and similar). #### What's working well - Good work, good habits and smart work design seen on site. #### Areas for improvement - What could be better. #### Follow-up actions - What needs to happen next, including any good practice worth sharing more widely. --- ## Worked example ### Example transcript (what you might say into the mic) > Right, okay, so it's Thursday arvo, I'm out at the lane closure on the arterial — the culvert works job. There's about six on the ground, two traffic controllers on the stop-slow, a crew of three doing the actual works, a supervisor floating around, and an apprentice, young fella, shadowing. Um. So the big one for me, the thing that'll actually kill someone, is the live traffic — you've got cars coming through at, what, sixty, seventy, and the workers are in there on foot, so it's all about that separation, the exclusion zone, keeping the public away from the crew. They've got the lane closed, cones, signage is up early which is good, speed's dropped through the zone. What was really good actually, and I haven't seen this before — one of them had jumped on and submitted the closure to Google Maps in real time, reported it through the app, so the navigation was already rerouting people before they even got to the closure. So you're not getting as many cars turning up confused at the taper, they've been sent around already. That's clever, takes the pressure off the controllers. Improvement-wise, the buffer, the distance of the exclusion zone — I thought it was a bit tight for the speed of that road, the gap between the last cone and where the blokes were actually working, I'd want that longer. And the other thing, more of an observation — there's one supervisor and he's covering the crew and the apprentice and half-watching the controllers, that's a lot, that ratio's a bit stretched, and that's probably a scheduling thing more than a today thing. Follow ups — extend that buffer, definitely, and we should write up that Google Maps trick so other crews do it. And look at the supervision ratio when we're planning these. Yeah, that's it. ### Example report (what comes back) ### Field Observation Report **Task:** Traffic management setup supporting culvert works behind a lane closure **Location:** Lane closure on an arterial road (culvert works) **Date:** Thursday [date] **People present:** ~6 on site — 2 traffic controllers (stop/slow), 3-person works crew, 1 floating supervisor, 1 apprentice shadowing **Observed by:** [observer name] #### Task description A crew was carrying out culvert works behind a lane closure on a live arterial road, supported by a traffic management setup separating the work area from passing traffic. #### Hazards - Live traffic adjacent to workers on foot — vehicles approaching at roughly 60–70 km/h with the crew inside the closure. Potential for serious or fatal injury from a vehicle intrusion into the work zone. #### Critical controls - Physical separation between live traffic and the work crew — the closed lane and exclusion-zone buffer. In place, but its adequacy is in question: the buffer looked tight for the road's approach speed (see Areas for improvement). #### Supporting controls - Advance signage set up early, ahead of work starting - Reduced (posted) speed limit through the work zone - Traffic controllers managing the approach (stop/slow) - Real-time closure reported to Google Maps, rerouting drivers upstream and reducing the number of vehicles arriving at the taper #### What's working well - **Proactive public protection through work design:** submitting the closure to Google Maps in real time rerouted traffic before it reached the site, cut the volume of vehicles arriving at the taper, and eased pressure on the controllers — a smart, low-cost control (see how-to below). - Signage was set up early, before work began, rather than rushed once the crew was exposed. #### Areas for improvement - **Exclusion zone distance:** the buffer between the last cone and the working crew looked tight for the approach speed of the road. Recommend a longer set-back appropriate to the speed environment. - **Supervision load:** one supervisor was effectively covering the works crew, the apprentice and the controllers — a stretched ratio. More a scheduling and resourcing matter than a same-day fix. #### Follow-up actions - Extend the exclusion-zone buffer to suit the road's approach speed. - Write up the real-time Google Maps closure method and share it so other crews adopt it. - Review apprentice-to-supervisor ratios when planning and scheduling similar works. --- ### How they did it — flagging a road closure on Google Maps in real time The standout in this observation was getting the closure onto Google Maps so drivers were rerouted *before* they reached the site. It's quick, and worth other crews knowing: 1. Open Google Maps and start navigating toward the closure location. 2. Tap the report icon on the navigation screen (the speech-bubble or **+**). 3. Choose the **closure** / roadworks option and confirm the location. 4. Submit. The more crew or members of the public who confirm it, the faster it sticks and the routing updates. For a planned or longer closure, you can also submit it via **Menu → Edit the map → Report a road closure**, or use **Waze** (also owned by Google) for fast community reporting. *(Exact menu wording varies by app version.)* **Important:** this is an extra layer of public protection — not a replacement for your formal traffic management plan and road-authority approvals. Those still come first. --- ## Transcript *Paste your debrief transcript below this line.* ---