Operator + Make: An Inbound Email to a Booked Onboarding Call With No Human in the Loop

The first time the agent booked an onboarding call without me touching anything, I was halfway through a sandwich. Inbound email landed at 12:14 p.m. — a "demo request" from a VP Sales at a 240-person fintech. By the time I picked up my phone again at 12:38, the prospect had received a personalized prep doc in her inbox, three Cal.com time slots in her timezone, and a calendar invite for Thursday at 10:30 a.m. Her only action was clicking "yes." I never saw the lead until she showed up on the call.

That was the moment a five-step pipeline earned its place. Up to that point I had been running it in shadow mode for six weeks — every lead the agent qualified also got a human qualification. After the 200th shadow comparison, the agent had disagreed with me exactly three times. Two of those were cases where it had caught a signal I had missed (a job change the prospect had not yet updated on LinkedIn, a "we just raised Series B" buried in the email signature). The third was a genuine error: a qualified lead sent to the decline queue because Operator had hit a captcha on the company website and silently returned "site unreachable" instead of falling back.

This is the build — a Make webhook, an Operator browser task, an ICP (Ideal Customer Profile, 理想客户画像) rubric you can paste in, a Cal.com hand-off, and a personalized prep doc composer. Five pieces, end-to-end. I will give you the actual rubric, the actual Operator instruction set, the actual Make module list, and the three failure modes that have cost me the most sleep. ⚠️ One caveat up front: Operator's UI and the surrounding browser-agent category are shifting fast. The framework here is what lasts. The specific Operator screenshots, prompts, and form-field names will likely need a refresh in 6–12 months.

The pipeline, top to bottom

Five stages, four tools, one human only at the close. The flow is a Make scenario (Make is the automation platform formerly called Integromat, a Zapier competitor with more flexible routing) and a single Operator task that gets invoked with the email body as its input.

1. Trigger — Gmail or Outlook label demo-request fires a Make webhook. Email body + signature + subject + sender metadata get bundled into a JSON payload.
2. ICP qualification — Make POSTs the payload to Operator with a fixed instruction: visit the company website, classify ICP fit on a 5-point rubric, return either a qualified (with score) or decline (with reason) verdict.
3. LinkedIn enrichment — for qualified leads, Operator visits the prospect's LinkedIn profile, reads the three most recent posts, returns a 3-sentence summary of stated priorities.
4. Cal.com booking — Operator opens Cal.com's booking page for the next 5 business days, finds 3 slots in the prospect's inferred timezone, sends a calendar invite via Cal's email integration.
5. Prep doc composition — Make composes a 200-word personalized prep doc (company + role + stated priorities + 3 discovery questions) and sends it to the prospect 24 hours before the call. A Slack digest of the day's bookings lands in #sales-pipeline at 9:00 a.m.

End-to-end latency for the median lead: 4 minutes 12 seconds, of which 3 minutes 40 seconds is Operator doing the qualification visit. End-to-end cost per lead: $0.42, of which $0.38 is the Operator task. Make operations account for $0.04.

What you need before you build

• OpenAI Operator (or any browser-using agent with similar primitives). I am running this with Operator today; Anthropic's Computer Use and Google's Mariner are functional substitutes if you adapt the instruction set. The post is written against Operator's API surface. ⚠️
• Make.com Core plan ($10.59/mo). Free tier's 1,000 operations per month runs out by lead number 35 if you are getting any meaningful demo volume. Core's 10,000 ops covers 200 leads/month with headroom.
• A dedicated inbox with a demo-request label in Gmail or Outlook. The label, not a forwarding rule, is the right trigger — it gives you human control over what enters the pipeline (e.g., the AE can drag a misrouted sales-call follow-up into the label manually).
• A Cal.com account with a public booking link per AE (Account Executive, 客户经理), plus the Cal.com email integration turned on. The pipeline books into a round-robin pool of three AEs.
• A 200-word prep doc template in a Make data store. The pipeline fills in 4 fields: company name, prospect role, top 3 LinkedIn-derived priorities, and 3 discovery questions.
• A Slack channel named #sales-pipeline for the daily digest.

The whole build takes about six hours the first time. After that, every change is in the rubric, the prep doc template, or the Cal.com round-robin config — all five-minute edits.

Step 1 — The trigger and the payload

The trigger is a Gmail module in Make set to "Watch emails" with a label filter on demo-request. Every five minutes it polls for new messages. For each new email it extracts from, subject, body, and body_signature (a regex-stripped block under the -- line in the signature) and bundles them into a payload:

{
  "from": "[email protected]",
  "subject": "Demo request — LogiTech Solutions",
  "body": "Hi, I lead sales ops at LogiTech...",
  "signature": "Sarah Chen\nVP Sales\nLogiTech Solutions\nlogitech.com",
  "receivedAt": "2025-11-18T12:14:08Z"
}

The signature field is the load-bearing one. 88% of demo requests I have seen in the last year have a real company URL buried in the signature — that is the URL Operator will visit to qualify. The remaining 12% are personal Gmail/Outlook accounts with no company name, and they fall to the manual queue (Step 6 below).

The five-minute polling cadence is intentional. A faster cadence (one minute) hit Gmail's rate limits during a 200-lead webinar spike. Five minutes gives Make headroom while still feeling instant to a prospect.

Step 2 — The ICP rubric and the Operator instruction set

This is the part the framework posts on "AI lead qualification" almost always skip. The qualification is not a vibe. It is a rubric. Here is the rubric I paste into Operator's instruction set, adapted from a B2B SaaS ICP I built for a 60-person client in the martech space:

# ICP qualification rubric (5 points)

You are qualifying an inbound demo request for a B2B SaaS product
(our analytics platform, sold to mid-market revenue teams).

Score 1 point for each criterion that is TRUE. Maximum 5.

1. Company size: 50–2,000 employees (count LinkedIn / About page)
2. Industry: B2B SaaS, fintech, martech, edtech, or HR tech
3. Buyer signal: the email sender's title contains "Head", "VP",
   "Director", "Founder", "C-level", or "Manager" of a revenue or
   marketing function
4. Tech fit: the company website mentions analytics, attribution,
   or growth tools, OR the company has an active careers page
   for analytics/marketing roles
5. Timing: the email body mentions a specific problem, timeline,
   or vendor replacement (not just "just curious")

Output JSON exactly:
{
  "score": ,
  "verdict": "qualified" | "decline",
  "companyUrl": ,
  "companyName": ,
  "industry": ,
  "employeeCount": ,
  "rationale": <1-2 sentences, referencing the rubric points you
                awarded or denied>
}

Decision rule:
- score >= 3: verdict = "qualified"
- score < 3: verdict = "decline", include reason in rationale
- if you cannot find a company website at all: return
  verdict = "manual" and companyUrl = null

The instruction set itself is what gets sent to Operator. The wrapper Make module looks like this:

Operator task: "An inbound demo request just landed. Read the email
body and signature, find the company website, score the lead on the
ICP rubric below, and return JSON.

[PASTE RUBRIC HERE]

Email body: {{1.body}}
Email signature: {{1.signature}}
Sender: {{1.from}}"

Two things matter in the instruction set. First, the rubric is given as a paste-in block, not as a vague instruction. Operator reads structured rubrics better than open-ended ones. Second, the JSON output schema is fixed. Operator is generally reliable about returning structured JSON when the schema is in the prompt and the call is short. Across 200 leads, 6% of Operator responses had to be re-parsed for a missing field — usually employeeCount when the About page had no headcount hint.

The manual verdict is the third exit state and it is the most important. "I cannot find a company website at all" covers two real situations: personal emails from consultants or freelancers, and emails where the signature was stripped by a corporate mail gateway. Routing those to a human queue (not the decline path) is the difference between a clean pipeline and a queue full of bad declines.

Step 3 — LinkedIn enrichment (the secret to better prep docs)

The qualification step tells you whether to book the call. The enrichment step tells you what to put in the prep doc. The difference between a "thanks for booking" email and a 200-word prep doc that names the prospect's own priorities is the difference between a 60% show rate and an 85% show rate. I have measured both.

For qualified leads, Make fires a second Operator task:

Operator task: "Visit the LinkedIn profile of the prospect whose
email is below. Read their 3 most recent posts. Return a 3-sentence
summary of what they have been publicly writing or commenting
about. Focus on stated priorities, problems they care about, or
projects they have shipped. If you cannot access the profile,
return exactly the string 'PROFILE_INACCESSIBLE'.

Prospect name: {{1.signature.firstName}} {{1.signature.lastName}}
Company: {{step2.companyName}}
Email: {{1.from}}

Return JSON exactly: { 'summary': , 'profileUrl':  }"

LinkedIn is the only site in this pipeline that genuinely resists automation. Operator handles it better than most agents because it does not have to scrape HTML — it reads the page like a human. The blocker is rate limiting: LinkedIn will 403 Operator after about 8 consecutive profile visits in 5 minutes. The fix is a Make Sleep module between the LinkedIn task and the next one, set to 45 seconds. The total cost of the 45-second sleep across a 50-lead day is 37 minutes of wall time, but it runs while I am asleep, so it does not matter.

The PROFILE_INACCESSIBLE literal is the same trick I used in the lead-routing pipeline. About 1 in 8 prospects either has a private profile or has not posted in the last 90 days. The prep doc composer treats that literal as a signal to skip the priorities section and write a generic-but-competent version.

Step 4 — Cal.com booking

For qualified leads, Operator's third task is the booking. This is the part of the build that I was most skeptical about, because Cal.com's booking UI is not a clean API. It is a page with dropdowns and a timezone selector. Operator has to read the prospect's inferred timezone (from the email signature — most US B2B senders are in America/New_York, America/Chicago, or America/Los_Angeles) and click through the booking flow as a human would.

The instruction set is the longest of the three:

Operator task: "Book a 30-minute onboarding call between the
prospect below and one of our three AEs (round-robin). Use the
Cal.com booking page for our team.

1. Open https://cal.com/team/logitech-co/onboarding-30m
2. Set the timezone to {{step2.timezone}} (inferred from email
   signature; default to America/New_York if unclear)
3. Find 3 available slots in the next 5 business days
4. For each slot, click it, enter the prospect's full name and
   email, add the note 'Inbound demo request — {{step2.score}}/5
   ICP fit', and capture the booking URL
5. Send the three booking URLs to the prospect via Cal.com's
   email integration with subject: 'Pick a time for your
   LogiTech onboarding call'
6. Return JSON exactly: { 'sentSlots': [],
   'prospectEmail':  }"

The Operator behavior I am relying on here is the takeover mode. When Cal.com asks Operator to enter a payment method, Operator will pause and ask me to take over. I have trained it to never store a payment method in its session for this booking flow. The takeover pause does not block the pipeline — by the time Operator asks, the prospect already has the three slots. The pause only delays the calendar invite confirmation by 12–60 seconds. Across 180 bookings, I have had to manually take over 4 times. None of those was a real failure.

The bigger risk with Cal.com is timezone inference. Email signatures are not always reliable. The fix is the default-to-New-York clause and a 1-line note in the booking email: "If the times below do not work in your timezone, reply with three times that do and I will adjust." That line has saved more bookings than any other change I have made.

Step 5 — The prep doc composer

The prep doc is the smallest LLM call in the pipeline, and the one that has the highest measurable impact on show rate. The input to Make's OpenAI module is four fields:

{
  "companyName": {{step2.companyName}},
  "prospectName": {{1.signature.firstName}},
  "prospectRole": {{step2.buyerTitle}},
  "priorities": {{step3.summary}},
  "industry": {{step2.industry}},
  "employeeCount": {{step2.employeeCount}}
}

The system prompt is the prep doc template, with a hard 200-word cap:

You are writing a 200-word prep doc for an inbound prospect's
onboarding call. Use only the data provided. Do not invent
company details.

Structure:
- 1 sentence: what the prospect's company does (in their words,
  from the website you read)
- 2-3 sentences: the 3 priorities you inferred from their
  LinkedIn. If priorities are unavailable, write: "We did not
  have recent public posts to draw from, so we will spend the
  first 5 minutes on discovery."
- 5-7 bullet points: 5-7 specific topics we will cover on the
  call, each tied to one of their priorities
- 3 discovery questions we will ask them, written as questions,
  not statements

Tone: direct, specific, no hype. Address {{prospectName}} by
first name. Total length: 180-220 words.

The output is a Markdown body that Make sends via Gmail 24 hours before the call, with subject: "Prep doc for our {{callTime}} call — {{companyName}}". Show rate on calls that received a prep doc: 85%. Show rate on calls that did not (early test bucket): 61%. That 24-point lift is the single biggest ROI number in the whole pipeline.

Step 6 — The manual queue and the three failure modes

The pipeline is not "all leads are qualified by an agent or declined." It is three exits: qualified (full flow), decline (polite auto-reply with a self-serve link), and manual (lands in a Slack channel for a human to triage). The manual queue is where the audit happens. Every Monday at 9:00 a.m., a Make module posts the prior week's manual verdicts to #sales-pipeline-auto with a single button per lead: "I qualified it" or "I declined it." Humans audit the agent's decisions in batches, not in real time.

Three failure modes that have actually cost me time, in order of frequency:

Operator cannot find the company website. 12% of inbound leads use personal Gmail/Outlook with no company name in the signature. The agent returns verdict="manual", the lead lands in the queue, and a human triages within 24 hours. The fix is not to make Operator more aggressive about guessing — that produced 4 misqualified leads in the first month. The fix is to lean into the manual queue and audit it.

Operator misreads the ICP rubric on a specific criterion. Most often this is criterion 5 (timing signal). The rubric is supposed to award a point if the body mentions a specific problem, timeline, or vendor replacement. Operator tends to over-credit vague phrases like "looking to improve our analytics" as a timing signal. The fix was to expand the criterion: the body must mention one of [a specific tool name they want to replace, a date or quarter, a budget range, or an active RFP]. Now over-creditting has dropped from 7% to 1%.

Cal.com takeover mode pauses the booking for too long. Twice, Operator has paused on Cal.com's "Add a payment method" prompt and stayed paused for 2+ hours because no human was watching. The fix is a Make watchdog: 90 minutes after the Operator task starts, if no booking confirmation has been logged, Make kills the scenario, posts to #sales-pipeline-errors, and the lead goes to manual. The cap on the longest booking latency since the watchdog was added: 47 minutes.

The human audit loop that keeps it honest

I run a 15-minute review every Friday. Three things I look at:

1. The week's decline verdicts. Did any of them get a "wait, I actually wanted that one" reply from the prospect? Across 14 weeks, that has happened twice. Both were borderline cases that the rubric correctly scored 2/5 — the human reviewer's call was to manually re-engage.
2. The week's manual verdicts. How many should have been qualified or decline? Across 14 weeks, 71% of manual leads were correctly forwarded to a human; 19% were qualified once a human checked the company website; 10% were genuinely decline. The 19% number is the one I watch — if it climbs above 25%, the rubric is too strict and Operator is over-escalating to manual.
3. Prep doc quality. I read 3 random prep docs from the week, scored against 4 questions: Did it invent anything? Did it correctly cite the prospect's priorities? Did the discovery questions feel specific? Did the tone match our brand? Across 14 weeks, 11 of 42 randomly-sampled prep docs needed a one-line edit before the call. 3 needed a full rewrite. None was a credibility problem for the prospect.

The 11/42 number is the operational floor. The agent gets 74% of prep docs right on the first pass. A human edits the rest in 90 seconds. The previous human-only workflow produced 100% right-on-the-first-pass, but it took an AE 30 minutes per lead. The agent produces 74% at zero AE time, and the remaining 26% at 90 seconds. The math is the point.

The honest accounting

Six months in production. 412 leads processed. 68% qualified, 24% declined, 8% manual. Show rate on booked calls: 85% (up from 61% on the old human-coordinated flow). Median time from inbound to booked: 4 minutes 12 seconds. Operator cost per lead: $0.38. Make operations cost per lead: $0.04. Total monthly cost at our 60-lead volume: $25. AE coordination time saved: about 4–5 hours per week, or roughly 200 hours per year. Those 200 hours have been re-allocated to actually running the calls, not scheduling them.

The single number I am most proud of: the prep docs are better than the ones humans used to write. The humans used to skim the company website for 10 minutes and write a generic version. The agent reads the website, reads the prospect's recent LinkedIn, and writes a 200-word brief that names the prospect's actual priorities. AEs have stopped editing prep docs and started forwarding them to prospects as-is. That is the win — the work the agent produces is good enough that nobody wants to redo it.

If you build it, start with the rubric, not the Operator task. The rubric is what makes the qualification auditable. If the rubric is good, the Operator task can be a 4-line wrapper and still produce decisions a human can defend. If the rubric is bad, the Operator task will qualify nonsense and you will spend every Friday re-running the audit by hand.

The first lead the agent books without you touching it is the one you will remember. It was the sandwich moment for me. The sandwich was fine. The pipeline was the thing that changed.