Building it, step by step

Now we build Rohit's enquiry pipeline for real. The specifics of any one platform's buttons will drift, so what follows is deliberately about the decisions rather than the clicks — the decisions are what transfer.

Start with the trigger, and test it alone

Connect the mailbox, choose "new email", and run the trigger by itself. Every serious automation platform lets you do this, and it produces a sample of real data: the sender, the subject, the body, the timestamp, each as a named field you can refer to later.

Do not proceed until you have looked at that sample. Two things routinely surprise people here. Email bodies arrive with signatures, disclaimers, and quoted reply chains attached, which will be fed to your AI step along with the actual message. And the body may arrive as HTML rather than plain text, which means a wall of tags. Both are fixable; both are much more expensive to discover after you have built four more steps on top.

Filter early

Rohit's second step is not the AI. It is a filter: continue only if the email is not an automated reply, not from a known vendor domain, and longer than twenty words.

Filtering early is a habit worth forming, for two reasons. It stops the automation acting on junk, and on a per-task pricing model it stops you paying for junk. A filter step is usually free; an AI step is not.

The AI step, written for a machine

Now the extraction. The prompt inside this step is a configuration, not a conversation, and it follows lesson 3's rules with one addition — the output shape is absolute:

You extract enquiry details for an interior design studio. From the email below, return exactly five lines in this order: CLIENT, PROJECT_TYPE, LOCATION, BUDGET_BAND, TIMELINE. Each line is the label, a colon, then the value. If a value is not stated in the email, write UNKNOWN — never guess. Ignore email signatures, disclaimers, and quoted previous messages. Return only the five lines.

Then the email body is inserted below it.

Four things in that prompt are doing real work, and each was added after something went wrong. Exactly five lines in this order makes the next step's parsing possible. Never guess stops the model inferring a budget from the tone of the email, which it will otherwise do with total confidence. Ignore signatures stops a designer's own footer being read as the client's details — the first version of this automation produced eleven enquiries from "Sent from my iPhone". And return only removes the preamble.

Parse, then act

The parsing step splits the five lines into five fields. Then the action writes them to the tracker.

Here is where a decision matters more than it looks. Rohit adds a sixth column to the tracker: status, set to needs review rather than new. Every automated row lands as unreviewed, and a human clears it.

That is the human checkpoint, and it is the most important design choice in the whole automation. It converts the machine from something that acts on the world into something that prepares actions for a person to confirm. The next lesson is about what happens without it.

Run it on ten real emails before it runs on one live one

Every platform has a way to feed historical or test data through. Use it. Take ten real enquiries from last month and run them.

Rohit's first pass on ten: seven extracted cleanly, one produced UNKNOWN for a budget that was written as "around 15-18L" (the model was being obedient about not guessing, and the fix was to give it three examples of how budgets get written), one blended two projects mentioned in a single email into one row, and one had the sender's name as the client when the sender was an architect referring a client.

Three defects in ten, all found before anyone downstream saw a row. Two were fixed with added instructions. The third — the referring architect — was genuinely ambiguous, so the rule became: when the email is a referral, put both names in and flag it for review. The checkpoint absorbs what the specification cannot resolve.

Do this today: build the trigger and the filter for your sentence from lesson 7, and stop there. Look at the real data your trigger produces. That five-minute look prevents more rework than anything else in this course.