Nora's Runbook

Needs
- A way to receive crew lead texts (a shared inbox or messaging bridge the agent can read).
- The job schedule with crew assignments, customers and addresses, plus a source of drive times.
- A Slack channel for dispatch.
- Ask your person for crew membership, working hours and which job types can move between crews.

Build
1. Trigger on any crew lead text that reports someone off sick tomorrow.
2. Read tomorrow's schedule for that crew, the other crews' open slots and drive times between sites.
3. Instruct the model: "Rebuild tomorrow's routes with the fewest moves. Keep jobs on their promised day where possible, never overload a crew, and list every customer whose promised time changes."
4. Post the plan to the dispatch channel within ten minutes: jobs moved, jobs unchanged, customers needing a call, with Accept and Edit options.
5. Change the schedule or contact any customer only after the dispatcher accepts. Close the item when they accept or edit.

Check
- The first plan should list moved jobs, an unchanged count and the customers to call. Test with a made-up sick call and confirm no job is double-booked.

Needs
- Timesheets with hours per job, the original quoted hours per job, and crew lead notes.
- A scheduler that can run daily and send email.
- Ask your person for the recipients (themselves and the ops manager) and the threshold (default 80%).

Build
1. Schedule a run every day at 2pm.
2. Read hours used and hours quoted for every open job, and the latest crew lead note.
3. Keep only jobs where hours used exceed 80% of hours quoted.
4. Instruct the model: "For each job give hours used against quoted, quote the lead's last note, and suggest one action before the quote is exhausted."
5. Send one short email to the two recipients. If no job passes the threshold, send nothing.
6. The email is a report only. It never contacts customers.

Check
- The first email should list job, hours used of quoted, the note and a suggestion. Test by lowering the threshold to confirm a known near-limit job appears.

Needs
- Access to the job schedule, timesheets and a weather forecast by site address.
- A way to text your person's phone.
- Ask your person for the crew list, what counts as weather risk (default: rain above 60% chance, wind above 40 km/h, frost) and their phone number to text.

Build
1. Schedule a run on weekdays at 6:30am.
2. Read yesterday's jobs still marked unfinished, today's sites with forecast, and each crew's headcount against its planned headcount.
3. Instruct the model: "Write a one-page brief: unfinished jobs from yesterday, sites at weather risk today with the reason, and crews that are short. Plain words, nothing else."
4. Text it to your person only. Do not send it to anyone else.

Check
- The first text should have three short sections and fit on one screen. Test by comparing it with the schedule for a day you know had a short crew.

Needs
- A review tool that lets the agent read new reviews and save drafts without posting.
- Past replies as examples of tone, and the job record for each review.
- Ask your person for a tone sample and any topics that must not be answered by draft (default: refunds and legal complaints).

Build
1. Schedule a run every morning.
2. Read each new review and the matching job record.
3. Instruct the model: "Reply in the voice of the past replies. Thank the customer, address what they raised using the job record, and keep it under 80 words. Do not promise compensation."
4. Save each reply as a draft in the review tool.
5. Nothing is posted until your person approves each draft.

Check
- The first morning should show one draft per new review, none posted. Test with a negative review and confirm the draft stays calm and makes no promises.

Needs
- Read access to your person's email, texts and call notes.
- A Notion page the agent can edit.
- Ask your person which senders to ignore and what phrases count as a promise (default: "I'll get back to you", "I'll send", "I'll call").

Build
1. Schedule a run every 30 minutes over new messages and notes.
2. Instruct the model: "Find commitments your person made to a customer or crew that are still open. Record who, what, and the date promised."
3. Add each to a pinned Notion page with a count of days open, oldest first.
4. Mark an item closed when a later message shows the promised thing was sent.
5. The agent only records. It never sends anything.

Check
- After a day, the page should show real promises with days counted. Test by sending a promised item and confirm the entry closes on the next run.

Needs
- Booking history by customer with dates and season.
- Text history, and a Notion list.
- Ask your person for a tone sample for texts and how long counts as quiet (default: no booking in the usual season window plus 4 weeks).

Build
1. Schedule a run on Mondays at 8am.
2. Find customers who book most seasons but have not booked this one. Take at most ten, the longest quiet first.
3. Instruct the model: "Draft a short, warm check-in text that mentions their last job and asks if they want a booking. No discounts."
4. Write the list to Notion with each draft beside the customer.
5. Nothing is texted. Your person sends or edits each one. Remove an entry when the customer books or is dismissed.

Check
- The first list should hold up to ten customers with a draft each. Test that a customer who booked last week is absent.

Needs
- Supplier price lists in a readable form each week, with last month's saved for comparison.
- A scheduler that can send email.
- Ask your person for the recipients (themselves and purchasing) and the threshold (default 5%).

Build
1. Schedule a run on Fridays at 4pm.
2. Read this week's price lists and the copy from about four weeks ago, matching materials by name and unit.
3. Keep materials whose price moved more than 5% either way.
4. Build a table: material, old price, new price, percentage change, and the cheaper supplier.
5. Email the table to the two recipients. It is a report only. No orders are placed.

Check
- The first email should hold a table sorted by size of move. Test with a material you know changed and confirm it appears with the right percentage.

Needs
- Job records, customer reviews and callback logs per crew lead.
- Email drafting access.
- Ask your person for the list of crew leads and a tone sample (default: direct and encouraging).

Build
1. Schedule a run on Fridays at 5pm.
2. For each lead, collect jobs finished that week, callbacks and customer comments.
3. Instruct the model: "Write a one-page week in review for this lead: jobs finished, callbacks with the cause if known, and customer comments quoted. Be fair and specific."
4. Save each as an email draft addressed to the lead.
5. Your person reads and sends each one. Nothing goes without that.

Check
- The first run should produce one draft per lead. Test by checking a lead's job count against the schedule.

Needs
- Calendar access and a place where your person records three priorities on Monday.
- A way to text your person.
- Ask your person for where the priorities are stored.

Build
1. Schedule a run on Sundays at 7pm.
2. Read the coming week's calendar and Monday's three priorities.
3. Instruct the model: "Compare the calendar with the priorities. Say how much time each priority has and name the one meeting most worth dropping, with the reason."
4. Text the result to your person only. Do not cancel or decline anything.

Check
- The first text should show each priority with its time and one meeting to drop. Test with a week where a priority has no time booked.

Needs
- A custom GPT or equivalent that accepts photos and a voice note.
- The price list and a quoting tool that takes drafts.
- Ask your person for labour rates, markup and standard line items.

Build
1. Trigger when an estimator uploads site photos and a voice note.
2. Transcribe the note and read the photos.
3. Instruct the model: "Produce a line-item quote using only the price list. Give hours and materials per line. List anything not visible in the photos as something to check on site."
4. Save it in the quoting tool as a draft marked prices unchecked.
5. The estimator checks every price before anything reaches the customer.

Check
- The first draft should have itemised lines and a check-on-site note. Test with a job that has hidden work and confirm it is flagged.

Needs
- Access to the morning brief's rules and the last week of briefs.
- Claude Code or a similar coding agent with edit rights to the brief's rules.
- A way to text your person.

Build
1. Trigger when your person replies to the brief describing an error.
2. Read the reply and the last seven days of briefs.
3. Instruct the agent: "Find the rule that caused this mistake and propose a corrected rule. Do not change anything else."
4. Re-run the last week's briefs with the new rule and compare against the originals.
5. Make the rule live only if the mistake is gone and nothing else changed. Then text your person that it is live.

Check
- The text should say what changed. Test by replaying a brief that contained the known error.

Needs
- A voice-capable chat assistant.
- Ask your person for a summary of the complaint, what the customer wants and what they can offer.

Build
1. Start a voice chat when your person asks to rehearse.
2. Instruct the model: "Play the customer in this complaint for five minutes. Be firm and realistic, and stay in character. Do not make it easy."
3. After five minutes, stop and review the conversation.
4. Pick the three points your person handled worst, with a suggested better line for each.
5. Draft the email to your person only.

Check
- The email should list three points with a better line each. Test with a complaint you know well and see whether the criticism is fair.