FW
Handbook

Part V · Systems that run themselves · Chapter 13

Orchestration and handoffs

Webhooks, workflow tools and APIs, and why the joins between tools are where pipelines quietly break.

13 min read

Orchestration is the wiring between tools: when something happens in one place, the right thing happens in the others, without anyone copying data between tabs. It is invisible when it works and very costly when it quietly doesn't. Most outbound systems that disappoint have a broken wire somewhere, not a bad message.

What you'll take away

  1. 01What orchestration is responsible for in a GTM system.
  2. 02Webhooks, APIs and JSON explained without jargon.
  3. 03A complete signal-to-rep workflow, step by step.
  4. 04Retries, duplicates, logging and alerts: what makes automations trustworthy.
  5. 05How to choose between no-code workflow tools and code.

What orchestration does

  • Moves data between tools: from the enrichment table to the sending tool, from replies to the CRM.
  • Triggers actions on events: a new signal, a reply, a meeting booked, a form filled.
  • Applies rules on the way: skip customers, route to the right rep, stop a sequence when someone replies.
  • Keeps a record of what happened, so problems can be traced.

Webhooks, APIs and JSON in plain words

TermPlain meaningExample
APIA way for one program to ask another to read or change somethingAsk the CRM for a contact; tell the sending tool to add a lead
WebhookA message one tool sends to a URL you choose when something happensThe sending tool notifies your workflow when someone replies
JSONThe text format most tools use to pass data{"email": "sam@example.com", "company": "Northwind"}
API keyA password for one program to use another's APIStore it in the tool's secret settings, never in a spreadsheet

None of this requires an engineering degree. It does require being able to read API documentation, look at the JSON a tool sends, and find the field you need. AI assistants are very good at explaining an unfamiliar API response.

a webhook payload you might receive when someone replies
{
  "event": "reply_received",
  "lead": { "email": "sam@northwind.example", "company": "Northwind" },
  "campaign": "second-site-q3",
  "received_at": "2026-10-14T09:12:00Z"
}

A signal-to-rep flow

Signal arriveswebhook from ahiring feedCheckin ICP? customer?contacted recently?Enrichfind the rightperson + emailWritedraft the firstline with evidenceHand offadd to sequence,post to SlackRecordupdate the CRMwith the sourceSkipped, with a reasonFailed: retry, then alertevery run logged
Fig 1. Every step has a defined way to skip, fail and record. That is what separates a workflow from a demo.
  1. 1

    Receive the signal

    A hiring feed, a website-visit tool or a scheduled search sends new events to your workflow.
  2. 2

    Check before spending

    Is the company in the ICP? Already a customer? Contacted in the last 90 days? Skip early, and record why.
  3. 3

    Enrich and write

    Find the right person and verified email, and draft the opening line from the evidence.
  4. 4

    Hand off

    Add to the right sequence and post a short note to the rep in Slack, with the reason and a link.
  5. 5

    Record

    Create or update the CRM records, including which signal and campaign produced the lead, so outbound gets credit.

Making it reliable

  • No duplicates on retry. Before creating a record, check whether it exists, matching on a stable key such as email or company domain. Webhooks are sometimes delivered twice; your workflow must not create two leads.
  • Retry, then alert. Network calls fail. Retry a couple of times with a pause, then send an alert to a person instead of failing silently.
  • Log every run. What came in, what was skipped and why, what was created. When sales asks where a lead went, you can answer in a minute.
  • Count both sides. Compare how many records left one tool with how many arrived in the next, daily.
  • Keep keys safe. API keys go in the tool's secret storage, not in shared documents or table cells.

Alert on silence. A workflow that processed nothing is usually broken, not resting.

Choosing a tool

OptionGood forWatch out for
Built-in automations in your toolsSimple, one-tool rulesLogic scattered across tools; hard to see the whole flow
Workflow tools (n8n, Make, Zapier)Connecting many tools visually; most GTM workflowsComplex logic gets hard to read; check pricing at volume
Code (scripts, small services)Heavy data work, custom logic, full controlSomeone has to maintain it; see chapter 15

Try it

Design a reply-handling workflow

Replies to outreach arrive in the sending tool. Today a rep checks it twice a day and copies interested replies into the CRM by hand. Design a workflow that does this automatically and safely.

Write your answer down first, then reveal the worked answer

Trigger: the sending tool's reply webhook.

Steps: (1) Stop the sequence for that person across all channels. (2) Classify the reply: interested, not now, wrong person, unsubscribe or out of office. Use an AI step with fixed categories, and treat unclear replies as needing a person. (3) Unsubscribes: add to a permanent suppression list immediately. (4) Interested: find or create the contact and company in the CRM, matching on email and domain to avoid duplicates; create a task for the owner; post to their Slack with the reply text. (5) Wrong person: create a task to follow the referral.

Reliability: log every reply and its classification; retry CRM writes, then alert; a daily count of replies received against replies processed. A strong answer handles unsubscribes first and never lets the AI decide to ignore a reply.

Go deeper

Practise the skills