ZoomInfo SDR Playbook: Direct Dials, Website Data, and the LinkedIn Extension in an Agent-Native Workflow

Every week, I talk to a RevOps leader who is trying to answer the same question: how does the LinkedIn extension fit into an agent-native prospecting workflow? It's a fair question. It's just not the first question. The first question is who is actually doing the prospecting—your SDRs, your automated sequences, or your AI agents.

I'm the person who gets called when a campaign is days away and the target list isn't ready. In the last five years, I've coordinated 200+ rush list requests for B2B sales teams. Maybe 40 of those were true emergencies—same-day or next-day turnarounds. The rest were normal requests that sat in a queue until the deadline scared someone. When it's 36 hours before launch, it's basically triage: what can we do with the data we have, and how fast can we make it usable? I've used ZoomInfo for most of those jobs. And I keep coming back to the same lesson: there isn't one “right” way to use it. There's a right way for your workflow.

The short version

Here's the shortest answer I can give: in an agent-native workflow, the LinkedIn extension is not the agent's data pipeline. It's the human exception layer. Agents should pull structured data from ZoomInfo—direct dials, org charts, intent signals—through the platform or its API. The extension belongs in a browser where a human is trying to decide, “Do I trust this record?” or “Why did the agent flag this account?”

That answer fits one of the three main workflows I see. Let me break all three down, because the LinkedIn extension is a game-changer in one of them and basically a distraction in another.

Three workflows, three answers

Workflow 1: The human-first SDR team

What it looks like: Each SDR owns 15–30 accounts per week. Research is manual: LinkedIn profile, company website, a few targeted searches. The CRM is the system of record, but the real work happens in a browser tab.

If this is you, the LinkedIn extension is incredibly useful. It gives context without forcing you to leave the page. You see a job change, click the extension, find a direct dial, and move on. This is the workflow the extension was built for.

How to use it: Use the extension as your research companion, not your database. Build your initial list with natural-language prospecting on the ZoomInfo website. Try something like “Series B SaaS companies in Chicago with a VP Sales hired in the last six months.” Save the list. Then use the extension while you're researching individual accounts, because it lets you confirm details before you enter them in the CRM.

Direct dials are still valuable here, but you don't need a perfect phone number for every contact. You need a fast way to decide whether a contact is worth a call. The extension gives you that speed.

Where it struggles: if you try to make the extension the center of a scaled pipeline, it becomes the bottleneck. I've seen teams with 15 SDRs, all running the same extension, all rebuilding the same lists. That's a red flag.

Workflow 2: The scaled playbook

This is the team that has moved from “researching accounts” to “executing a repeatable outbound process.” SDRs handle 50–100 accounts per week. Sequences are automated. The CRM is the engine. The LinkedIn extension has a smaller job here.

Use natural-language prospecting to define segments once and refresh them on a schedule. Use intent data and website signals from ZoomInfo to decide which accounts enter a sequence. Move direct dials into a CRM field, not a browser lookup. If a rep is spending more than a few minutes per account in the extension, something is wrong.

You don't need to uninstall it. You need to demote it.

One thing that helped us: use the extension as a QA tool. When a batch of imported contacts looks off, the fastest check is opening a LinkedIn profile and seeing whether the data in front of you matches. It's a spot-check, not the whole workflow.

Workflow 3: Agent-native workflow

This is where the conversation gets interesting. In an agent-native workflow, AI agents are doing the list building, enrichment, and maybe even the first-round personalization. Humans set the strategy and review exceptions.

The LinkedIn extension is not built for agents. It's a browser extension. Agents don't browse; they query. I'm not an AI engineer, so I can't speak to API rate limits or the best way to build an orchestration layer. What I can tell you from a RevOps perspective is that the extension is a human-in-the-loop surface.

Here's how it fits:

1. An agent builds a segment with natural-language prospecting.
2. It pulls direct dials from ZoomInfo.
3. It writes personalized lines using company data from the ZoomInfo website.
4. When a record fails verification—or an agent flags a signal that doesn't match your ideal customer profile—a human opens LinkedIn, the extension surfaces the ZoomInfo data, and the human decides yes or no.

The counter-intuitive part: the more agent-native your workflow gets, the less important the LinkedIn extension becomes. You don't need it for high-volume enrichment. You need it for judgment calls.

So how does the LinkedIn extension fit into an agent-native prospecting workflow?

Direct answer: it fits as a review layer, not a data source. Or rather, it should. Honestly, I'm not sure why this extension gets so much attention from teams building agent-native workflows. My best guess is that it's visible. The extension is what people see in the browser; the agent pipeline is invisible. So everyone assumes the extension must be the center. It isn't.

Why do people get this wrong? Because we've been trained to think of a LinkedIn extension as a magic button. Click it, see everything. In an agent-native workflow, that magic button doesn't scale. The agent should be doing the clicking—conceptually, at least. The extension is for the human who has to approve the agent's work.

I once told a team, “we have an agent-native workflow,” and they heard, “we have an agent.” Result: two weeks of people feeding the agent the same lists it was supposed to replace. Discovered this when the SDR team asked why they still had to do data entry. We were using the same words, but we meant different things.

If you can't explain the review-layer role to your team, you'll end up with a bunch of SDRs manually checking data that an agent already checked. That's not a workflow; that's a waste.

Direct dials and website data: where they matter

Let's isolate two ZoomInfo features that get lumped together too often.

Direct dials. Direct dials matter because calling still works. But a phone number is only useful when it's attached to the right person. In Q3 2024, one of our campaigns pulled 1,200 contacts with direct dials. Before upload, a teammate spot-checked a sample and found two numbers that were no longer valid. That was enough. It reminded us that direct dials are a starting point, not a guarantee. The verification step is what makes the list usable.

The bigger mistake I see is treating direct dials as the entire strategy. A direct dial for someone who left the company two months ago is worthless. The ZoomInfo website shows you the org chart before you dial—use it.

Website data. The ZoomInfo website is where intent and firmographics come together. It's not just “company size” and “industry.” It's “which companies are showing buying signals right now.” In an agent-native workflow, that data is a routing signal: this account is showing intent, this one isn't, this one has hiring patterns that match your ideal customer profile.

If you're a ZoomInfo SDR, this is the part of the platform I'd learn first. It tells you who to call and when to call them. The LinkedIn extension can't do that. It can only show you one profile at a time.

Natural-language prospecting is the missing layer

Let's talk about natural-language prospecting for a minute, because I don't think people appreciate how much it changes the conversation.

Years ago, building a list was a filter-stacking exercise: industry equals x, employee count between y and z, title contains “vice president.” Then you'd export, clean, and enrich. Natural-language prospecting changes that to a sentence: “Find me fintech companies in New York that have recently hired a head of sales and are actively buying data infrastructure.”

This isn't just a nicer search box. For an agent-native workflow, it's basically the interface. Agents can parse natural-language requests from humans, translate them into structured queries, and act on the results. That's why I keep telling ZoomInfo SDR teams to practice writing these prompts. The better your prompt, the better your list.

In March 2024, a sales leader came to me 36 hours before a campaign. The original list had been built manually over three weeks, and 18 of the 40 target accounts had changed ownership. We rebuilt the list with a natural-language query, pulled direct dials, and ran it through email verification. It wasn't perfect—I do not want to pretend it was—but the campaign went out on time.

A rule of thumb

I use this rule with every team I work with:

If a human is the bottleneck, move the task to a query. If a machine is the bottleneck, move the task to a human.

That's the whole philosophy behind an agent-native prospecting workflow. Natural-language prospecting is how a human tells the machine what to do. Direct dials and website data are what the machine brings back. The LinkedIn extension is where a human says, “This one is worth it.”

Which workflow are you in?

If you're still not sure, here's a quick diagnostic. Ask yourself three questions:

• How many accounts does a single SDR really handle per week? Under 30, you're probably workflow 1. Between 50 and 100, you're workflow 2. If you're not sure because an agent is doing the heavy lifting, you're workflow 3.
• When a target list needs to change, who updates it? If a person rebuilds it by hand, you're in workflow 1 or 2. If you can type a new natural-language query and an agent generates a new segment, you're in workflow 3.
• Where does LinkedIn live in your stack? If LinkedIn is where your data comes from, you're more human-first. If LinkedIn is where your data gets checked, you're more agent-native.

Answer honestly. There's no prize for being the most automated team. I've seen a two-person SDR shop beat a fully “AI-powered” pipeline because they knew their accounts inside out. I've also seen a 50-person team scale beautifully by letting agents do the boring parts and humans do the judgment calls.

Bottom line

The question “how does the LinkedIn extension fit into an agent-native prospecting workflow?” has a simple answer: it fits as a human checkpoint, not as the agent's engine. But the exact setup depends on your team, your volume, and how much of the work you're ready to hand to an agent.

Use natural-language prospecting to find the needle. Use direct dials and website data to make that needle actionable. Use the LinkedIn extension for the moments a human needs to look at a record and say, “This one is worth it.”

That's the workflow that actually scales.