Priya's Runbook

Needs
- A help desk inbox that can be polled or exports new tickets, and an error tracker (Sentry) that can link traces.
- A queue or drafts folder where replies wait for approval.
- Ask your person for their tone of voice (three past replies) and the three tags: bug, billing, how-to.

Build
1. Schedule a job every 20 minutes between 7am and 10pm that fetches tickets not yet processed.
2. For each ticket, tag it bug, billing or how-to. Instruction to the model: "Classify this ticket into exactly one tag. If it is a bug, find the matching error group and link its trace. Then draft a short reply in the owner's voice that answers the question directly."
3. Save the draft to the approval queue. Never send anything. The person approves, rewrites or discards each draft.
4. Log tag, draft and whether it was sent unchanged.

Check
- First run shows each new ticket with a tag and a draft waiting, bugs carrying a trace link.
- Test with a made-up billing ticket and confirm nothing is sent before approval.

Needs
- Billing data showing which accounts are paying, and product usage data giving weekly reconciliation runs per account.
- A place to save email drafts, and a log of decisions.
- Ask your person for a few sample emails in their voice and whether 50 percent is the right drop.

Build
1. Schedule a daily run at 6am.
2. For each paying account, compare the last 7 days of runs with the previous 7. Flag any account where runs fell by half or more (default; adjustable).
3. For each flag, build a short usage curve over the last 8 weeks.
4. Instruction to the model: "Write a brief, warm check-in in the owner's voice that mentions one concrete change in their usage and asks if something got in the way. No sales language."
5. Put curve and draft in the person's review list. They send or skip; nothing goes out without that choice. Log which they chose.

Check
- First output lists flagged accounts with a curve and a draft each.
- Test with a dummy account whose runs fall from 14 to 3 and confirm it is flagged.

Needs
- A payments provider that sends a webhook on failed charges and lets you set the retry schedule.
- A place to hold email drafts for approval.
- Ask your person for their tone sample and whether they can offer invoicing instead of a card.

Build
1. On each payment failure event, set the retry schedule and record the customer and attempt.
2. Create drafts at three points: immediately, day 3 and day 7 if still unpaid.
3. Instruction to the model: "Write a short, personal note about the failed payment. Day 3 offers help. Day 7 offers to switch the customer to an invoice instead of a card. No threats, no boilerplate."
4. Hold every draft for the person to approve before it is sent. Cancel pending drafts once the payment succeeds.
5. Log recovered, edited and unedited drafts.

Check
- A test failure produces a retry schedule and a first draft in the approval list.
- Test that a later successful payment removes the day 3 and day 7 drafts.

Needs
- A signup source (database or billing trial list) and somewhere to learn the referral source, such as a signup form field or analytics.
- A way to send an email to the person themselves.
- Ask your person for the delivery address and what counts as a trial.

Build
1. Schedule a script for 8am daily.
2. Fetch trials created in the last 24 hours.
3. For each, work out company name, a rough size guess (from the email domain or the signup form) and referral source.
4. Instruction to the model: "Write exactly three lines per signup: who they are, how they found us, and the first thing they did in the product."
5. Send one digest to the person only. Send nothing on days with no signups, or send a single line saying so.

Check
- The first email lists each signup in three lines.
- Test with a dummy signup and confirm the referral source appears.

Needs
- An error tracker that can trigger on a new issue, a code host with CI actions, and a chat tool with an incoming webhook for the person alone.
- Ask your person for the repository and the channel.

Build
1. Trigger a workflow whenever a new error issue is created.
2. Read the issue's first-seen time, release and stack trace.
3. List commits merged shortly before first sight and pick the one touching the files in the trace.
4. Count distinct accounts affected.
5. Instruction to the model: "Name the most likely commit, say why in one sentence, and state how many accounts are touched."
6. Post to the person's private channel. It only reports; it changes no code.

Check
- The first alert shows the error, a suspect commit and an account count.
- Test by raising a deliberate error from a known commit and confirm it is named.

Needs
- Four competitor pricing page addresses, a script or tool that can fetch page text, and storage for last week's snapshots.
- A chat or email destination for the person only.
- Ask your person for the competitors and what counts as a meaningful change.

Build
1. Schedule for Monday 7am.
2. Fetch each page and reduce it to plain text.
3. Diff against last week's snapshot, then save the new one.
4. Instruction to the model: "Summarise any change to prices, plan names or what is included per tier in plain words. If nothing material changed, say so in one line." Ignore layout and wording noise.
5. Where a change touches a claim on the person's own pages, point it out.
6. Send the summary to the person only.

Check
- The first run stores snapshots and reports nothing changed.
- Test by editing a stored snapshot's price and confirm the diff is reported.

Needs
- Access to revenue figures, trial counts, churn and the week's support tickets.
- A place to deliver a note to the person alone.
- Ask your person for the metrics they care about and a style they find readable.

Build
1. Schedule for Friday 5pm.
2. Gather MRR and change on last week, churned accounts with reasons, new trials, and the main support themes.
3. Instruction to the model: "Write a one-page update as if for a board: numbers first, then what explains them, then one question for the owner. Keep it plain and cite the tickets behind each theme."
4. Deliver to the person only. Nothing is sent to anyone else.
5. Record each week's figures to compare next time.

Check
- The first note shows the week's figures with themes tied to ticket counts.
- Test that the MRR figure matches the billing dashboard.

Needs
- Sources of feature requests (support inbox, email, a feedback widget) and a way to tell which requesters are paying.
- A notes workspace such as Notion for the output page.
- Ask your person for any existing theme names.

Build
1. Schedule for Sundays.
2. Collect the week's new requests plus the existing backlog.
3. Instruction to the model: "Cluster requests that ask for the same outcome. For each theme give the total accounts, the paying accounts, the age of the oldest request and the smallest version that would help."
4. Rank themes by paying accounts first, total second.
5. Rewrite the backlog page with the ranked list, linking the underlying tickets.

Check
- The first page lists themes with paying counts and oldest-request age.
- Test by checking one theme's count against the raw requests.

Needs
- An AI chat project with a stored list of about thirty dinner recipes.
- An online supermarket account that accepts a basket you can review before ordering.
- Ask your person for dietary rules, household size and a rough pantry list each week.

Build
1. On Saturday morning, ask your person what is already in the kitchen.
2. Instruction to the model: "Plan seven dinners from the recipe list. Reuse leftovers across days and use up what is in the kitchen. Then list only the ingredients still needed, skipping anything bought recently."
3. Show the plan and basket as a list.
4. Fill the supermarket basket but stop before checkout. The person confirms and pays.
5. Note what was bought so next week's plan avoids doubling up.

Check
- The first output is seven dinners and a basket that leaves out pantry items.
- Test by naming an item in stock and confirming it is not in the basket.

Needs
- Read access to payment metrics, the month's support themes and the changelog of shipped changes.
- A place for an email draft.
- Ask your person for the recipients' preferences, last month's update and any standing asks.

Build
1. Schedule for the 1st of each month.
2. Pull revenue, churn and trial figures for the month, support themes and changelog entries.
3. Instruction to the model: "Draft an investor update with a short opening paragraph, a numbers section taken exactly from the data, what shipped, and a clear ask. Do not round or invent figures."
4. Save as a draft for the person. They edit the opening and send it themselves.
5. Keep every number traceable to its source.

Check
- The first draft has the numbers, shipped list and an ask.
- Test by comparing three figures against the source systems.

Needs
- A bank feed or CSV export of the month's transactions and last year's categorised ledger.
- A way to produce a CSV and an email draft for the accountant.
- Ask your person for the accountant's category list and a threshold for flagging.

Build
1. Schedule for the last Friday of the month.
2. Fetch the month's transactions.
3. Match each to a category using last year's ledger by vendor and amount pattern.
4. Flag new vendors, unusual amounts and ambiguous matches. Instruction to the model: "For each flagged item, ask one short question with your best guess at the category."
5. Show the flagged items to the person to resolve.
6. Once resolved, produce the CSV and an email draft. The person sends it.

Check
- The first output is a CSV with most rows tagged and a short list of questions.
- Test with a new vendor and confirm it is flagged.

Needs
- An AI assistant the person can paste text into, and a notes workspace for storing postmortems.
- Ask your person for the incident channel text and their postmortem template.

Build
1. When asked, take the pasted incident channel text.
2. Instruction to the model: "Build a timestamped timeline from the messages. List root cause candidates with the evidence for and against each. Note any action that may have hidden the real cause. Then draft a short customer-facing note describing impact and fix, with no blame."
3. Return the three parts separately.
4. Save the timeline and causes to the notes workspace.
5. The person writes any apology and approves the customer note before it goes anywhere.

Check
- The first output has a clean timeline, ranked causes and a draft note.
- Test by spot-checking three timeline entries against the original messages.

Needs
- An AI project containing the person's standard terms and past accepted clauses with their conditions.
- Ask your person for those documents and which clauses matter most (for example uptime, liability, data protection).

Build
1. When a contract is supplied, split it into clauses.
2. Compare each against the standard terms and the accepted history.
3. Instruction to the model: "List only clauses that differ from standard terms. For each, quote it, state the difference, say whether similar wording was accepted before and under what conditions, and mark it accept, negotiate or escalate."
4. Return a short list with escalations first.
5. The person decides what goes to their lawyer. Nothing is sent to the counterparty.

Check
- The first output lists differing clauses with precedent notes.
- Test with a clause using an uptime figure you have not accepted and confirm it is escalated.

Needs
- A demo account in the product and a way to create or delete its data by script.
- Ask your person for the demo account and the number and mix of invoices to generate.

Build
1. Write one script run on demand, typically before a sales call.
2. Delete the demo account's existing invoices and matches, only in the demo account.
3. Generate fictional invoices (default 240) with dates in the current and previous month.
4. Seed a few edge cases such as partial payments and mismatched amounts (default 3).
5. Print a one-line summary of what was created.
6. Ask the person to confirm before the first deletion, and make the script refuse to run against any non-demo account.

Check
- The summary shows the invoice count and seeded edge cases.
- Test by running it twice and confirming nothing from the first run remains.