Sade's Runbook

Needs
- An Airtable base holding applicants (CV text, source) and open briefs (must-haves, nice-to-haves, deal-breakers).
- A ChatGPT project with the briefs loaded.
- Ask your person for the scoring scale (default 1 to 5) and the score below which a decline is clear (default 2).

Build
1. Schedule an Airtable automation every 2 hours on working days, picking up applicants with no score.
2. Send each CV and the open briefs to the ChatGPT project. Instruction: 'Score this CV against each open brief from 1 to 5. Give two lines of reasoning that cite the brief's must-haves. Name the best-fitting brief, or say none.'
3. Write score, reasoning and best brief back to the applicant record.
4. For scores at or below the threshold, draft a decline that mentions something specific from their CV. Save it as an email draft only.
5. Your person reads every score and approves each decline before anything is sent or any stage changes.

Check
- The first run should show scored records with two-line reasoning and drafts for the clear misses only.
- Test with one CV you know is a poor fit and confirm a decline draft appears but is not sent.

Needs
- An Airtable base with interviews (date, candidate, client contact, feedback status).
- Access to the inbox to read hiring-manager replies and save drafts.
- Ask your person for the chase wording style and the three warmth levels, plus the 48-hour wait (default).

Build
1. Schedule an Airtable automation for 9am daily. Find interviews older than 48 hours with no feedback recorded.
2. Draft a chase per interview. Escalate with the chase count: first is friendly, second is direct, third states that the candidate has other processes moving and a quick no is better than a late yes. Instruction: 'Write three sentences, polite, specific to this candidate and interview date.'
3. Save chases as drafts. Your person approves each before it goes.
4. When a reply arrives, extract the feedback into the interview record (verdict, reasons, next step).
5. Create a candidate-update draft from the extracted feedback. Your person approves and sends it.

Check
- A day with a stale interview should produce one chase draft and nothing sent.
- Test by adding a fake reply and confirm the feedback fields fill and an update draft appears.

Needs
- A ChatGPT project with web browsing for public sources.
- Access to the calendar or ATS for interviews booked tomorrow, including panel names and the candidate.
- Ask your person for each client's usual three interview questions and the pack format they prefer.

Build
1. At 6pm each day, list interviews happening the next day. Skip the run if there are none.
2. For each, collect the panel names, then search public sources only (company site, talks, public profiles) for their backgrounds and the team's tech stack.
3. Instruction to the model: 'Write a one-page prep pack for this candidate: who is on the panel and one line on each background, the team's stack, the three questions this client always asks, and one practical tip per panellist. Mark anything you could not verify.'
4. Save the pack as an email draft from your person to the candidate.
5. Your person reads and approves every pack before it is sent.

Check
- The first pack should name each panellist with a sourced detail and flag gaps.
- Test with an interview where one panellist has little public presence and confirm the pack says so rather than guessing.

Needs
- An Airtable base with past candidates, the process they reached, outcome and the date.
- A ChatGPT project and the inbox for saving drafts.
- Ask your person what counts as a strong runner-up (default: reached final stage, rated 4 or above) and for a tone sample.

Build
1. Every Tuesday morning, filter candidates who finished as runner-up between 5 and 7 months ago and rated strong.
2. Pull their process notes: client, role, what they liked and disliked, and any open roles that fit now.
3. Instruction to the model: 'Draft a short check-in that refers to their actual process and, if an open role fits, names it and why. Never write hope you're well. Under 90 words, in this tone sample.'
4. Save each as an email draft and list them in a review view.
5. Your person approves, edits or skips each draft. Record sent and replied in Airtable.

Check
- The first run should give a short list of drafts, each mentioning a specific past process.
- Test that a candidate outside the 5 to 7 month window does not appear.

Needs
- A list of people on active shortlists, with names, employers and the brief each belongs to (from the applicant tracker).
- A ChatGPT project with web browsing.
- Ask your person which public sources are allowed (default: conference programmes, code repositories, company announcements) and to confirm personal social accounts are out of scope.

Build
1. Every Friday, load the active shortlists.
2. For each person, search the allowed sources for the past week: talks, open-source releases, promotions or job moves.
3. Instruction: 'Report only public, verifiable activity with its source and date. Explain in one line how it connects to their brief. If nothing is found, say none.'
4. Write hits into the candidate record with the source noted, so outreach can say where it was seen.
5. Do not send outreach. Your person decides which hits go into messages and approves each message.

Check
- The first output should be a short list of hits with sources, and no entry for people with no findings.
- Test by checking that every hit has a source your person can open and confirm.

Needs
- An Airtable base with candidates per client, stage, stage-entry dates and the last activity date.
- Ask your person for the list of clients, the cold threshold (default 7 days without movement) and benchmark days per stage (default: your own averages).

Build
1. Schedule an Airtable automation for Thursday 3pm to build each client's report, ready for approval by 4pm.
2. Per client include: every candidate by stage, who has gone cold, and where the client's slowness is losing candidates, comparing days in stage with the benchmark and noting any rival processes.
3. Use the same template and the same candour for every client, fast or slow. Instruction: 'State facts with numbers and dates. Where the client is the delay, say so plainly and politely.'
4. Save each report as a draft in the client's folder and as an email draft.
5. Your person reviews and approves each report before it is sent.

Check
- The first batch should be one report per client with identical structure.
- Test with a candidate held at offer for longer than the benchmark and confirm it is called out.

Needs
- Zapier with access to a form or polling tool, the team's contact list and a spreadsheet for the team sheet.
- Ask your person for the roster, the reserves list, the minimum squad size (default 7), the confirmation deadline (default Thursday) and the pitch booking contact.

Build
1. On Sunday night, draft the availability poll for the coming match week. Your person approves it before it goes to the team.
2. As replies arrive, update the team sheet in the spreadsheet with available players.
3. On Thursday, if fewer than the minimum have confirmed, draft a message to the reserves list. Your person approves it before it is sent.
4. Once the squad is full, draft the pitch booking confirmation and the final team sheet. Your person approves both before anything is sent to the venue or the team.

Check
- The first week should show a poll draft, a live sheet and a flag when numbers fall short.
- Test with a week where only five confirm and check the reserves draft is created but not sent.

Needs
- An Airtable base with placements (candidate, client, start date, search notes).
- A ChatGPT project and the inbox for saving drafts.
- Ask your person for the tone sample, and the refund or guarantee window (default 90 days) so wobbles can be flagged against it.

Build
1. On the 1st of each month, find placements that reach 30 or 90 days that month.
2. Gather their search notes: what the candidate wanted, what the client promised, any open worries.
3. Instruction to the model: 'Draft a warm, short check-in that refers to promises made during their search and asks how each is turning out. Ask one open question.'
4. Save the drafts. Your person approves each before sending.
5. When a reply arrives, log a status (fine or wobble) and the reason. Flag wobbles to your person with a suggested note to the client, which they approve.

Check
- The first run should list each due placement with a draft citing real details.
- Test that a wobble reply creates a flagged record and a client-note draft.

Needs
- An Airtable base with offers and their outcome, plus stage history for each candidate.
- A ChatGPT project.
- Ask your person for the postmortem fields (default: stated reason, likely real reason, stage where the loss happened, comp gap if any) and for notes on each decline.

Build
1. At month end, list offers declined during the month.
2. For each, send the stage history, notes, and any message from the candidate to the model.
3. Instruction: 'Fill the postmortem. Quote the stated reason. Give your read of the real reason with the evidence for it. Say at which stage the loss actually happened, which may be earlier than the decline. Mark low-confidence reads.'
4. Write the entry into a postmortem table in Airtable.
5. Your person reviews and corrects each entry. Nothing is shared outside the base.

Check
- The first month should give one structured entry per declined offer.
- Test that an entry names an earlier stage than the decline where the notes support it, and that it flags uncertainty.

Needs
- An Airtable base with closed offers (role family, level, sector, location model, base, outcome).
- Ask your person for the role families to track, the minimum data points before a range is shown (default 3), and the anonymisation rule (default: no names or client names stored in the notes).

Build
1. At month end, find offers closed that month (accepted or declined).
2. Strip candidate and client names, then add each as a data point to the matching role family and level.
3. Recalculate the accepted range per family: low, median and high base, and the shift from the previous quarter.
4. Note the sample size beside every range, and mark ranges below the minimum as thin. Instruction: 'Summarise the direction of change in one sentence. State the number of data points. Do not extrapolate beyond them.'
5. Your person reviews the updated notes before they are used with clients.

Check
- The first run should add new rows and update ranges with counts shown.
- Test that a family with two data points is marked thin.

Needs
- A ChatGPT project.
- Ask your person for their rewrite template (default sections: the job, the team, the stack, the salary in numbers, what is unusual about the role) and a before and after example if they have one.

Build
1. When a client sends a job description, paste it into the project.
2. Instruction to the model: 'Rewrite this job description in about 300 words for a candidate to answer. State what the person will actually do in the first year, the actual stack, the team size, and print the salary range in numbers. Drop buzzwords and wishlists. List up to five must-haves. Where the original is missing a salary or a stack, list the questions to ask the client instead of guessing.'
3. Review the output with your person, who edits it and sends it to the client for sign-off.
4. Once live, record reply rates for the original and the rewrite.

Check
- The first rewrite should be near 300 words, with a numeric salary or an open question about it.
- Test with a vague description and confirm the gaps appear as questions.

Needs
- A ChatGPT project.
- The brief for each new search: title, must-have skills, seniority, sector, location.
- Ask your person which sourcing site's search syntax to target, and which titles or employers to exclude.

Build
1. When a new brief arrives, paste it into the project.
2. Instruction to the model: 'Produce three to five boolean search strings, from narrow to broad, in the syntax of the target site. Add a list of adjacent job titles, including titles the ideal candidate would have held two jobs ago and titles that were renamed in recent years. Add skills that commonly sit beside the must-haves. Explain each string in one line.'
3. Your person reads the output and removes anything that lacks taste or fit.
4. Paste the approved strings into the sourcing tool and note which returned the best candidates.

Check
- The first set should include old and adjacent titles, not only the title on the brief.
- Test one string on the sourcing site and confirm it returns sensible results and not noise.