Job Description: Choose the First Job to Give an AI

Before anything else: do not paste real customer names, phone numbers, addresses or amounts. Use markers such as CUSTOMER_A, as you did. The method does not need the real values.

Step 2: scoring (Repetition, Rule-likeness, Volume, Recoverability)

The score sorts; it does not decide. Jobs scoring 1 or 2 on recoverability, here (c), (d), (e), (f) and (i), are not automated end to end: the decision stays with a person.

Step 3: the two questions

For the top three, (b), (a) and (g):

1. Where do the inputs come from? (b) and (g) both read the job sheet, which is typed by hand today. (a) reads the jobs mailbox. Mailbox and spreadsheet are reachable. Access method (sharing, API) is [TO CHECK].
2. Who owns exceptions? PERSON_A, twice a day.

First candidate: (a), not the highest score. The reminders and review requests both depend on the sheet, so a clean sheet comes first. Starting with (b) would automate on top of manual typing errors.

Step 4: job description, "Job requests into the sheet"

1. Trigger: a new email arrives in the shared jobs mailbox.

Input: the email subject and body, and the sender address. Not attachments, unless a photo is the only content, in which case set aside.
3.

Source of truth: for a returning customer, the existing customer row in the sheet; for the request itself, the email text. If the two disagree (a different address or phone), it does not choose.
4. Output: one row: date received, CUSTOMER marker field, service type, urgency words found, status "Unconfirmed".
5. Destination: a "New requests" tab of the job sheet, never the main schedule.
6. Never: see Step 5.
7. Exception owner: PERSON_A, checks the tab at start and mid-afternoon.

Step 5: the never list

• Never replies to the customer or confirms a visit, price, or deadline. Alternative: the row is for PERSON_A to answer. Enforced by missing access: it cannot send mail.
• Never decides an emergency is not urgent. If the text contains words such as gas, leak, flooding or no heating in winter, it marks the row "Urgent, set aside" and does nothing else. Alternative: PERSON_A reads it first.
• Never merges two customers or overwrites an existing row when the details disagree. Alternative: set aside with the reason.
• Never invents a service type not in the company's list [TO CHECK: the list].
• Never processes a request it could not read in full (a corrupt attachment, a blank body). It reports "could not check".

Step 6: three answers

• Done: a clean row was written and the fields match the rules.
• Set aside: why in one sentence (urgent words, conflict with an existing customer, unknown service).

Could not check: the mailbox did not open or an attachment was unreadable. This must stay separate, because a failed read and an empty mailbox look the same, and an outage would otherwise read as "no new requests".

Step 7: start in draft mode

It does the whole job except moving the row to the main schedule. PERSON_A reviews the tab and moves rows by hand for a period she chooses. One category at a time, for example plain boiler-service requests, earns the right to go straight in once the record shows it is accurate.
Steps: read the email (understanding), pick service type (understanding), find urgency words (checking), find the phone and address (checking), match an existing customer (checking), write the row (checking).

I make no promise about time saved. If you are taking the course, you can send this as the module 2 or 3 exercise for the written review.

This is a worked example and not legal, tax or data-protection advice; questions about personal data belong to your data protection lead or lawyer. The business and every name here are synthetic test data.