Most teams that buy website visitor identification end up with a very expensive dashboard. RB2B tells you a VP of Sales at a target account just read your pricing page. Then the name sits in a Slack channel, a CSV, or an SDR's "I'll get to it" pile. By the time anyone calls, the buyer is three vendors deep.
So I built an agent in Aurasell's Agent Builder to handle the handoff. It watches every RB2B identification, decides in seconds whether it's worth a rep's time, routes it to the right person, and drops an urgent call task with a script into their queue. I never wrote a line of YAML. I described what I wanted in plain English, and the builder wrote the agent.
TLDR (but please do read): median time from website visit to a task in a rep's queue is 61 seconds. Opportunities created on accounts it touched total $1.25M in influenced pipeline.
This post includes everything: what the agent does, the math on what it produced (caveats included), every prompt I used to build it, what broke, and the call script. Steal all of it.
The model: a precision filter, not a lead router
Most routing logic asks "who gets this lead?" This agent asks a better first question: should anyone get it at all? A visit has to clear every gate below before a rep sees a task. When it clears, the task is urgent, due today, and arrives with the script.
Three agents do the work. Agent A is the core play above. Agent B waits for a rep to complete the call, then adds the follow-up email task, because a call can close days after the visit. Agent C listens for Agent A's failed runs and immediately emails me the failed step and the reason.
Two design choices matter more than the rest:
Silence is a feature. Competitors, repeat visits, and our own team stops without a word. Low-fit visits go to a once-a-day digest instead of an inbox. Only a qualified task or a broken run interrupts a human.
Existing relationships get an email, not a task. If the account is a customer or has an open opportunity, the owner hears about the visit and decides what to do. Nobody cold-calls a customer because they read the docs.
The math
The agent is designed as a precision filter. Most visits end quietly, and a rep gets a task only when the visit is worth a dial. Here's what those tasks produced:
Metric | Result | How solid |
|---|---|---|
Median time from visit to task | 61 seconds | Measured directly |
Connect rate per completed call | ~20% | Directional |
Meeting rate per completed call | ~10% | Directional |
Pipeline on touched accounts | $1.25M | Influenced |
Two notes on those numbers. The connect and meeting rates are directional: calls link to conversations only at the account level, and reps don't log every dial, so the real rates are likely higher. The pipeline is influenced, not sourced: it counts any opportunity created on an account after the agent touched it, whatever the opp's recorded source.
Why 61 seconds is the number that matters
The HBR study of 1.25 million inbound leads found that companies that called within an hour were seven times as likely to qualify the lead as companies that called an hour later, and more than 60 times as likely as those that waited a day or more.
That study measured hand-raisers who filled out a form. An RB2B visitor never raised a hand, so the window is, if anything, shorter. At 61 seconds, the task lands while they're still on the site. Whatever happens after that is on the rep, not the routing.
The meeting rate only counts calls to visitors who cleared every gate. That's the point: the filter is what makes the calls worth making. Compare it against your own cold-call meeting rate before you decide whether it's good.
How I built it: one paragraph, then one sentence at a time
The finished core agent is hundreds of lines of YAML. I wrote none of it. Agent Builder generated the agent from plain English, and I made every change after that with a one-sentence prompt in the same thread.
That is the real lesson here. Don't try to spec everything out front. Describe the shape, ship it, watch it run, and fix one thing at a time.
Prompt 1: the shape
Build an agent triggered when RB2B identifies a website visitor (cdc.cri-core.activity, source rb2b). If a person is identified, enrich them and create a dialer task for the account owner with a call script; if only a company is identified, find the best buyer-persona-fit contacts and task those. Skip accounts that are current customers or have open opportunities. Dedupe so each visitor only generates one task per day.That one paragraph produced the trigger, the person and company branches, enrichment, the customer and open-opp gates, dedup, task creation, and the call script. Everything below is refinement.
Prompts 2 onward: one fix per prompt
I put each of these into the same thread after watching real runs. I grouped them by the job they did.
Keep junk out of reps' queues
If account_status = competitor, disqualify silently. No tasks or emails.Remove anyone from Aurasell AI from the notifications.Handle the company-visitor case: when RB2B resolves a contact with no real person data and a /company/ LinkedIn, send a company-style notification with no dialer task.Catch the right people, not just the obvious ones
Loosen the persona gate to also include any Sales, Revenue, GTM, Account Management, Business Development, or Growth titles.Run persona matching before the gate, with an AI fallback for titles the deterministic match misses.Make it fast and route it right
Make all created tasks due today (24h SLA) and urgent.Change the SDR fallback: route EMEA-HQ accounts to our EMEA SDR; round-robin everything else across the US SDRs.Remove phone and email from the visitor notification.Make it quiet when it should be, loud when it breaks
Add a step that, if a run fails, emails me immediately.Make the skip notifications (ICP too low, no persona match) silent instead of emailing me each one.Make it better
QA the failed runs.Optimize this agent.Those last two did more work than any other prompt on the list. More on that in what broke.
Prompt 3: the daily digest (a new thread)
Once skips went silent, I still wanted to see them, just once a day instead of once per visit.
Build a scheduled agent that runs daily at 6pm and emails me a summary of the RB2B Sales Play: total runs (completed/stopped/failed), and a per-SDR breakdown of tasks created (pending/complete/overdue). Pull the skip events (rb2b.sales.play.skip, reasons no_role_persona_match and icp_too_low) for the skip section. Skip the email if there were zero runs.Count it up: about a dozen sentences. The output was three coordinated agents, a US round-robin queue, persona matching with an AI fallback, and a daily report. The traditional version of this is a RevOps project with a ticket, a sprint, and a backlog.
What broke
The prompts give you the shape. Production gives you the edge cases. Here's every bug that actually bit, in the order it showed up. I found each one the same way: I noticed failed runs and typed, "QA the failed runs."
1. The no-owner crash. When I asked for customer and open-opp visits to email the account owner, the builder added a step that read the owner's email off the account. Plenty of our accounts have no owner. Reading an email address off a non-existent owner crashed the step, and the default-value wrapper never ran because the crash happened first. Every failure traced to that one step. The fix was one character: safe navigation:
owner.email_address → owner?.email_addressThe ?. returns empty instead of crashing, so the default can kick in.
2. The same crash, somewhere else. A second batch of failures showed up later. Same bug, different place: the routing step checked the owner the same unsafe way, on both the person and company paths. The first fix patched one spot without searching for the pattern anywhere else. Round two applied it to all 10 owner lookups, then re-ran the exact visit that had crashed. It completed and routed correctly to the SDR queue.
Lesson: when you find a bug, ask "where else does this pattern exist?" before you ask "is it fixed?"
3. Two bugs the optimization caught before they shipped. "Optimize this agent" converted the slow AI guard into plain logic. It went from about 137 seconds to about 3. Before pushing, the builder dry-ran the new version against real data, and that caught two bugs:
Dedup was counting the wrong records. The new version counted every activity the endpoint returned (192) instead of only the ones tied to that contact (6). It had dropped the association filter the original used. That would have broken dedup completely, and silently. A real cluster of duplicate visits exposed it.
Accounts with zero opportunities crashed the count. They returned an empty list, and reading the first result failed. Now it's null-safe.
Lesson: use AI where you need judgment and plain logic for lookups. Then dry-run the conversion on real data instead of trusting it.
4. Query formatting, caught in the dry run. The native query step needed its fields listed alongside the count, and its results came back in a different shape than the old tool's. Both were fixed before going live. Minor, but "same logic, new step" is still new code.
5. The enrichment error. For some people, the directory couldn't resolve the person, and the enrichment step returned an error. Enrichment had no error tolerance, so one failed lookup killed the whole run and lost the visitor. The QA pass sorted failures by agent version and isolated these on the live one. The fix: all three enrichment steps are now best-effort (continue_on_error: true). If enrichment fails, the run keeps going with what it has, and the rep's email flags limited contact data.
The pattern
Every bug that reached production (1, 2, and 5) had the same root: real-world data with something missing. Accounts with no owner. People the directory can't find. Your CRM has both.
So before you ship, add one more prompt to your list:
Audit every step for null and missing-data cases. Make every lookup null-safe, and make every best-effort step (enrichment, research) continue on error.The bugs that never shipped were caught for one reason: you tested the change against real duplicates and real customers instead of trusting it. That's the habit to copy.
Run it Monday
Find out what happens to your identified visitors today. Pull the last 30 days of RB2B identifications. For each one, check whether anyone touched that person or account within 24 hours. That number is your baseline, and for most teams it is painful.
Write your version of Prompt 1 and ship it narrow. Swap in your exclusions, your personas, and your routing. Point it at one rep or a test queue for the first week. Turn on the failure email on day one, not day ten.
Spend week one in QA mode. Every morning, read the failed and skipped runs, then fix one thing per prompt. When failures stop surprising you, open it to the whole team and add the daily digest.
Steal it
The decision table
This is the whole agent in one table. Settle these outcomes with sales leadership before you build, and your Prompt 1 mostly writes itself.
When the visitor is... | What happens | Who hears about it |
|---|---|---|
A competitor, a repeat visit today, or your own company | Stops silently | Nobody |
A current customer or an account with an open opp | No task | Account owner gets an email |
A person with no persona or role match | No task | Rolls into the 6pm digest |
A company below 50% ICP match | No task | Rolls into the 6pm digest |
An ICP company with no persona contacts yet | Contact backfill kicks off, no task | Account owner gets an email |
A qualified person or company | Urgent call task, due today | Assigned rep gets an email |
A run that fails | Nothing reaches a rep | Failure email to the builder, immediately |
The persona gate also passes anyone whose title or department includes sales, revenue, RevOps, GTM, go-to-market, account management, business development, or growth. That list is ours. Yours should be your buyer's titles.
The call script
This is the script that rides in every call task. It works because the rep demonstrates the product on the call. Swap in your own product and your own proof.
Hey [first name], it's [rep name] over at [company]. You popped up on my radar and our platform flagged it. I'm going to send you an email right after I hang up that shows you exactly how that happened, a quick 2-3 minute Loom. I'll have it in your inbox before you even set the phone down.
IF THEY ANSWER AND BITE ("wait, how'd you know?")
Short version: our platform identifies companies landing on your website, even the ones who never fill out a form, so your team can reach out while they're still interested instead of guessing.
And here's the part I love. I'm not even the one who spotted you. We built an agent that watches for this stuff, and the second your company showed up, it created a task telling me to follow up. So this call? A rep somewhere at your company could be making the exact same one, teed up automatically, instead of digging through data hoping to catch something. I just did to you what we help you do to your buyers.
IF THEY'RE SKEPTICAL OR RUSHED
"Totally fair, I know cold calls are annoying. I'll keep it to one thing: watch the Loom when you get a minute today. If it's not relevant, hit reply and tell me to buzz off, no hard feelings. If it is, we grab 15 minutes. Sound good?"
CLOSE
"Perfect. Sending it the second we hang up. Keep an eye on your inbox. Subject line's got your name on it. Talk soon, [first name]."If you don't sell visitor identification, the meta-move won't transfer. The structure will: say why you're calling in the first sentence, promise one short asset, and give them an easy out.
The follow-up agent
A call can close days after the visit, so the follow-up email lives in its own small agent. Here's a starting prompt:
Build an agent triggered when a call task whose title contains "RB2B Web Play" is marked complete. Create a high-priority email task due tomorrow for the same rep and the same contact, telling them to send a 2-3 minute Loom that explains how we spotted the visitor and references the call they just had.I work at Aurasell, which makes Agent Builder. Views are my own.