Your first end-to-end automated workflow

Target audience: technical + engaged non-technical | Prerequisites: 2.1 Getting to a good prompt, 2.2 Structured output, 2.3 Basic workflows, 2.4 Inputs and data preparation

What you'll learn

After this document you will be able to:

• put a workflow's (an automated sequence of steps) goal onto one page and write down what the system will NOT do;
• map the system with 1.5's seven anatomy parts before the first click;
• build the flow step by step with a no-code tool and justify every choice;
• take the finished flow through the test cycle and watch the first week with three numbers.

In plain terms

2.1–2.4 gave the parts: the prompt template, the structured output, the steps and conditions, the cleaned input. Now we put them together into one machine: in the HomeCraft Store (handmade goods) we build the return-request flow from start to finish — the guide is precise enough to build the same system by following it.

Step 0: the goal and the scope choice

Before building, put the goal onto one page — that is the sponsor's decision (1.6). The volume is known: about 40 client letters a day, five minutes each — more than three hours of routine (40 × 5 min = 3 h 20 min; the 1.4 calculation). (In the 1.2 example, when Mari still worked alone, the letters were 15–20 a week — always take your own system's current, measured volume; this example assumes a grown shop.)

In the meantime the shop has grown: the approver of the replies is now the shop's customer service agent Piret — Mari still decides and approves everything connected with goods or money.

The system does: classifies every new client letter (“return”, “info”, or “other”), pulls the order data from the e-shop system for returns and info letters, composes a reply draft, and puts it up for Piret's approval.

The system does NOT: send anything to a client without Piret's approval; handle complaints or legal claims; decide in money matters.

What we left out, and why. Complaints stay with a human — according to 1.2, the client relationship's important moments are human work: a wrong tone costs more than the automation saved. Fully automatic sending was left out, too: the first version stays human-in-the-loop (a human approves the result before it is used); a lighter check comes only based on the metrics (the 2.3 placement table). The three values (“return”, “info”, “other”) are deliberately leaner here than 2.3's four-branch example (“return”, “info”, “complaint”, “unknown”) — complaint and “unclear” both usually do the same thing: take the letter to a human. And in the first version, every outgoing letter gets a human's approval, even info — as trust grows, the info branch can be opened (see the 2.3 placement table).

In plain terms: the goal fits into one sentence: “the system reads the letter, composes the reply, and Piret presses the button.” Everything that doesn't fit into the sentence stays out — the list of exclusions is as important as the goal: without it, the project grows along the way.

The list of the system's parts (the anatomy table)

1.5's anatomy is the construction plan: every build step fills one row.

The build, step by step

Open a no-code tool — n8n, Make, or Zapier — and build seven blocks. For the technical reader: if the flow will later need to be triggered from within your own system, the next level is the API — see 3.1.

1. The trigger: a new letter in e-mail. Set the flow to wake up when a new letter arrives at the shop's service address. Why: the trigger makes the flow autonomous — the system wakes the same way with every letter, and Piret copies nothing by hand.

2. Input preparation: the letter into labeled form. Put the letter's text under the [CLIENT_LETTER] label — as 2.4 taught. Why: unformatted free text is noise; the labeled form is identical with every letter.

3. The classifier prompt with JSON. Create a step that calls the AI model with this prompt template:

You are the classifier of an e-shop's client letters. Your only task is to classify the letter.

Determine from the letter:
- type: "return" (the client wants to send the product back), "info" (other questions),
  or "other" (a complaint, a legal claim, an unclear letter)
- product: the product name stated in the letter or "missing"
- order_number: the order number stated in the letter or "missing"
- reason: one short sentence

Rules:
- Use only the data stated in the letter. If there is no data, write "missing" — don't invent.
- Answer with ONLY JSON, without introductory or closing text.

CLIENT_LETTER:
[CLIENT_LETTER]

The result is a structured output:

{
  "type": "return",
  "product": "wool scarf",
  "order_number": "1187",
  "reason": "the scarf turned out too tight"
}

Why: the workflow knows how to read the JSON fields onward — “type” goes into the condition, “order_number” into the lookup. The rule “if there is no data, don't invent” closes the road to a hallucination: an empty field is visible, an invented number is not. “other” fills the “unknown” role here — that path also leads to a human.

4. The condition: “other” → to a human. The condition reads the “type” field: if the value is “other” — or if the automatic rule (“is the answer JSON and are all the fields present?”, from 2.2) finds no fields — route the letter to Piret's review list and end the flow. Why: the fallback path is part of the design, not a failure (1.5). In the return case: if “order_number” is “missing” or the order is not found, the letter is routed to Piret's review list.

5. The drafter prompt template with the order data. For the types “return” and “info”, the flow looks up the order data by the number and puts it into the drafter template's placeholders [NAME_IN_CAPITALS]:

You are the HomeCraft Store's customer service agent — businesslike and friendly.

Compose a reply letter based on the client's letter.

Rules (the shop's terms):
- return period 14 days from the purchase, return fee 5 euros, money back within 3 business days
- use only the data below; if data is missing, say that you will ask
  your colleagues — don't promise anything else

Format: an e-mail, up to 80 words, in Estonian.

CLIENT_LETTER:
[CLIENT_LETTER]

ORDER DATA:
- number: [ORDER_NUMBER]
- purchase date: [PURCHASE_DATE]
- product: [PRODUCT]
- amount: [AMOUNT]

Why: the fixed parts (role, rules, format) are the fixed wording that has passed 2.1's test cycle and is not changed during the flow; the variable parts are filled with facts from the database — a number that doesn't exist in the system cannot get into the draft.

6. The approval step: Piret sees three things side by side. The flow waits until Piret has read the original letter, the draft, and the order data. Piret goes through the review list (for example, next to the e-mail) and approves or corrects. Why: the draft is a promise to the client; the checkpoint before the output catches the error where it costs a minute, not trust (the fifth part of 1.5).

7. Sending and a record in the log. After the approval, the flow sends the reply and writes into the log: the type, the decision (sent / to a human), whether the draft was changed, the time. Why: without the log, the flow's behavior is an opinion — from the records you see what works, and you can say who approved what (1.6).

Testing before going live

Before switching on, walk 2.1's test cycle through the whole flow: enter test letters by hand and watch where the flow takes them. The acceptance criterion: every letter ends up in the right place and the draft contains no fact that didn't come from the data. Use real old letters (data anonymized):

In plain terms: the tests are the test drive with an empty car. If some case fails, make one change, a new version, and a new round — not several changes at once, otherwise you won't know which one helped (2.1). Go live only when all the important rows pass.

The first week in production

After going live, read step 7's records into three numbers:

1. How many letters a day went through the flow and how many turned to a human. Using the fallback path is not a mistake — a sharp jump, however, is: something changed in the input.
2. How many drafts Piret changed before sending. The main sign of quality: many changes means some fixed part needs work; zero suggests the check can be lightened later (2.3's sampling check).
3. The error types — where the mistake happened. In the classification, the data, or the tone? Every error has an address according to 1.5: fix the right part, not “the AI in general”.

If the day shortens by hours and the changes are few, expansion (for example, preparing complaints for Piret) is the next project. A first look at the costs: write down how much a week of model calls spent — more thoroughly in 3.6. If errors repeat, it is time for error handling (3.4) and monitoring (4.6) — here, three numbers suffice.

In plain terms: the first week is the measuring week: three numbers tell whether the machine makes Piret's day shorter and where it errs.

Summary

• The goal onto one page, the excluded things too: returns and info get a draft, everything else turns to a human, Piret approves everything before sending.
• 1.5's anatomy is the construction plan: seven parts = seven build steps; as a step is finished, a system part is filled.
• Three rules make the machine trustworthy: the facts come from the data (JSON and “missing”), the decisions stand in the conditions, the promises go through the human-in-the-loop.
• The test cycle before going live, three numbers after it — decisions are based on metrics.

What's next?

• previous → 2.4 Inputs and data preparation
• next → 2.6 Prompt management as an asset
• The technical level → 3.1 API integrations
• back → handbook index