Number the discovery notes, ask AI to sort them into a requirements record where every line is marked confirmed, assumed or open, then draft scope-of-work lines from the confirmed items only. The system designer then checks each line against equipment, cabling, power and network before the scope goes to the client.
Discovery notes contradict themselves. The managing director wants "one button for everything", IT wants nothing new on the network, and HR has a view on recording. AI is good at sorting that pile and poor at knowing which statement wins. So each scope line carries the ID of the note it came from and a status, and open questions stay visible instead of being settled quietly by the draft.
The illustrative project is a craft brewery supplier's new unit: a 10-seat meeting room, a 20-seat training room, a four-person huddle room and a reception display. Notes from two site visits and a call run to about 1,900 words and 38 numbered notes. The training room carries the detail below, and the other spaces follow the same steps. Once the scope is agreed, the next job is putting scope and exclusions into the proposal, and the tests at the end of the project come from these same lines.
Have these ready: the raw notes from every visit and call, the room list, the client's contacts with their roles (who can decide what), and your standard list of discovery questions. If the notes are thin, go back to the client before you draft anything, because no tool can recover facts that nobody asked about.
Why raw discovery notes cannot go straight into a scope
Three kinds of trouble turn up in almost every set of notes. The first is disagreement: the operations manager says sessions should be recorded and HR says to check consent first, and both statements are true at once. The second is vagueness: the back row must see small parts "clearly", which is not a requirement until someone says how far away the back row sits and how small the parts are. The third is vague timing: the client's IT team will create meeting-room accounts "by next month", which is a hope rather than a date.
A scope of work written straight from notes like these hides all three. It picks a side, invents a number or assumes a date, and the client discovers the choice at handover. The method below keeps each problem visible until a person with authority settles it.
Step 1: number the notes and keep who said what
Before any AI sees the notes, give each one an ID and record who said it and where. One fact per note. This takes about 20 minutes for a set this size and it is the step that makes the rest traceable, so do it by hand. If the notes come from a call recording, check the numbers in the transcript against your own notes, and get everyone's consent before an AI notetaker joins the call. The training-room notes look like this:
N11 Training room: 20 people, classroom layout, sometimes cabaret. (ops manager, visit 1)
N12 Trainer demonstrates at a bench at the front, about 2.4 m long. People at the back must see small parts "clearly". (ops manager, visit 1)
N13 Remote staff join by Teams and must see the bench demo "properly". (ops manager, visit 1)
N14 Recording sessions: ops manager says yes; HR says check consent first. (visit 1 and call)
N15 Old 65-inch TV on a trolley "to be binned"; Bluetooth speaker. (visit 1)
N16 Mix of Windows laptops and a few Macs; some trainers show video from a phone. (IT lead, visit 1)
N17 Front wall has three network ports: two live, one dead. IT will patch more "if we tell them where". (IT lead, visit 1)
N18 Guest Wi-Fi is separate and slow; the staff network is firewalled. (IT lead, visit 1)
N19 "No cables on show." Ceiling is plasterboard, walls are painted block. (MD, visit 2)
N20 Ceiling height 2.7 m; windows along the left wall; blinds not fitted yet. (visit 2)
N21 MD wants one button to start a meeting in every room. (call)
N22 IT will create room accounts for Teams "by next month". (call)
N23 Budget "around 25k for all four spaces". (MD, call)
N24 Training runs Monday to Thursday, 09:00 to 16:00; install must avoid those days. (ops manager, call)Step 2: a requirements record with a status on every line
The first AI task is sorting, not writing. The prompt below forbids choosing equipment and forces a status onto each requirement. Note the two rules that matter most: disagreeing notes make a line Open, and budgets and working-hour limits go to a separate list.
You are helping an AV integrator turn discovery notes into a requirements record.
Use ONLY the numbered NOTES below.
For each space, produce a table with these columns:
Req ID | Requirement | Source note IDs | Status | Question for the client
Status:
- Confirmed: a client stakeholder stated it clearly and nothing in the notes contradicts it.
- Assumed: implied by the notes but never stated. Say what you assumed.
- Open: vague, missing a detail, or contradicted by another note.
Rules:
- One need per line. Quote numbers exactly as written.
- Do not choose equipment, sizes, brands, cable types or positions.
- Put budgets, dates and working-hour limits in a separate CONSTRAINTS list, not in the table.
- If two notes disagree, mark the line Open and name both note IDs.
- Finish with a list of any notes you could not place.
NOTES:
[paste the numbered notes]For the training room, the record comes back with 12 lines: 6 Confirmed, 3 Assumed and 3 Open. You still read it against the notes, because the status column is a judgement and the AI can get it wrong.
| Req | Requirement | Source | Status |
|---|---|---|---|
| R01 | Seating for 20 in classroom or cabaret layout, with a clear view of the front from every seat | N11 | Confirmed |
| R02 | Trainer demonstrates at a front bench about 2.4 m long | N12 | Confirmed |
| R03 | Back row can see small parts on the bench "clearly" | N12 | Open: distance and smallest part size not given |
| R04 | Remote staff join by Teams and see the bench demonstration | N13 | Confirmed |
| R05 | Sessions are recorded | N14 | Open: operations manager and HR disagree |
| R06 | Windows and Mac laptops and phone video connect to the room | N16 | Confirmed |
| R07 | Existing 65-inch TV and Bluetooth speaker are removed and not reused | N15 | Assumed: "to be binned" suggests removal; who removes it is not stated |
| R08 | AV devices use the staff network through the front-wall ports, not guest Wi-Fi | N17, N18 | Assumed: never stated as a decision |
| R09 | No visible cables; plasterboard ceiling and painted block walls | N19 | Confirmed |
| R10 | One button starts a meeting, as in every room | N21 | Confirmed |
| R11 | Teams room accounts are created by client IT before commissioning | N22 | Assumed: "by next month" is not a date |
| R12 | Blinds are not fitted; display and camera positions depend on window glare | N20 | Open: who supplies the blinds, and when |
Two notes are not in the table on purpose. N23 and N24 sit in the constraints list: the budget of "around 25k for all four spaces" shapes the design but is not a requirement, and the training days decide when the installers can work. Putting a budget into scope text is a classic way to promise something the money cannot buy. The ceiling height in N20 is a room fact, so it travels to the designer's survey sheet instead of becoming a requirement.
Step 3: turn the open items into questions for the client
The Open lines are your list of things not to guess. Ask the assistant to rewrite each as a question a client can answer in a sentence, grouped by who answers, and to say what a wrong guess would cost. That last part orders the list by risk, so the expensive questions get asked first.
From the requirements record, list every Open line as a question for the client.
Group by who can answer: operations, IT, HR, management.
For each question write: the question in one plain sentence; the Req ID; what we would have to guess if it is not answered; and whether a wrong guess changes the design, the price or only the paperwork.
Do not suggest answers.In the example the list comes back with three questions. Recording (R05) is for HR and operations, and a wrong guess changes the design, because recording needs storage and a consent process. The back-row view (R03) is for operations: how far the back row sits from the bench and what the smallest part is, since a wrong guess changes display sizes and the camera. Blinds (R12) are for management or facilities: who supplies them and when, which affects display positions and the commissioning date. A call of about 20 minutes with the right people answers all three.
Step 4: draft scope lines from the confirmed items only
Only Confirmed lines become scope lines. Assumed lines become conditions, and Open lines stay as questions. Say so in the prompt, and tell the assistant where the designer's decisions begin.
Using ONLY the REQUIREMENTS RECORD below, draft scope-of-work lines for one space.
- Write scope lines only for requirements marked Confirmed. Start each with "Supply and install", "Provide", "Program", "Configure" or "Commission" and end with the Req IDs in brackets.
- Where the choice belongs to the system designer (display size and number, microphone and speaker layout, camera position, cable types and routes), write "sized by the designer" or "positions to be confirmed in the design" instead of choosing.
- Put each Assumed requirement into an ASSUMPTIONS list, worded as a condition ("The client will..."), with its Req ID.
- Put each Open requirement into QUESTIONS BEFORE DESIGN, with its Req ID.
- Add CLIENT RESPONSIBILITIES for anything the record says client staff must do.
- Do not add exclusions; they are chosen from our library later.
- Do not invent durations, quantities, prices or equipment.
REQUIREMENTS RECORD:
[paste]A first draft for the training room might look like this, with faults left in on purpose so you can see what checking looks like.
Scope lines. SOW-TR-01 Supply and install two displays at the front of the training room, sized by the designer to give a clear view from all 20 seats. [R01, R02] SOW-TR-02 Supply and install ceiling microphones and ceiling loudspeakers, with echo cancellation for conferencing calls, to cover the trainer and 20 seated participants. [R01, R04] SOW-TR-03 Supply and install one camera that shows the front bench to remote participants. [R02, R04] SOW-TR-04 Provide wired connections at the front bench for Windows and Mac laptops, and a wireless presentation option for laptops and phone video. [R06] SOW-TR-05 Conceal AV cabling in the ceiling void and walls as far as the construction allows. [R09] SOW-TR-06 Program one touch panel so that one button starts a meeting in the room, matching the other rooms. [R10] SOW-TR-07 Commission and test the system against the room test sheet, give one 90-minute training session to the trainers and issue the handover documents.
Assumptions. A1. The client removes the existing TV and speaker before installation and they are not reused. [R07] A2. AV devices use the staff network through the front-wall ports, with the third port activated by client IT. [R08] A3. Client IT creates the meeting-room accounts before commissioning. [R11]
Questions before design. Q1. Are sessions to be recorded, and who decides? [R05] Q2. How far is the back row from the bench, and what is the smallest part to be seen? [R03] Q3. Who supplies the blinds, and when? [R12]
Compare line SOW-TR-01 with what a lazy request produces. Leave out the "sized by the designer" rule and a draft can read "Supply and install two 86-inch displays and a ceiling microphone array with HDMI cabling". Every detail in that sentence is a design decision nobody has made, from the number of displays to the cable type.
Assumptions and client responsibilities written as conditions
An assumption is only useful if it says what happens when it turns out to be false. Pair each one with a responsibility, a date and a consequence, so the client can see the cost of delay in advance rather than argue about it afterwards. The table is filled in for the example; dates are placeholders.
| Condition | Source | Needed by | If it is late |
|---|---|---|---|
| Client removes the old TV and speaker | R07, N15 | Installation start | Removal and disposal are quoted as an extra, or the install date moves |
| Client IT activates a third network port at the front wall and permits the AV devices on the staff network | R08, N17, N18 | Two weeks before installation | Network-dependent items cannot be commissioned; a return visit is chargeable |
| Client IT creates the meeting-room accounts | R11, N22 | Before commissioning | Conferencing tests wait; the handover date moves |
| Client confirms the blinds supplier and fitting date | R12, N20 | Before display positions are fixed | Display and camera positions may change after installation |
| Client keeps installation to Fridays and weekends | N24 | Agreed schedule | Weekday work in training time is not possible |
The last row follows from the constraints list. If training runs Monday to Thursday, the installers can only work on Fridays and at weekends, and that affects labour cost. An assistant will not make that connection unless a rule tells it to look at constraints when it drafts the schedule line, so add the rule or check by eye.
What the system designer checks before the scope goes out
The designer owns the technical truth. They take the draft scope and the notes and test each line against the room, the equipment and the cabling. Give the designer the draft with each line numbered so they can mark it as Verified, Corrected, or Cannot verify until the survey. The areas below are the ones that matter in this room.
| Area | What the designer verifies | What it meant for the example |
|---|---|---|
| Display size, number and position | Sizes the displays for the back row using the contract's method; AVIXA publishes a display image size standard, Display Image Size for 2D Content (V202.01), and a free online DISCAS calculator for checking conformance. Checks positions against sight lines | The draft said "two displays", though no note gave a number. The designer removes "two" until the room length and back-row distance are known (Q2) |
| Audio coverage | Chooses the microphone and speaker layout for 20 seated people and a trainer who moves around the bench | The plasterboard ceiling needs checking for fixings and void depth, so the line cannot be verified until the survey |
| Camera and bench view | Camera position, field of view, lighting and privacy | The mount depends on the ceiling, so two options go to the client |
| Cabling routes | A concealed route for every signal and power cable, and whether painted block walls need chasing | "No cables on show" implies chasing; building work and making good are excluded unless priced, so the client decides |
| Cable types and lengths | Cable type for each signal, and each run against the manufacturer's stated maximum length for the resolution in use; extender or network-based transport where a run is too long | A 14 m run from the bench to the rack is checked against the cable maker's data, not assumed to work with plain HDMI |
| Power | Socket positions, loads and who supplies new circuits | The notes say nothing about sockets at the front wall, so the designer adds a survey question and a client-side item if none exist |
| Network | Ports, power over Ethernet budget, VLAN, bandwidth for calls and recording, and firewall rules for the conferencing service | The third port is dead; assumption A2 stays assumed until IT confirms |
| Control and platform | The single start button across rooms, room accounts and calendars | Accounts due "by next month" become a dated responsibility |
| Recording and consent | Not a design question. Consent and storage rules come from the client's HR and legal advisers | Stays Open until the client decides; the design leaves room to add recording later |
| Lead times and install windows | Availability of the chosen equipment against the Friday and weekend install windows | Longer lead-time items are ordered first |
On the draft above, the designer marks four lines Corrected, two Verified and one held until survey. SOW-TR-01 is corrected as described. SOW-TR-03 is corrected because the number and position of cameras are design decisions, so the line now reads "camera number and positions to be confirmed in the design". SOW-TR-05 is corrected by adding an exclusion for chasing and making good, and a question to the client. SOW-TR-07 is corrected because "90-minute training session" came from nowhere in the notes; use the figure from your own exclusions library instead. It also carries no Req ID, and a line with no source is a warning sign in its own right. SOW-TR-04 and SOW-TR-06 are verified, and SOW-TR-02 waits for the ceiling survey.
Keep the designer's marks in the document, with initials and a date, and issue the scope as version 0.2. The marks are what let you answer, months later, who verified the cabling lengths and when. The designer also gets one more output from the assistant: a check sheet listing each scope line with a blank Verified, Corrected or Cannot verify column. The assistant prepares the sheet; the designer does the checking.
Checking equipment and cabling lines against the manufacturer's data
The designer's most reliable habit is to compare each equipment and cable line with the manufacturer's own documents. For every device, check supported resolutions, connections, power draw, mounting weight and any stated limits. For every cable run, check the type, the route length from the drawing and the manufacturer's maximum for the signal in use. Where the run exceeds the maximum, the design changes, not the sentence.
A realistic slip shows why the AI cannot do this part. Suppose a draft lists "HDMI cabling" for all connections. The designer measures a 14 m route from the bench to the rack. Suppose the maker's data sheet states a maximum run shorter than that for 4K over a plain cable. The line then becomes an extender or network-based video transport, with its own power and network needs. The scope then picks up a network port requirement and a power requirement that nobody wrote down, and both flow into the client responsibilities table above.
Notes that disagree, and other awkward discovery
Two stakeholders disagree. The recording question (R05) is the example. Do not let the draft choose. Put both statements side by side in the question, send it to whoever has authority, and record the decision with name and date. Suppose the answer comes back as "no recording at launch, but leave the option open". R05 then becomes a scope note ("the design allows recording to be added later") plus an exclusion for recording equipment, storage and any consent process.
"Make it work with everything." Convert the wish into a list of the devices and platforms in use today, which is what N16 did, and test those at the survey. "Everything" is not testable, and a scope line has to be.
Remote discovery with no site visit. Mark dimensions, ceiling construction, power and network conditions as assumptions, and add a scope line that the design is subject to a site survey. The designer's marks will say Cannot verify more often, and that is the honest answer.
Reused equipment. Record what exists and test it at the survey. The scope should state that reused items are accepted as found, and the assistant should not describe their condition.
Phased projects. Write a separate scope for each phase with its own assumptions, and ask the designer to confirm that phase one does not block phase two.
Returning the record to the client for confirmation
Before the scope is final, send the client the requirements record, not the scope: the table with statuses and the questions. A short table is easier for a client to answer than a long document is to read. Ask them to confirm the Confirmed lines, answer the Open lines and correct anything wrong. Record each decision in a log, as in this filled-in example.
| Req | Decision | Decided by | Effect on the scope |
|---|---|---|---|
| R03 | Back row is 7.5 m from the bench; smallest part is about 30 mm across | Operations manager | Designer sizes displays and the bench camera view from these figures |
| R05 | No recording at launch; option kept open | Operations manager with HR | Recording becomes an exclusion; the design leaves room for it |
| R12 | Client buys and fits the blinds before commissioning | Management | Added to client responsibilities with a date |
With the three open items closed and the designer's corrections made, the scope becomes version 1.0. Every line is testable: the commissioning checklist and sign-off sheet are built from these lines, so a line you cannot test is a line to rewrite. If you capture notes by voice rather than typing, turning voice notes into job sheets covers the dictation habits, and the Step 1 numbering still applies. For the room-by-room habit in another trade, see drafting a bathroom renovation scope room by room.
Timing the method against your usual routine
Time the method once against your usual routine for a four-space project, replacing these example figures with your own.
| Step (four spaces) | Usual routine | With this method |
|---|---|---|
| Number and tidy the notes | None | 20 minutes |
| Requirements record | 60 minutes | 30 minutes (10 for the AI run, 20 to check) |
| Questions for the client | 25 minutes | 15 minutes |
| Scope lines, assumptions, responsibilities | 90 minutes | 35 minutes |
| Designer's check | 30 minutes, informal | 45 minutes, line by line |
| Total | 205 minutes | 145 minutes |
The saving is an hour, and the more important change is that the designer's check grows by 15 minutes and becomes a recorded step. Track four things across your next few projects: open items closed before design starts, scope lines the designer corrected, change orders traced to an unclear scope line, and requirements the client added after confirming the record. If the last two stay high, the discovery questions are too thin. Add the questions that would have caught each late change to your standard list, and the next set of notes starts better than this one did.
Questions about AV scope of work and discovery notes
What is the difference between a scope of work and a proposal?
The scope of work says what will be delivered, room by room, with assumptions, exclusions and client responsibilities. The proposal wraps it with prices, terms and an acceptance step. Some integrators agree the scope first and attach it to the proposal; others write both together. Either way, every priced line should trace back to a scope line.
Can AI read handwritten site notes and call recordings accurately?
It can often read neat handwriting from a photo and produce a transcript from a recording, but numbers are where both go wrong: a 2.1 can become a 2.7. Type or re-check every dimension against the tape, and get consent from everyone on a call before an AI notetaker joins it.
Should the client see the requirements record?
Yes, in a clean version. Send the table of requirements with their status and the questions, and ask the client to confirm or correct it. Leave out your internal comments about people and budgets. A client who has confirmed the record in writing finds it much harder to say later that nobody mentioned something.
Is it safe to put discovery notes into a free chatbot?
Take care. Notes can hold names, network details, security arrangements and budgets. Use a business plan, which does not train on your content by default, or switch off the model-training setting on an individual plan, and remove names and network details you do not need. Never paste passwords or access codes.
Further reads
- AV Service Agreements: Support Terms and Renewals Drafted With AI — Support terms and renewals once the system is handed over.
- AV Integrator Software: Quotes, Projects and Service, AI Compared — Software for quotes, projects and service, with AI compared.
- How to Turn Meeting Notes Into Tasks Automatically With AI — Turning meeting notes into tasks and owners.
- AI Tools and AI Development: The Complete 2026 Guide — the AI hub, including every tutorial in the AI-for-business series.
Sources: AVIXA standards and published-standards pages, which list the Display Image Size for 2D Content standard (V202.01) and link its DISCAS calculator (read October 2026).