Runway East — Broker Email Automation Flow

How the flow works

Sequential. Make / Zapier watches the inbox and creates the HubSpot deal with the raw email body and the broker contact (broker company auto-associates via HubSpot's standard setting).

Then HubSpot's workflow runs a single webhook step that sends the email body to the AI bot and reads the bot's response back into the deal — all in one round-trip. No tokens, no callbacks, no extra middleware on the return path. If the webhook step times out, HubSpot retries until it succeeds or eventually fails — failures route to manual review.

Make / Zapier — email watcher + initial deal creation HubSpot — orchestrator + webhook caller + send AI Bot — parses email, returns JSON in the response

Trigger

Broker sends email

▼

Email inbox

broker-responses@runwayea.st

Make / Zapier watches this inbox

▼

1. Make / Zapier

Create deal + broker records in HubSpot

Read email: sender, domain, subject, full body, Message-ID
Create / update broker contact (matched by email) — sets Is Broker = Yes + name, email, phone, etc. The broker company auto-creates and associates via HubSpot's "Create and associate contact with company" setting.
Create deal: Automated? = Yes, Stage = Awaiting AI, Entry Point = Broker Enquiry, Email_Body_Raw, Email_Message_ID
Associate broker contact to the deal with association label = Broker (this is what step 3a uses to filter the email send — only contacts labelled Broker receive it). The auto-created broker company associates too. Note: this label is new for this flow — sales currently sends broker emails manually so the filter wasn't needed. It's required now because the email in 3a goes out without human oversight.

deal created → workflow fires

▼

HubSpot AI Bot

2. HubSpot workflow — webhook step

One round-trip: send email body, map response back into the deal

Trigger: deal created where Entry Point = Broker Enquiry AND Automated? = Yes

HubSpot fires the webhook (reads from the deal record) The webhook step reads properties from the deal that triggered the workflow and sends them to the bot's URL: deal_id, Email_Body_Raw (the email Make/Zapier saved on the deal in step 1), Email_Message_ID. Same mechanism as a webhook step reading from a contact after a form submission — just sourcing from a deal record instead.

AI bot's job (inside the response) Parses email body (prospect, company, area, budget, move date, size, requirements) → matches against RWE offices (top 3) → drafts the response email body → returns everything as JSON in the response body.

HubSpot reads the response → maps fields onto the deal

Deal-level: area, budget, move date, requirement size, other requirements, Broker AI sales email reply
Prospect fields parked on the deal as temp holders (HubSpot uses these in step 3b to create the prospect contact): prospect_name, prospect_email, prospect_phone, prospect_company, prospect_domain

If the bot doesn't respond in time, HubSpot keeps retrying the webhook step until it gets a successful response — or eventually gives up (which routes to step 3b).

webhook outcome

▼

Webhook returned data — send

3a. HubSpot — send email to broker

Send the marketing email (this happens first — broker is waiting)

Wrap Broker AI sales email reply in branded marketing email template
Send via Marketing Email — filtered to deal contacts with association label = Broker. The prospect (created in 3b) never receives this email by design.

▼

3b. Prospect record — your choice

CRM hygiene — runs after the email goes out

HubSpot's native "Create record" workflow action fails if the contact already exists. So we have two options for handling this — pick whichever fits.

Option 1 — Route through Make/Zapier (recommended for full automation) HubSpot workflow fires a webhook to a Make/Zapier scenario with the prospect_* fields + deal_id. The scenario uses three native modules:

Create or Update Contact — handles duplicates natively (looks up by email, updates if exists, creates if not)
Create or Update Company — same logic, matched by domain
Associate Contact with Deal — links to deal_id with association label = Prospect

Symmetrical with step 1. No API token needed. No Ops Hub Pro needed.

Option 2 — Skip it (simplest, no automation work) Leave the prospect_* fields sitting on the deal as data. Don't auto-create the contact. If sales engages with the deal, they promote the prospect to a real contact manually from the deal record.

Zero new setup. The data is still captured on the deal, just not surfaced as a searchable contact in CRM until someone touches it.

Either way, the email to the broker has already gone out in step 3a — this step doesn't block that.

Webhook eventually failed

3c. Manual review queue

Route deal for human handling

HubSpot exhausted retries on the webhook step → branch here
Notify deal owner / team Slack channel
Raw email body still on the deal as backup
Reviewer replies manually + logs in HubSpot

Why one round-trip is best

HubSpot's webhook step in workflows can both send a request and read the response. So we send the email body in the request, the bot returns the parsed data in the response, and HubSpot maps those fields onto the deal — all in one step. No async callbacks, no API tokens, no Zapier on the return path.

Matching key vs audit key

deal_id is the matching key — it's how the bot knows which deal the request is for.

Email_Message_ID rides along on the deal as the audit / idempotency key — useful for tracing logs across systems.

Confirmed behaviour

Multiple emails from same broker: Each email = its own deal.

Still to confirm

All for the bot dev:

"What URL should HubSpot send the broker email to?" (this is the URL we plug into step 2)
"Does your URL need a token in the request, or is it open?" (so HubSpot's outbound webhook is set up correctly)
"What fields will you return in the response body?" (so we can map them in HubSpot's webhook step)