Draft a Site Progress Update from Your Observations with AI at the Cursor

You can speak your site observations and ask AI to draft a structured progress update at your cursor, provided you supply verified inputs and review the result before anything is used. The useful output is a short update covering the location, the work you observed, the unresolved issue and the responsible person, plus a list of facts still missing. The AI step needs an internet connection, an enabled service, your consent, access to that service and a compatible focused Windows text field. You remain responsible for every measurement, judgement and decision in the final text.

This article covers how to set up the workflow, how to capture observations while they are fresh, how to phrase the spoken request, what to check afterwards and how to measure whether the workflow earns a place in your routine.

A progress update is read by people who were not on site. A project manager, client representative, contractor or colleague may need to act on it. Updates can fall short in three ways: they omit the location, they blur what was seen with what was assumed, or they mention a problem without naming who owns the next step.

For a first draft, four fields carry most of the weight:

• Location: the road, structure, zone, chainage reference or grid line your team already uses.
• Observed work: what you saw, in plain statements of fact.
• Unresolved issue: what remains open, uncertain or waiting on someone else.
• Responsible person: the named person or role expected to act, as you understand it.

A fifth element improves the draft: a short list of missing facts. If you did not record a depth, a date or a delivery confirmation, the update should say so instead of filling the gap with something plausible.

These fields suit speech because they are short and concrete, and easy to say while standing at the edge of the works.

SpeakLingo uses the term Syping for combining speaking and typing. You keep the cursor in the text field where the update will live and speak, and text appears there. Plain dictation only transcribes what you say. When you want AI to do more, such as structuring your inputs into an update, you use the supported AI Task workflow and the draft text is produced at the same cursor. The concept is explained on the Syping page, and the wider product scope is outlined on the features page.

Two product capabilities matter here:

1. Online transcription in 99+ languages. Your spoken observations become text, and you choose a supported language that suits you.
2. AI contextual formatting. Spoken material can be shaped into a clearer structure, such as headings, short paragraphs or lists, depending on what you ask for.

The workflow aims to reduce a familiar routine. Notes are typed or dictated in one place, copied into a separate AI window, wrapped in a prompt, and the result is copied back into the site diary, email or project tool. Where the supported cursor workflow fits, the draft arrives in the field where you are already working, so there is less structuring by hand and less switching between windows. Whether this suits you depends on the target field being compatible, so test it first.

Some boundaries apply. SpeakLingo is not compatible with every application or text field, and it does not take over your computer or act on its own. AI output is a draft and needs your review.

A few minutes of preparation prevents most surprises on site.

1. Pick the destination field. Choose where the update will live, such as a site diary entry, an email draft or a project tool note, and confirm it is a compatible text field by dictating a harmless test sentence.
2. Turn off automatic Enter or send behaviour. SpeakLingo has an optional setting that presses Enter after text is delivered, which in some apps can send a message. For progress updates, switch it off to reduce the risk of anything being submitted before you have read and reviewed it.
3. Choose your dictation language. Pick a supported language you can speak precisely.
4. Decide on screen context. It is optional and involves your opt-in. Leave it off unless you need it, and keep unrelated documents out of view.
5. Check connectivity. The AI step needs internet access and an enabled service. If you expect poor signal, do not assume transcription or AI will be available. Transcription has its own mode, setup and access requirements. Have a fallback such as handwritten or typed notes, and structure them later once the AI service is reachable.
6. Leave the draft unsent. Review the text in the field, make your edits and send it yourself through your normal channel.

One point about how the AI step works matters for site updates. To get a drafted update, use the supported AI Task workflow and give the instruction and the facts it needs together in that one request. For example, ask for a structured progress update and, in the same request, state the location, what you observed, the open issue and who owns it. Dictating alone does not switch AI on. The AI does not automatically see your earlier dictations, text already in the field, or what is on your screen. If you want screen contents considered, that is a separate opt-in, and the screen context may be sent to a remote service. Anything you leave out of the request is a gap the draft should flag, not something the AI knows.

The sequence of the day, which crew was where and the exact wording someone used about a delivery all blur by the time you are back at a desk. Speaking the inputs soon after you observe them gives you a better chance of recording them accurately.

A few practices make the spoken capture cleaner:

• Say the location first. Anchoring each note to a place stops later details drifting between areas.
• Separate what you saw from what you were told. Say 'I observed' for the first and 'the foreman said' for the second, so the distinction carries into the draft.
• Say measurements only if you took them. State the value and unit clearly. If you did not measure, say 'not measured' so the gap can be flagged.
• Name the owner of each open item. If nobody owns it yet, say 'owner not confirmed.'
• State the date and time of observation. An update without a timestamp is harder to act on.

Avoid dictating client-confidential details or anything you would not want processed remotely. Audio and text may be sent to a remote service for transcription and AI requests, and optional screen context, if you opt in, may be sent too. If your organisation has rules for site information, follow them.

This example is illustrative, not observed output. The site, people, details and events are invented to show a writing process. They are not real project data and should not be reused.

Before: raw spoken capture

Imagine you finish a walk-round of a fictional culvert replacement on the 'Northfield access road' and dictate the following into a compatible text field. The transcription appears as you said it, hesitations included:

ok so Northfield access road culvert, east end, crew finished the pipe bedding I think up to the second chamber, headwall formwork is up but not poured, there's water coming into the trench at the low end, pump's running, I don't know where it's coming from yet, Dana the foreman said she'd chase the supplier about the backfill material, maybe Thursday, I didn't write down the trench depth, um, and I think the inspection is booked but I'm not sure of the day

This reflects what you remember, but it is not ready to forward. It mixes observation with hearsay, leans on 'I think' twice, and does not say who owns the seepage question.

The spoken AI request

Before asking for a draft, decide which items you can stand behind and which are reported by others or uncertain. Then speak an instruction based on this prompt, giving the inputs in your own words:

Using only these verified inputs, draft a site progress update from my observations. Inputs: [Location, observed work, unresolved issue, responsible person]. Use a clear professional structure. Flag missing facts; do not invent them.

In practice you replace the bracket with the facts. For the example, that would be the culvert location, the formwork and pumping you saw, the seepage as the open issue, and Dana as the person following up the backfill. The instruction to flag missing facts and not invent them is the most important line, because it sets the expected behaviour at every gap.

After: an illustrative AI-assisted draft

A draft might come back like this (illustrative, not observed output):

Site progress update (DRAFT for engineer review)

Location: Northfield access road culvert replacement, east end.

Observed work: - Pipe bedding reported as complete up to the second chamber (extent to be confirmed). - Headwall formwork is erected. Concrete has not been poured. - Water is entering the trench at the low end. A pump is running.

Unresolved issues: - Source of the water entering the trench has not been identified. - Backfill material: the foreman said she would chase the supplier, possibly on Thursday. No delivery date has been confirmed. - Inspection: reported as booked, but the day and the booking itself are not confirmed.

Responsible persons: - Dana (foreman): reported as chasing the supplier about the backfill material. - Seepage investigation: owner not confirmed.

Missing facts to confirm before issue: - Trench depth at the low end. - Date and time of observation. - Chainage or reference for the second chamber and the trench low point. - Inspection date. - Who will investigate the water source.

What you do next

The draft is better structured, but it is still a draft. A careful review might involve these edits:

• Replace 'reported as complete' with a plain statement if you verified it, or keep the hedge if you did not.
• Add the trench depth only if you measure it, and add the observation date and time.
• Assign an owner for the seepage investigation after you speak to the project team, and not before.
• Remove any phrasing that could read as an assessment of stability or safety. The update records what was seen and does not judge whether conditions are acceptable.
• Confirm the inspection day against the booking record.

Once those changes are made, you choose where the update goes and send it yourself.

Keep this skeleton as a snippet or speak it from memory. Fill each line with facts you have verified, and leave a line empty or say 'not confirmed' when you do not know the answer.

Draft a site progress update using only the inputs below. Do not invent facts. Mark anything missing as 'to confirm'. Keep observations separate from reported information.

Date and time of observation: [ ] Location: [site, zone, chainage or reference] Observed work: [what I saw, with measurements only if I took them] Reported by others (not observed): [who said what] Unresolved issue: [what is open or uncertain] Responsible person: [name or role, or 'not confirmed'] Next step I expect: [action and date if known]

Format: short headings, bullet points for observations, and a final list titled 'Missing facts to confirm'.

Two details make the template useful. The 'Reported by others' line stops hearsay turning into observation, and the closing list turns gaps into a to-do list instead of leaving them hidden in confident prose. For more ideas on adapting spoken workflows to other roles, see the use cases page.

Run through this before the update is sent or filed. It is an illustrative writing practice, not a regulation or professional standard, so adapt it to your organisation's requirements.

Facts and measurements - Every measurement was taken or sourced by someone, and its unit is stated. - Any figure the AI introduced that you did not say has been removed or confirmed. - Chainage, grid references and element names match your project documents. - Dates and times of observation are present and correct.

Observation versus report - Statements of what you saw are separate from what others told you. - Words such as 'complete', 'satisfactory' or 'acceptable' appear only where you have the basis to use them. - Hedges such as 'I think' have been resolved or deliberately kept.

Issues and ownership - Each unresolved issue has a named owner or is marked 'not confirmed'. - Next steps and dates reflect what was actually agreed. - Nothing in the draft reads as a design decision or approval.

Scope and boundaries - The update records conditions and does not state that they are safe or approved. - Anything that may need design or safety review goes to the right person through your normal process. - Confidential or sensitive content is removed if the destination is not appropriate.

Final handling - Automatic Enter or send behaviour was off while you dictated, and the text is still unsent. - The draft label is removed only after your review. - You have chosen the recipients and sent the update yourself.

Rather than assuming a workflow is faster, measure it with your own work. The meaningful figure is time to reviewed output: the time from the end of your site observation to an update you are willing to send, with review included. A draft that appears quickly but needs heavy correction is not complete until it passes your checklist.

A simple approach:

1. Define start and finish. Start when you finish the walk-round. Finish when the update has passed your checklist and is ready to send.
2. Record both routes. Time several updates with your usual method and several with the cursor workflow, covering similar kinds of work and similar lengths.
3. Note the review effort. Keep a short tally of corrections, such as figures changed, owners added or hedges resolved. A quick draft with many corrections tells you something different from a quick draft with few.
4. Watch for hidden steps. Include the time spent placing the cursor, speaking a clear request and fixing transcription errors, especially in site names and technical terms.
5. Compare like with like. A routine update and a complex multi-issue update are different tasks, so keep them in separate groups.
6. Repeat before deciding. A handful of samples says more than one. Keep the records so you can adjust the template and revisit your results later.

If the workflow does not suit a particular kind of update, that is a useful finding too.

Several conditions apply, and it helps to understand them before you rely on the workflow on site.

• Internet and service access. Spoken AI requests need an internet connection, an enabled service, your consent and access to that service. Without these, the AI step is unavailable. Transcription has its own mode, setup and access requirements, so AI being unavailable does not show that transcription is available, and the reverse also applies.
• Remote processing. Audio and text may be sent to remote services. If you opt in to screen context, that context may also be sent. Keep sensitive documents out of view and out of your dictation when this is a concern.
• Compatibility. The AI draft appears at a focused text field in a compatible Windows application. Not every application or field works, so test with a harmless note before using it for a real update.
• Sending stays with you. An optional Enter-after-delivery setting can submit text in some apps, so keep it off for progress updates and send only after your review.
• Fallback only. Offline English transcription is only a fallback, and only if it has been configured beforehand. Do not assume it is set up or will work on site, and test it before you rely on it. AI requests do not work offline, so plan to structure the notes yourself or run the AI step later.

Online transcription supports 99+ languages, so you can dictate in a supported language that suits you and your team. Choose the one you can speak most precisely, particularly for place names, technical terms and quantities. This is transcription support only. It is not translation, and it does not guarantee AI-generated output in every language. If the update will be read in a different language from the one you dictated in, check the text carefully, or ask a colleague who reads that language to review it before issue.