Someone told me recently that they found this practice by asking ChatGPT who to bring in to set up ZoomInfo and Salesloft for their sales team. Fair question. I want to answer it the way I would on the call: the configuration is not the hard part. The hard part is the month after, when both tools are technically live and the reps are quietly working around them.
I have walked into teams that owned both, paid for both, and still had reps hand-searching contacts that were already in the database they were paying for. The tell was not a metric. It was that the reps had quietly stopped using it.
One note on scope before the steps. I have run this setup with ZoomInfo and Salesloft, and with Outreach and Gong Engage on the sequencing side and Seamless and LeadIQ on the data side. The breakages below show up in every pairing, because none of them are tool bugs. Where ZoomInfo or Salesloft does something specific, I say so.
Most companies hand this to RevOps, and most RevOps teams are generalists by design. They own the CRM, the routing, the reporting, the comp plan and a dozen integrations, and they are good at Salesforce because everything runs through it. Ask the same team to set a sequencer's reply rules, a data tool's duplicate logic or a dialer's disposition set, and the depth drops fast. Not because they are not capable. Because nobody on that team has sat in the seat those tools were built for.
The vendor will not close that gap for you. Salesloft's onboarding assumes you arrive with your lists, your cadences and your rules already decided, and the white-glove tier that does more of it costs extra and still needs someone on your side who knows what they are looking at. The rollouts that work have that person. This is not a RevOps project. It is a sales development project that touches RevOps.
The short version
- Pick one system of record and make the other two read from it. ZoomInfo feeds the CRM. Salesloft reads from the CRM. Nothing bypasses it.
- Enrichment has to land where the rep looks. If job function, direct dial and management level sit on the account object or in a hidden field, the rep does not have them.
- A reply removes a person from the cadence. It does not pause them. Same for "left company." Pausing creates records that look worked and are not.
- Gate the first touch on research, not on list arrival. A list landing in Salesloft is not permission to send.
- Credits are spent last. Search is free. Build and review the list on the free record, and pay only for the people who will actually be emailed.
- Measure nobody until the data path is verified. Fix the pipe before you read the gauge.
One question decides everything after it
Before any field is mapped: which system is the record? For almost every team the answer is the CRM, Salesforce or HubSpot. ZoomInfo is a data source that writes into it. Salesloft is an execution layer that reads from it and writes activity back. The moment ZoomInfo exports straight into Salesloft, you have people in the sequencing tool with no CRM record, and three months later nobody can tell you who was worked, by whom, or what came of it.
This sounds obvious. It is also the first thing I find broken, because the built-in ZoomInfo-to-Salesloft export is a click and the CRM route is an afternoon of field mapping. Teams take the click. Tools amplify clarity or confusion. They never fix it.
ZoomInfo: the data has to reach the rep's screen
The most common ZoomInfo failure I see is good data that lands somewhere the rep never looks.
On one team the enrichment was owned by RevOps. It ran, the fields filled, and the reps had no idea. Their lists came out of a different view with no phone number and no job function on them, so they opened LinkedIn and started searching by hand for contacts the company had already paid for. Nobody was lying about adoption. Nobody could see where the data was.
The order I set it up in:
- Map enrichment to contact-level fields the rep can see, and put those fields on the list view they actually work from. Job function, management level, direct dial, mobile where licensed. If the rep's working list does not show those columns, the enrichment might as well not have run.
- Set enrich-on-create and the scheduled refresh, then check both fired on a record you created yourself. Do not trust the status screen. Open the record.
- Define the duplicate rule before the first bulk export. Match on email first, then on name plus company domain, and decide in writing what happens on a match: update, skip or flag. Most instances I inherit are set to create, which is how an account ends up with four copies of the same VP.
- Build saved searches that mirror your lead pools, not one giant ICP filter. If the motion has four pools, there are four searches, each named the same thing the CRM list is named.
- Make the integration user a service account. When the sync runs as a real person and that person leaves, it stops the day their license is deactivated, and it takes a week for anyone to work out why the fields went stale.
Then the check I run at the end of week one: pull the list a rep is working from today and count how many rows have a phone number and a job function. On a team I walked into this fall, the first list that arrived had a few hundred records and neither column was populated. That looks like a rep adoption problem from the manager's chair. It is a data path problem wearing one.
ZoomInfo: credits are spent last
The second ZoomInfo failure is the credit bill, and it comes from pulling contacts before anyone has looked at the companies. On a team I am setting up now, a publisher whose reps each work one city at a time, the first search for one market matched about three thousand people. A launch for one rep is a few hundred. The gap between those two numbers is the credits most teams burn.
Under ZoomInfo's current API rules, searching is free and paying happens only when you redeem or enrich a record, one credit per person, and a record you have paid for stays free for a year. I run the list build through the ZoomInfo MCP in Claude, which is the same API, and the whole method follows from that one boundary:
- Companies first, free. Headquarters only, downtown zip plus a radius sized to the market, the rep's revenue floor, the industries in and out. Never the metro-region filter; it is too wide and it is a different parameter, so the mistake cannot happen by accident. The free record carries name, website, city, revenue and headcount, which is everything a rep needs to say yes or no to an account.
- Scrub by name. ZoomInfo files hospitals under business services and residential architects under architecture. A name scan for health, clinic, college, county, bank, law and the rest catches most of it. Foreign entities with a local address come out. Same-name pairs with different websites get flagged.
- The rep reviews the company list before a single contact is pulled. Prior clients, open pitches, personal relationships, companies already called. This is the gate, and it costs nothing because nothing has been bought yet.
- Contacts, still free. Search the approved companies for the title. Filter on whether an email or a phone exists and on the accuracy score before you look at a single name. Drop assistants, emeritus titles, year-range titles and anyone not verified in two years from the free record, not after the purchase.
- One person per company. Two CEOs listed is common; pick by email-domain match, clean title and verification date, and note the reason. No CEO means the marketing lead. Nobody gets two people from one company in the same cadence.
- Now spend. Enrich the final picks only. Credits spent equals contacts delivered to the rep, not contacts considered. Check which records are already under management first; those are free again.
Two things the API does that the screen does not: the audience builder in the interface capped that three-thousand-person market at the first 500 rows, and the search endpoint pages to ten thousand for free, so the whole market is visible before a decision is made. And the filters on email, phone and accuracy score run before the pick, which is what shortens the removed-rows file. The credit is the last thing that happens, not the first.
Salesloft: the cadence has to remove, not pause
Salesloft cadences are where the next failure lives, and it is almost always the same one. A prospect replies. The cadence pauses them. The rep is busy, the reply sits, and in every report that person shows up as worked. A few weeks later the cadence is full of paused people, a manager is asking why reply rate is up and meetings are flat, and nobody has opened the replies.
The fix is a rule rather than a feature: any reply removes the person from the cadence and creates a task owned by a named human. The same rule covers the "left company" call disposition, which I regularly find set to pause. A person who has left the company is not paused. They are gone, and the account needs a new contact.
The rest of the Salesloft setup, in order:
- Field mapping from the CRM, both directions. Activity writes back to the CRM. Account and contact fields read in from it. Check the mapping on a record, not in the settings screen. On one team the engagement platform's tasks were not syncing to Salesforce at all, and the pipeline reports had been understating most of the team for a quarter before anyone caught it.
- One cadence per lead pool, named identically to the CRM list and the ZoomInfo search. If a rep cannot tell from the name which cadence a person belongs in, there are too many cadences or the names are wrong.
- Step count and duration set from the motion, not from a template. The standard I run is about a month long with roughly fifteen touches across email, phone and LinkedIn, but the exact number matters less than every rep running the same one, so the results can be compared across people.
- Dispositions defined and enforced. A call with no disposition is not a call. I have watched a rep log two hundred dials in a day with no email sent and no disposition on any of them, and the activity report counted every one.
- Daily send limits checked against list sizes. One team loaded a webinar follow-up list big enough to consume the whole team's daily send limit for days, and the outbound cadences silently stopped sending. Nobody set out to do that. The list was bigger than the pipe.
The research gate
A list arriving in Salesloft is not permission to send. The flow standard I run puts a research step between the list and the first touch: the rep confirms the account is a fit, confirms the contact is in the right function at the right level, and writes the one line of context the first email opens with. A few minutes per account, and it is the difference between a cadence that earns replies and one that earns unsubscribes.
It also repairs a reporting problem. Without the gate, "added to cadence" means a list was uploaded. With it, "added to cadence" means a person looked at the account and decided to work it. Only the second one is a number worth managing to.
Measure nobody until the pipe is verified
The strongest advice I can give on a ZoomInfo and Salesloft rollout is the order of operations at the end. Fix the data path. Verify it end to end on a handful of real records. Show every rep their own number against their own target, in the tool, before anyone is measured on it.
Then measure. Measure first and the reps optimize for the gauge, the gauge is reading a broken pipe, and you have built a team that is very good at producing numbers that do not mean anything. I have inherited that team more than once. I think it is a worse starting point than no tools at all.
What I would want to see before I called it done
- A record created in the CRM today shows enriched job function and direct dial within the hour, and the rep can see both from their working list.
- Every cadence has the same reply rule and the same "left company" rule, and both remove rather than pause.
- A call logged in Salesloft appears on the CRM activity timeline, with a disposition.
- The ZoomInfo search, the CRM list and the Salesloft cadence for a given lead pool all carry the same name.
- The integration user is a service account nobody will ever offboard.
- Each rep can open one screen and see their own number against their own target.
- The credit report for the month is within a few percent of the number of contacts delivered to reps.
If those seven things are true, the tools are set up. If they are not, the tools are installed, which is a different thing and the one most teams are paying for. This is the work we do when we run outbound inside a client's own stack, and it is most of the first month.
Questions this gets asked as
Who do you hire to set up ZoomInfo and Salesloft for a sales team?
Someone who has run a sales development team on these tools and will run yours inside them after the setup, not an administrator who hands over a configured instance and leaves. Your RevOps team can administer ZoomInfo and Salesloft; they have rarely run a sales development team on them, and that is the difference between configured and used. The configuration is a week. The failures show up in month one, when a rep opens a list with no phone numbers on it and goes back to LinkedIn. This is part of what SantiXS does when it runs outbound inside a client's own stack.
How long does a ZoomInfo and Salesloft implementation take?
In my experience the technical setup is a few days if the CRM is clean and two to three weeks if it is not, because most of the time goes to field mapping, duplicate rules and deciding who owns enrichment. Reps should be working from the new setup by the end of week two. Measuring them on it should wait until the data path has been verified end to end, which for me is the day-30 readout.
Should ZoomInfo push directly into Salesloft or go through the CRM first?
Through the CRM. ZoomInfo into Salesforce or HubSpot, then the CRM into Salesloft, so the CRM is the one record everything else reads from. Pushing straight from ZoomInfo into Salesloft creates people in the sequencing tool who do not exist in the CRM, and three months later nobody can reconcile who was worked.
What is the most common mistake when setting up Salesloft cadences?
Letting a reply pause the cadence instead of removing the person from it. A paused person looks worked in every report and sits there untouched. The same goes for a "left company" call disposition. Both should remove the person and create a task for a named human.
How do you keep a ZoomInfo list build from burning credits?
Search before you spend. Under ZoomInfo's current API rules searching is free and a credit is charged only when a record is enriched, so build and review the company list on the free record, have the rep approve it, pick one person per company, filter on whether an email or phone exists and on accuracy score, and enrich the final picks only. Credits spent should roughly equal contacts delivered to the rep.
Why are the reps not using ZoomInfo after we bought it?
Usually because the enrichment is owned by RevOps or marketing and never reaches the rep's screen. The data lands on the account or in a field the rep does not see, the list they get has no phone number or job function on it, so they search by hand. Fix where the data lands before you address adoption.
Installed is not set up. Set up is when the rep's screen, the CRM and the cadence agree, and nobody is measured on a number the pipe cannot support yet.