2 ready-to-build workflows

AI agent workflows for D2C consumer brands

Handle post-purchase support, tracking, returns and restock nudges on WhatsApp — with every refund or exchange gated to a human.

Each recipe below is expressed only in VegaDūta's real workflow building blocks — Trigger, Agent, Knowledge, Condition, Approval, Output, Tool (MCP), Voice, Device, Loop, Code and Parallel — so it maps 1:1 to something you can assemble in the Workflow designer. Consequential actions always pass a human Approval step.

1. Post-purchase WhatsApp support & order tracking

After every order the inbox fills with 'where's my order?', 'how do I use this?' and 'is size M back in stock?' — cheap questions individually, but a full-time job at launch volume, and slow replies read as a bad brand.

Trigger: WhatsApp (inbound message)

How the workflow runs

  1. Trigger

    Customer messages. A WhatsApp trigger starts on any inbound post-purchase message.

  2. Agent

    Understand intent + identify the order. An Agent node classifies the intent (tracking, product help, stock, other) and extracts the order id / phone to identify the order.

  3. Tool (MCP)

    Look up live status. A Tool (MCP) node fetches the real order and shipment status from your OMS / 3PL / carrier — no first-party OMS connector, MCP calls yours.

  4. Knowledge

    Ground product & policy answers. A Knowledge node answers product care, sizing, shipping and returns-policy questions strictly from your own content — with citations, no invented claims — and can offer a back-in-stock alert on an out-of-stock item.

  5. Output

    Reply on WhatsApp. An Output node sends the answer in the customer's language and, for anything out of scope or upset, hands off to a human with the context attached.

Channels & connectors

  • WhatsApp
  • Tool (MCP → OMS/3PL)
  • Knowledge base
  • Sarvam (multilingual)

Outcome

The commonest post-purchase questions answer themselves instantly, day or night, with a human reached only for what genuinely needs one.

Why it helps

Removes the highest-volume, lowest-value inbox work from a small team, on the channel customers actually read, without the agent inventing product claims.

Build spec

1 agent — 1 support agent; the live-status lookup and the human hand-off are workflow nodes.

System prompt (paste-ready)

You are a post-purchase support agent for {{brand}}. Classify the message as {tracking | product_help | stock | returns | other}, identify the order, and answer in the customer's language. For tracking, use only the status the tool returns — never guess a delivery date. For product and policy questions, answer ONLY from Knowledge and cite it; if it isn't there, say so and offer a human. Never invent a product claim, ingredient, or policy. If the customer is upset or the request is out of scope, hand off to a human.

MCP connectors

  • OMS / 3PL / carrier — via a Tool (MCP) node (no first-party connector)
  • WhatsApp — send/receive channel

Built-in tools

  • http_request (live order + shipment status)
  • knowledge_search (product care, sizing, shipping & returns policy)

Guardrails

  • Grounded-only — product and policy answers come from Knowledge with a citation, or the agent defers to a human; no invented claims
  • No guessed delivery dates — tracking answers use only the status the OMS/carrier tool returns
  • Auto-hand-off on upset or out-of-scope intent, carrying the conversation context so the customer doesn't repeat themselves

Output & delivery

Inbound WhatsApp → the agent classifies intent and identifies the order → a Tool node pulls live status via MCP and Knowledge grounds product/policy answers → the reply is sent on WhatsApp in the customer's language, with upset or out-of-scope threads handed to a human with full context.

2. Returns / exchange intake with a refund approval

Return requests arrive by DM and email, someone eyeballs each against the return window and condition, refunds get issued inconsistently, and the follow-up review request never gets sent — so a good return never becomes a good review.

Trigger: WhatsApp (return request) or Webhook

How the workflow runs

  1. Trigger

    Return requested. A WhatsApp trigger (or a Webhook from your store/help desk) starts the flow.

  2. Agent

    Structure the request. An Agent node identifies the order and item and captures the reason, preferred resolution (refund or exchange), and any required photos into a clean record.

  3. Knowledge

    Check the return policy. A Knowledge node checks the request against your return window and eligibility rules — with citations — so the policy is applied consistently, not by feel.

  4. Condition

    Completeness & eligibility gate. A Condition node won't advance until the mandatory details and photos are in and the item is within policy; edge cases branch to review.

  5. Approval

    Team approves the refund / exchange. An Approval node holds every refund or exchange for a human — the money/inventory decision is never automated. This is the control.

  6. Output

    Confirm, then invite a review. On approval a Tool (MCP) node creates the RMA / issues the refund via your OMS + Razorpay UPI, an Output node confirms it on WhatsApp, and once the return is resolved it invites the customer to leave a review.

Channels & connectors

  • WhatsApp
  • Knowledge base
  • Approval / HITL
  • Tool (MCP → OMS)
  • Razorpay UPI

Outcome

Returns and exchanges are captured completely and judged against the same policy, refunds are issued only with a human sign-off, and a resolved return automatically turns into a review request.

Why it helps

Removes the inconsistent manual triage and the missed review follow-up, while every refund and exchange stays a human decision with a full trail.

Build spec

1 agent — 1 returns-intake agent; the policy check, the approval gate and the refund/RMA + review ask are workflow nodes.

System prompt (paste-ready)

You are a returns assistant for {{brand}}. Identify the order and item, and capture strict JSON {order_id, item, reason, resolution: REFUND|EXCHANGE, photos[], within_policy: boolean, policy_citation}. Judge within_policy ONLY from the return rules in Knowledge and cite them; if the request is outside the window or ineligible, say so plainly rather than promising a refund. Never confirm a refund or exchange as approved — that is a human decision. Do not state a refund amount as final until the approval step has run.

MCP connectors

  • OMS / store platform (Shopify/WooCommerce/etc.) — via a Tool (MCP) node (no first-party connector)
  • Razorpay UPI — refund issued via a Tool (MCP) node on the payments API
  • WhatsApp — send/receive channel

Built-in tools

  • knowledge_search (return window + eligibility rules)
  • http_request (order + payment lookup)

Guardrails

  • No refund or exchange without the Approval node — the agent captures and checks policy but never issues money or inventory; a human signs off every case
  • Policy applied consistently — within-window/eligibility is judged only from cited Knowledge rules, not the agent's discretion
  • Completeness gate — the Condition node blocks advancement until mandatory details and photos are present; the review ask only fires after the return is resolved

Output & delivery

Return requested on WhatsApp → the agent structures the request and checks it against the cited return policy → Condition enforces the completeness/eligibility gate → the team approves the refund/exchange at the Approval node → a Tool node creates the RMA and issues the refund via the OMS + Razorpay UPI, Output confirms it, and a review invitation is sent once resolved.

Related industries

Build one of these in minutes

The sandbox gives you a live agent workspace — no account, no card. Or head back to the full catalogue and compare patterns across every industry.

Try this in the sandbox — no signupBrowse all industries
See how VegaDūta compares to n8n, Dify and BotpressWhy VegaDūta's architectureEstimate your WhatsApp API costs