Scope the work.
Prove the value.

Before you start

Use one workbook per client and bounded use case. The scope describes the operating problem and testable solution boundary; it is not a statement of work, vendor commitment or compliance approval.

Distinguish measured facts, informed estimates and open assumptions. Give estimates an owner and a validation date. Dots beside labels mark core discovery fields, not a submission requirement.

Output to agree: A named sponsor, a specific decision and a traceable scope version.

Define a bounded job, not a general assistant

Write the use case as: When [trigger], [role] needs to [task], using [context], so that [observable outcome]. State why speaking is useful: hands-busy work, faster capture, difficult navigation or dialogue that resolves ambiguity. A screen or conventional workflow may still be better for dense tables or confidential information.

• Walk through one normal case, one ambiguous case and one out-of-scope request.
• Identify the exact asset, site, customer, version or time period needed before an answer is valid.
• Separate answering, recommending, creating a draft and executing an action. Each needs its own permission and success signal.

Illustrative example: after an inspection, a technician dictates findings for an identified asset, checks the read-back and submits a draft maintenance record for a supervisor to review.

Output to agree: One task flow, its entry/exit conditions, permitted actions and exclusions.

Observe the point of use

A quiet office demonstration does not validate use at a work face or on a production floor. Test the complete combination of location, shift, user, device, microphone, protective equipment and network. Record both normal and worst credible conditions.

For mines or industrial sites, obtain local safety approval of devices and interaction practices, including hazardous-area restrictions and the need to hear alarms. This workbook does not authorise device use, replace training or change an emergency procedure.

Output to agree: An approved operating envelope and a site survey/test plan.

Convert concerns into testable failure cases

“Noise” is a condition; “the system hears asset 18 instead of 80 and logs the finding on the wrong asset” is a failure scenario. For each material scenario, state the consequence, a detection method, fallback, owner and acceptance test.

• Test accents, numbers, abbreviations, units, negation, competing voices and incomplete requests.
• Test missing, stale and conflicting knowledge; wrong-user permissions; instructions hidden in retrieved material; interrupted connections and duplicated actions.
• Use operational risk labels for prioritisation only. Legal classification and any mandatory controls require a separate qualified assessment.

Output to agree: An owned risk register with observable stop/escalation conditions.

Separate use, supervision and accountability

The person speaking, the person benefiting and the person approving the outcome may be different. Include employees, contractors and temporary workers; distinguish pilot headcount from eventual rollout. Assess language, literacy, hearing/speech accessibility, experience and willingness to use voice.

• Process owner: accountable for outcome, adoption and operating procedures.
• Knowledge owner / expert: reviews source changes, disputed answers and newly captured knowledge.
• Operations / quality monitor: reviews sampled interactions and escalations; reports aggregate trends.
• IT/security and support: own access, incidents, uptime and recovery.

Agree who can see audio, transcripts and user-level analytics, and for what purpose. Explain monitoring to participants and involve appropriate workforce representatives before the pilot.

Output to agree: A named operating team, permission boundaries and a practical escalation roster.

Separate the device, the transport and the service

A mobile phone is a device, not an architecture. Decide whether audio travels through a telephone call, browser/app session or a specialist gateway, and where speech recognition, reasoning, speech synthesis and recordings would run.

Validate the channel end to end under the client’s identity, firewall and device policies. A headset does not prove hazardous-area approval; a local interface does not prove local AI processing. The offline capability of this workbook is unrelated to the offline capability of a future voice service.

Output to agree: One primary channel, a tested fallback and measurable service requirements.

Build a causal value story

Link a changed behaviour to an operational outcome: faster access to a verified procedure → less search and expert waiting → more tasks completed within the same shift. Do not assume that every faster interaction is a saving; include confirmation time, corrections and follow-up.

• Capacity: hours freed for productive work. This has economic value but is not automatically a budget reduction.
• Cashable saving: a specific overtime, contractor or other expense that the budget owner expects to remove.
• Knowledge transfer: measure independent task performance, time to proficiency and approved expert knowledge reused, not just the number of captured transcripts.
• Quality / safety: use verified process measures and controlled evaluations. A short pilot without an incident does not prove incident reduction.

Output to agree: A small set of benefit hypotheses with baseline, attribution and a realisation owner.

Use a defensible, non-overlapping model

Calculate eligible task volume first, then the expected net time reduction and adoption. Include corrections, confirmation and handovers in the proposed task time. Use a loaded hourly cost agreed with the client; exclude benefits already counted elsewhere.

A cashable share is the portion tied to a planned reduction in a specific expense. Capacity can be valuable even when that share is zero. Avoided errors and downtime may also be non-cash benefits. Obtain budget-owner approval before describing any value as cash savings.

Output to agree: a traceable base case, a lower-adoption downside case and the evidence needed to validate both. Monetary outputs are estimates, not commitments.

Specify the denominator, not just the KPI name

For each KPI define the formula, population, period, baseline, target, evidence source and owner. Keep business outcomes separate from technical quality. Agree a comparison period or matched task group and report by language, site, task difficulty and device where relevant.

Output to agree: A baseline and acceptance method that can support a go/hold decision.

Separate what should happen from what did happen

Policies and approved procedures define expected behaviour; incident reports and expert observations describe particular events. Preserve that distinction. A report must not silently override a current normative instruction.

• Documents: retain tables, headings, conditions, units, version dates and source references.
• Structured records: retain entity identifiers, field meanings, permissions and timestamps.
• Live information: retrieve at the required freshness; define what happens if the source cannot be reached.
• Tacit knowledge: capture with permission, identify the expert, review the claim and its applicability, then approve it before reuse as authoritative guidance.

Organise knowledge so it can be spoken accurately: short explanations, clear conditions and evidence available on request. Do not discard qualifiers to make answers shorter.

Output to agree: A source inventory, freshness rules and an owner for approval and change.

Scope each integration as a separate contract

Knowing a system name is not proof of access. For each environment identify the exact product/module, version, object or endpoint, owner, tenant/site boundary, permissions, freshness and expected traffic. Ask for a supported access method, sample payload and sandbox; API availability, licensing and approvals must be confirmed with the client/vendor.

Enforce the user’s data permissions throughout retrieval, caches and actions. Retrieved text is data, not authority to alter system instructions. A voice confirmation does not replace server-side authorisation.

Output to agree: An integration register plus approved data flows, access and retention boundaries.

IT handover for this workbook

Local JavaScript and downloads must be permitted. No automatic external calls are made; reference links below require a deliberate click. Browser drafts and exported files are not encrypted or access-controlled by this workbook. Use the client’s approved storage and sharing controls.

If hosted internally, IT should set authentication, transport security and security headers. W3C specifies that frame-ancestors cannot be enforced by an HTML meta policy; it belongs in the server-delivered policy. Do not weaken corporate browser or server policies to make this file run. W3C: CSP delivery via meta.

Make the next commitment explicit

A pilot tests the weakest assumptions in a bounded workflow. Agree a representative cohort and source set, baseline collection, scripted tests, controlled live use and a final evidence review. Keep a route back to the approved current process.

Before scaling, confirm the service owner, support budget, monitoring, knowledge maintenance, security approval and deployment/change process. Treat extra sites, languages, source families and write actions as scope changes requiring review.

Output to agree: proceed, targeted further discovery or hold — with an owner, due date and evidence-based reason.