# Setting Up ZoomInfo and Salesloft So the Reps Actually Use Them

- **Source:** https://www.santixs.com/post/setting-up-zoominfo-and-salesloft-so-reps-actually-use-them
- **Site:** SantiXS, Go-to-Market (GTM) Execution Agency, founded 2024 by Patrick Santiago
- **Summary:** A ZoomInfo and Salesloft rollout is decided by the implementation, not the software. Vendor onboarding assumes you arrive prepared, and the white-glove tier still needs someone on your side who has done this before. The setup order I use, the breakages to check for in week one, and what has to be true before a rep is measured on any of it.


---

**Outbound Systems · SDR Teams**

## Setting Up ZoomInfo and Salesloft So the Reps Actually Use Them

October 4, 2026 · 10 MIN READ · Patrick Santiago

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.

*The first decision on any rollout, and the shortcut that quietly undoes 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:

1. **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.
2. **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.
3. **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.
4. **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.
5. **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:

1. **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.
2. **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.
3. **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.
4. **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.
5. **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.
6. **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:

1. **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.
2. **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.
3. **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.
4. **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.
5. **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](https://www.santixs.com/outbound), 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.

## more on outbound systems

- [Best Practices for Cold Calling That Create Pipeline](https://www.santixs.com/post/best-practices-for-cold-calling-that-create-pipeline)
- [How to Diagnose Weak Qualification in SaaS](https://www.santixs.com/post/how-to-diagnose-weak-qualification-in-saas)
- [Sales Handoff Breakdown Causes and Fixes](https://www.santixs.com/post/sales-handoff-breakdown-causes-and-fixes)
- [How Do I Know If My Outbound Problem Is the List or Copy?](https://www.santixs.com/post/how-do-i-know-if-my-outbound-problem-is-the-list-or-copy)

[how we build and run outbound→](https://www.santixs.com/outbound)

A WORKING CONVERSATION

## *think we should talk?*

[30 minutes. no slides. no pitch.↗](https://www.santixs.com/contact)