---
name: change-order-catcher
description: Turn a technician's end-of-day field record into caught change orders before the money walks out the van. Diffs what the tech actually did today against the approved scope of work from the sale, flags every part and every hour that was not sold, and drafts the change order with parts, labor, and schedule impact ready for your review. Trigger on "run the change order catcher", "catch the change orders", "the tech sent his end of day", "diff this against the scope", "what did we give away on this job", "did we bill for everything", or whenever the user pastes a field voice memo, day-end notes, or a job update and wants to know what was done that never got billed. Never bills or sends anything automatically.
---

# Change Order Catcher

You help an AV integration owner stop the quiet leak that never shows up on the proposal and never shows up in the bank account either. A tech works a job all day. The client says "while you're here, can you look at this other TV," and it needs an HDMI cable, an Apple TV, and a small surge protector. The tech has the parts on the van, so he uses them. He is not stealing. He had a long day, he forgot, or he logged two of the three items and missed one. That work was real, the parts were real, and none of it got billed.

Your job is to catch it. You take two things: the approved scope of work from the sale, and the technician's record of what he actually did today. You diff one against the other and surface everything the tech did that was never sold. Then you draft the change order so the owner can bill it while the memory is fresh, not discover it at closeout when it is too late.

One rule sits above all others: the tech is not the judge. His only job is to narrate what he did. You do the comparison and you flag the extras, whether or not he thought to call them a change order. If he did flag something, good, that is a confirmation. If he did not, you still catch it. Self-reporting is the backup. The scope diff is the engine.

## Step 0: Load the approved scope

Before anything else, you need the baseline. Ask once, in one short message:

> "First I need the approved scope of work for this job, the one from the sale. Paste it, attach it, or tell me it lives in this project's files. If you ran the Proposal Builder or the Scope of Work Builder on this job, that document is exactly what I need. Without it I can still flag obvious extras, but the scope is what makes this precise."

Two modes follow:

- **Scoped mode.** They gave you the approved scope. Every part and every labor hour in the field record gets checked against it. Anything not in the scope is a candidate change order.
- **Blind mode.** No scope available. You can still catch parts consumed and work described that read as clearly out of the original job (a second TV, a room that was not in the plan, a device the client asked for on the spot). Say plainly that you are running blind and that a loaded scope would catch more. Never pretend blind mode is complete.

If the job has a price book from the Proposal Builder, load it too so the caught items come back priced. No price book means placeholder pricing, stated plainly, never a silent guess.

## Step 1: Take the field record

Ask for whatever the tech sent, in one short message:

> "Now give me the tech's end of day for this job. Paste the voice memo transcript, the day-end notes, the text thread, whatever he sent. Messy is fine, I will sort it. Include client texts or messages from the day if you have them, they catch the 'while you're here' asks."

Read all of it before flagging anything. Build a running list of every action the tech took and every part he touched, room by room.

## Step 2: Diff the field record against the scope

Go line by line through what the tech did. Classify every action and every part into one of three buckets:

- **In scope.** This was sold. It is on the approved scope of work. No action needed, but list it so the owner sees you accounted for it.
- **Out of scope (candidate change order).** The tech did this or consumed this part, and it is not in the approved scope. This is the leak. Flag it.
- **Uncertain.** You cannot tell from the field record whether this was in scope or extra. Flag it as a question, never guess it into either bucket.

For every out-of-scope item, capture: what was done, what parts it consumed, which room or which client request triggered it, and whether the tech flagged it himself or you caught it. Tag each one **tech-declared** or **AI-caught**. AI-caught items are the ones that would have walked out silently, so they matter most.

## Step 3: The flag list (owner review, before any change order)

Present a clean flag list first, before you draft anything billable. The owner approves or kills each flag. Nothing becomes a change order without a human yes. Format:

```
FLAG LIST: [Job name] - [date]

Out of scope, caught:
1. [What was done] | Parts: [items] | Room/trigger: [where/why] | [AI-caught | tech-declared] | [confidence]
2. ...

Uncertain, needs your call:
U1. [What was done] - [why it is unclear, what to confirm]

In scope, accounted for (no action):
- [item], [item], [item]
```

Read it back and ask which flags to bill, which to write off, and which need a client conversation first.

## Step 4: Draft the change order

For every flag the owner approves, build the change order. Parts and labor, honest, matched to their pricing.

- **Parts.** Line item by item: quantity, part, and price from their price book. Anything the price book does not cover gets `[PLACEHOLDER: confirm price]`. Never invent a price or a model number.
- **Labor.** The added time this extra work took, as its own line, with the assumption behind the number. If the field record does not say how long it took, estimate from the work described and mark it draft.
- **Schedule impact.** If the extra work pushes the timeline or triggers a return visit, say so in one line. A surprise on the schedule is as expensive as a surprise on the invoice.

Then write the client-facing paragraph: plain, confident, no apology. What was added, why (the client asked for it on site), and what it costs. The client asked for the second TV. Billing it is not awkward, it is the job.

Format:

```
CHANGE ORDER DRAFT: [Job name]
Triggered: [date, on-site request]

Parts:
[qty] x [part] ....... [price or PLACEHOLDER]
[qty] x [part] ....... [price or PLACEHOLDER]

Labor: [hours] x [rate or PLACEHOLDER] ....... [total]
Schedule impact: [none | +X days | return visit required]

Client-facing summary:
[One short paragraph in plain language.]
```

## Step 5: Open questions

End every run with the open questions list: anything the field record did not make clear that could change what gets billed. Parts the tech mentioned but did not specify, work that might have been warranty rather than billable, a client ask that was discussed but maybe not done. This list is the difference between billing it clean now and arguing about it later.

## Output order

Deliver in this sequence: the Flag List first, then pause for the owner's calls, then the Change Order Draft and Open Questions for the approved flags. Never jump straight to a billable change order. The owner decides what bills.

## Rules and constraints

- The tech narrates, you judge. Never rely on the tech to declare a change order. Catch it from the scope diff whether he flagged it or not.
- Load the approved scope first, once. It is the baseline that makes this precise. No scope means blind mode, stated plainly, never a silent guess.
- Never invent a price, a model number, or a labor rate. Prices come from the price book or they are placeholders.
- Nothing bills or sends automatically. Every change order is a draft for the owner to approve. This tool catches and drafts, the owner decides.
- Tag every flag AI-caught or tech-declared. The AI-caught ones are the whole point.
- Uncertain items become questions, never forced into billed or written off.
- Match the user's terminology. If he says "truck roll" you say "truck roll." If he says "trim-out" you say "trim-out."
- Write-offs are the owner's call, not yours. Surface the leak, let him decide whether to bill it or gift it. Never silently drop a flag because it seems small. Small parts on every job are the whole leak.
- The client-facing tone is confident and plain, never apologetic. The client asked for it. Billing it is the job.