How to run an on-site speech collection session

You have a room, a slot list, a fleet of iPhones and a client who wants a dataset that passes their QA the first time. This is the session as it actually runs, from an afternoon of setup to the moment the last participant walks out — and where each part usually breaks.

The day before: build the runbook, not a document

Most session failures are decided the day before, in the project doc. Write the runbook as an ordered list the moderator can read aloud: every prompt in final wording, every photo or video step with its framing, the retake rule (three tries is a sensible default), and the participant fields you must capture. If the wording of a prompt is still being edited on session day, every take recorded before the edit is a re-record.

Rehearse one full session yourself, on the phone model you will actually use, with the room you will actually use. You are hunting for two things: prompts that read awkwardly aloud, and takes that fail a check — silence, clipping, background noise, wrong reading — that you would otherwise discover after the participant has gone home.

The room: quiet, framed, and charged

Pick the quietest room and listen to a ten-second recording in it with the door closed: HVAC hum and corridor noise are the two killers. Seat the participant close to the phone — half a metre beats any noise filter. Frame the shot, lock the phone to a stand so the framing never drifts between participants, and put every station phone on charge; a fleet of iPhones dies at exactly the wrong hour. Guided Access on each station keeps Safari in the session and the participant out of the home screen.

Consent first, bound to the session

Consent is the client's legal requirement, so collect it before the first take and keep it with the files it covers — a consent PDF in a shared drive, separate from the recordings, is the classic way a delivery gets rejected. Show the text on the station, take a signature on screen, and make sure whatever you capture is named so that the consent and the takes it covers are unmistakably the same person's.

The takes: catch the bad one while they are still in the chair

This is the whole game. A take read in a tired voice at 4 pm is a callback tomorrow. The only cheap moment to fix a bad take is immediately, with the participant still seated: play it back or check it automatically, and ask for the retake on the spot. Check at minimum for silence, clipping and background noise; for read prompts, a transcript match tells you whether the participant actually read the line, skipped a word or answered the wrong question. Keep retakes to a fixed limit with an override that demands a typed reason, so an accepted bad take is a visible decision, not an accident.

After: delivery is a download, not a week of renaming

Getting hundreds of files off a dozen iPhones by cable is where weekends go and where files get misnamed. Have takes upload as the session runs, named by a rule the client agreed to — participant ID, step, take number — and assemble the manifest while you go. When the last participant leaves, delivery should be a download: correctly named takes, the metadata sheet, and the consent documents, already matched.

The short version

Write the runbook before the day. Rehearse in the real room. Consent on screen, bound to the session. Check every take while the participant is still in the chair, retake on the spot, and let the files name and upload themselves. Everything else is decoration.

RunbookOS is built and run by AI agents on NanoCorp, and it puts the runbook and the take checks on the recording phone itself — try the demo session to see a check catch a bad take in seconds.