Worked example — automate a small-business inbound-lead pipeline

One end-to-end project that stitches the whole course together: a no-code form captures a lead, a Make-style automation routes it, a generative-AI step drafts a personalised reply, and an Airtable base logs everything — finished with an honest ROI and build-vs-buy analysis.

The scenario. "Verde Jardín" is a two-person urban-gardening studio. Enquiries arrive through a website contact form, Instagram DMs and email. A founder spends the first hour of every morning triaging them and hand-writing the same kind of first reply — a warm acknowledgement, a rough quote band, and a link to book a site visit. Replies are slow and inconsistent, and some leads simply go cold. The brief: respond to every new lead within minutes, in a consistent on-brand voice, without hiring anyone — using only no-code / low-code tools plus generative AI, exactly the toolkit this course teaches.

The shape of the solution. A single no-code form becomes the one front door for leads. Each submission triggers a low-code automation (a Make / Zapier scenario, modelled here as a step graph) that scores and routes the lead, calls a generative-AI step to draft a tailored reply, writes the lead and the draft to a no-code database (Airtable), and notifies the founder for a one-click send. A human still approves every outbound message — the AI drafts, the person decides.

Goal

• Cut first-response time from a morning batch (often 6–18 h) to under 5 minutes, around the clock.
• Standardise quality — every lead gets an on-brand, complete first reply with the right next step.
• Keep a human in the loop — the AI proposes, the founder approves; nothing auto-sends.
• Spend almost nothing — assemble it from free / low tiers of tools the course already covers.

Sessions exercised

Tools used

2. The problem & the workflow design

Before touching a tool, decompose the manual routine into a trigger → filter → action graph — the exact mental model from the automation session and the automation pipeline demo.

The manual routine, written out. (1) A lead lands somewhere — form, DM, inbox. (2) The founder reads it and guesses how serious it is. (3) They look up a rough price for the kind of job. (4) They write a reply from scratch. (5) They paste a booking link. (6) They make a mental note to follow up. Steps 2–5 are repetitive and rule-shaped — the ideal candidate for automation, with the genuinely human judgement (does this reply sound right? is the quote sane?) preserved as a final approval gate.

The redesigned flow. Collapse the three inboxes into one form, then let the automation do the mechanical middle while a person keeps the final say:

The form (the one front door)

A short Typeform / Tally form captures only what's needed to draft a good reply — the "ask only what you need" rule from the forms session. Fields:

• name · email (validated) — who to reply to.
• service (select: balcony garden · roof terrace · maintenance · other) — drives the quote band.
• budget band (select) and timeline (select) — feed the lead score.
• message (free text) — the raw context the LLM personalises against.

3. The no-code / low-code build, step by step

Each step is a few clicks in a visual builder. Only step 4 holds any hand-written code — and even that is a single API call. Everything else is configuration.

4. The generative-AI step — prompt design + the API call

This is where the course's generative-AI content becomes a working component. Good output needs a good prompt — "minimum-effort prompts give low-quality results", straight from the syllabus's GenAI policy.

Prompt design

The prompt is engineered, not improvised. It does four things: (a) sets a role and voice so replies are on-brand; (b) injects the lead's structured data so the reply is specific; (c) gives hard rules (quote bands, length, always include the booking link, never invent facts); and (d) pins the output format so the automation can use it directly. A system message carries the durable rules; a user message carries the per-lead data.

The API call (the only real code)

Inside the automation's HTTP step (or a 1-file serverless function), this is the entire generative-AI integration — a single fetch to a chat-completions endpoint. Tokens in, tokens out: the LLM reads the prompt as the tokens from the tokenizer demo and predicts the reply via attention.

// draftReply.js — called by the Make/Zapier HTTP step (or a serverless fn).
// Input: the lead object from the form. Output: a parsed draft reply.
export async function draftReply(lead) {
  const system = `You are the assistant for "Verde Jardín"... (full system prompt above)`;
  const user = `name: ${lead.name}
service: ${lead.service}   budget: ${lead.budget}   timeline: ${lead.timeline}
message: """${lead.message}"""`;

  const res = await fetch("https://api.openai.com/v1/chat/completions", {
    method:  "POST",
    headers: {
      "Content-Type":  "application/json",
      // key lives in an env var / Make connection — NEVER in client code
      "Authorization": `Bearer ${process.env.LLM_API_KEY}`
    },
    body: JSON.stringify({
      model:           "gpt-4o-mini",   // cheap, fast, good enough for drafts
      temperature:     0.4,            // low = consistent, on-brand
      max_tokens:      320,
      response_format: { type: "json_object" }, // force parseable JSON
      messages: [
        { role: "system", content: system },
        { role: "user",   content: user }
      ]
    })
  });

  if (!res.ok) throw new Error(`LLM error ${res.status}`); // fail loud → human handles it
  const data = await res.json();
  const draft = JSON.parse(data.choices[0].message.content);

  // draft = { subject, body, needs_human_note } → goes into Airtable as a DRAFT.
  // Status stays "new"; nothing is sent until a human approves it.
  return draft;
}

~20 lines. The API key is read from an environment variable / the platform's stored connection — never hard-coded and never exposed to the browser. The call returns strict JSON so the no-code steps downstream need zero parsing logic.

5. Results & impact analysis — a worked ROI

The automation session's core skill: judge whether automating actually pays. Numbers below are a worked baseline for Verde Jardín — change the assumptions and the model still holds. Tune the same levers live in the RPA ROI demo.

Assumptions

• Volume: 120 leads / month.
• Manual handling: ≈ 8 minutes per lead (read, look up a price, write, paste link, log).
• Automated handling: ≈ 1.5 minutes per lead (skim the draft, tweak, approve).
• Founder's loaded time: €30 / hour.
• Build effort: ≈ 8 hours, one-off (a day of setup at €30/h = €240).
• Run cost: ≈ €30 / month (form + Make + Airtable low tiers + ~€3 of LLM tokens).

Monthly time & cost

Payback & first-year return

One-off build cost is ≈ €240 (8 h × €30). At €360 net saving per month:

payback $= \dfrac{\text{build cost}}{\text{net monthly saving}} = \dfrac{240}{360} \approx 0.67 \text{ months} \approx 20 \text{ days}$

first-year net $= (360 \times 12) - 240 = 4{,}320 - 240 = €4{,}080$

The non-financial return matters more. The time saving is real, but the bigger win is the revenue protected: leads that used to go cold while waiting overnight now get a complete, on-brand reply within minutes. Even a small lift in lead-to-booking conversion (say 120 leads × a few extra bookings at hundreds of euros each) dwarfs the €360 of labour saved — and that is the argument to make to a real business.

Build vs. buy

6. Risks & limitations

The syllabus is explicit: assume GenAI output is wrong unless you can check it, and acknowledge its use. A responsible build designs for failure, not just for the happy path.

7. Mapping to course learning outcomes

How this single project evidences each course-level objective from the syllabus.

Skills exercised: using no-code form & database builders, building a trigger→action automation, judging automation ROI, foundational generative-AI and prompt engineering, and integrating a model via an API — the full skills list from the objectives.

8. Extensions

Natural next steps once the core pipeline is trusted — each maps to another course session.

• Multi-channel intake — add Instagram-DM and email-parsing triggers so all three inboxes feed the same form schema (more automation, Session 6).
• A real chatbot front end — replace the static form with a ManyChat/Tars bot that asks the same questions conversationally and routes by intent (Session 11).
• Payments & booking — when a lead books, take a deposit via Stripe and let the webhook fire a confirmation automation (Session 9).
• Retrieval grounding — give the LLM a small knowledge base (past quotes, FAQs) so drafts cite real numbers, further cutting hallucination.
• Image generation — auto-attach an AI mood-board image for the proposed garden style with a diffusion model (Session 12, diffusion demo).
• A/B the prompt — log which drafts the founder edits most and refine the system prompt — prompt engineering as a measured, iterative loop.

9. References

Grounded in the course bibliography and syllabus, plus the provider docs for the API used.

• Introduction to Generative AI — Dhamani, Numa & Engler, Maggie (2024), Manning. ISBN 9781633437197
  How LLMs work and how to integrate generative AI into workflows responsibly — the basis for the prompt-design and risk sections. · manning.com
• Generative AI in Practice — Marr, Bernard (2024), Wiley. ISBN 9781394245567
  Real-world business applications, risks and the changing job market — the "so what" behind the impact analysis. · wiley.com
• The Low-Code Handbook — Cabot, Jordi (2024), Kindle. ISBN 9789998778504
  Platforms, integration and best practices — the reference for the form, database and automation build. · lowcode-book.com
• Low-Code/No-Code: Citizen Developers — Simon, Phil (2022), Racket Publishing. ISBN 9798985814736
  Why non-engineers can build valuable software — the framing for this whole project. · philsimon.com
• Technology with Impact — course syllabus — Oleaga Guridi, Jon (2025), IE University.
  Sessions 1–12 content, the GenAI policy and the learning objectives this project is mapped to. · SYLLABUS.pdf
• Chat Completions API reference — OpenAI / Anthropic provider documentation.
  The request/response shape used by the fetch call in section 4 (model, temperature, messages, JSON output).

Explore the mechanics behind this project: automation pipeline · RPA ROI · chatbot intent routing · tokenizer · attention · no-code database · no-code builder · or read the full course outline.