Last updated: August 31, 2026
By Ben Argeband, Founder & CEO of Heartbeat.ai
What’s on this page:
Who this is for
This page is for recruiting ops and leaders who need one consistent way to measure phone and email outreach across teams, tools, and time. If a weekly meeting has ever stalled on “what counts as a connect?” or “are we measuring replies on sent or delivered?”, that’s the gap this page closes.
Use it as the reference link for dashboards, SOPs, and stakeholder updates — one place that defines the numbers everyone reports on.
Quick answer
- Core answer
- Connect Rate = connected calls / total dials. Report it per 100 dials so phone reachability stays separate from messaging performance and weekly reports stay comparable.
- Key insight
- Most reporting drift traces back to a changed denominator, not a changed result. Lock the definitions, log the raw events, and publish per-100 rates alongside raw counts.
- Best for
- Recruiting ops teams and leaders who need consistent measurement across dialers, ESPs, and ATS/CRM systems.
Compliance & safety
This method is for legitimate recruiting outreach only. Respect candidate privacy, opt-out requests, and local data laws. Heartbeat does not provide medical advice or legal counsel.
Framework: denominator discipline
Outreach metrics fall apart when teams mix denominators. One report uses dials, another uses connected calls, a third uses “attempts” that quietly exclude voicemails. None of these numbers are comparable across weeks, teams, or vendors once the denominator moves underneath them.
- Define each metric with a fixed numerator and denominator and write it down somewhere everyone can see it.
- Report in a consistent unit per channel — per 100 dials for phone; per 100 sent emails for deliverability and bounce; per 100 delivered emails for reply metrics. Don’t blend channels into one number.
- Log the event that creates the numerator so the metric can be reproduced from raw data, not just trusted on faith.
- Separate data quality from execution — reachability, timing, targeting, and message fit are different problems with different fixes.
Worked example: if you place D dials and get C connected calls, Connect Rate = C/D. Report it as (C/D) × 100 connected calls per 100 dials, alongside the raw counts.
Step-by-step method
Step 1: Standardize your event vocabulary first
Your dialer, email provider, and ATS/CRM won’t use the same names for the same events. Start by listing what you can actually capture, then map each one to a stable definition.
- Phone events: dial placed, connected call, human answer, voicemail, busy, no answer, failed, wrong person confirmed, do-not-contact/opt-out.
- Email events: sent, delivered, bounced (hard/soft), replied, unsubscribed/opt-out, complaint.
- Identity events: person match confidence, wrong-person confirmed, duplicate merged, suppressed.
Decide what an “attempt” means per channel — a dial for phone, a sent email for email — and keep channels separate unless you’re deliberately building a blended model.
Step 2: Use canonical metric definitions
These formulas and denominators are meant to be implementable in any reporting stack, regardless of which dialer or ESP you run.
| Metric | Canonical definition | Formula | Report as | Primary diagnostic use |
|---|---|---|---|---|
| Connect Rate | Share of dials that result in a connected call (not necessarily a human answer). | connected calls / total dials | Connected calls per 100 dials | Phone reachability + dialer execution |
| Answer Rate | Share of connected calls that are answered by a human. | human answers / connected calls | Human answers per 100 connected calls | Call timing + caller ID trust + targeting |
| Deliverability Rate | Share of sent emails that are delivered (not bounced). | delivered emails / sent emails | Delivered emails per 100 sent emails | List hygiene + domain reputation |
| Bounce Rate | Share of sent emails that bounce (hard + soft). | bounced emails / sent emails | Bounced emails per 100 sent emails | Bad addresses + sending practices |
| Reply Rate | Share of delivered emails that receive a reply. | replies / delivered emails | Replies per 100 delivered emails | Message-market fit + targeting |
| Positive Reply Rate | Share of delivered emails that receive a positive reply (interested, send details, open to talk). | positive replies / delivered emails | Positive replies per 100 delivered emails | Offer fit + targeting precision |
| Hard Bounce Rate | Share of sent emails that permanently fail (invalid address, non-existent domain). | hard bounces / sent emails | Hard bounces per 100 sent emails | Address validity |
| Soft Bounce Rate | Share of sent emails that temporarily fail (mailbox full, transient server issue, rate limiting). | soft bounces / sent emails | Soft bounces per 100 sent emails | Temporary deliverability issues |
| Recency | How recently a contact point (email/phone) was verified or observed as valid. | Now − last verified/observed date | Days since last verification | Decay risk |
| Refresh cadence | How often you re-verify and update contact points for active segments. | Scheduled interval | Days between refresh runs | Freshness operations |
| Wrong-person rate | Share of outreach attempts that reach someone other than the intended candidate. | wrong-person confirmations / total attempts (phone: dials; email: delivered emails) | Wrong-person outcomes per 100 attempts | Identity resolution quality |
| Suppression | Operational rule that prevents outreach due to opt-out, complaint, wrong-person, or risk flags. | suppressed records / total records evaluated | Suppressed per 100 evaluated | Compliance + reputation protection |
Variable-only examples for clean reporting:
- Answer Rate: H connected calls, A human answers → Answer Rate = A/H (human answers per 100 connected calls = (A/H) × 100).
- Deliverability Rate: S sent, L delivered → Deliverability Rate = L/S (delivered per 100 sent = (L/S) × 100).
- Bounce Rate: S sent, B bounced → Bounce Rate = B/S (bounces per 100 sent = (B/S) × 100).
- Reply Rate: L delivered, R replies → Reply Rate = R/L (replies per 100 delivered = (R/L) × 100).
Step 3: Map tool outcomes to the definitions
Two terms need to be locked down in your ops doc and kept stable:
- Connected call: the carrier connects the call, regardless of whether a person answers.
- Human answer: a person answers, not voicemail or an automated message.
Build a mapping table that says which raw outcomes count toward each numerator and denominator. If you switch dialers, update this table the same day — not at the end of the quarter when someone notices the numbers look strange.
| Raw outcome (example) | Counts toward total dials? | Counts toward connected calls? | Counts toward human answers? | Notes |
|---|---|---|---|---|
| Connected (carrier connected) | Yes | Yes | No | Connected does not imply a human answered. |
| Human answered | Yes | Yes | Yes | Use a consistent rule for what qualifies as “human.” |
| Voicemail reached | Yes | Depends on dialer | No | If your dialer marks voicemail as connected, document it and keep it consistent. |
| Busy / no answer / failed | Yes | No | No | Still counts as a dial attempt. |
Do the same for email: sent is the denominator for deliverability and bounce; delivered is the denominator for reply and positive reply; bounced is the numerator for bounce rate, split into hard and soft.
Step 4: Build a weekly scorecard that can’t drift
Publish per-100 rates with raw counts next to them. If someone challenges a number, you should be able to trace it straight back to logged events, not a spreadsheet formula nobody remembers writing.
- Phone: total dials, connected calls, human answers, wrong-person confirmations, opt-outs/suppressions.
- Email: sent, delivered, hard bounces, soft bounces, replies, positive replies, unsubscribes/complaints, suppressions.
Per-100 reporting is easy to read but it can hide volume changes. Always show raw counts next to rates so leaders can tell whether performance changed or volume changed — those require different fixes.
Diagnostic table
Use this to triage performance without guessing. It’s written for recruiting ops: what broke, where to look, what to change.
| Symptom | Most likely cause | Where to check | What to do next |
|---|---|---|---|
| Connect Rate drops | Number decay, carrier filtering, or dialer config change | Dialer outcome codes; recency distribution; time-zone call blocks | Increase refresh cadence for active segments; adjust call windows; review caller ID strategy |
| Connect Rate stable, Answer Rate drops | Timing mismatch or caller ID trust issue | Answer Rate by hour/day; spam labeling reports; caller ID settings | Shift call blocks; rotate caller IDs; tighten targeting to reduce low-intent connects |
| Deliverability Rate drops | Domain reputation or list hygiene issue | Google Postmaster Tools reputation signals; bounce breakdown (hard vs soft) | Pause risky segments; remove hard bounces; slow sending; improve authentication and warm-up practices |
| Hard Bounce Rate rises | Invalid or stale addresses | Hard bounce logs; email recency | Refresh active segments; suppress known-invalid; verify before sending |
| Reply Rate flat, Positive Reply Rate falls | Offer mismatch or role confusion | Reply sentiment tagging; wrong-person confirmations | Fix role/facility context; tighten filters; include concrete schedule/call details earlier |
| Wrong-person rate increases | Identity resolution drift (shared lines, similar names, recycled numbers) | Wrong-person flags by source; match confidence | Feed wrong-person outcomes into suppression and matching rules; require identity confirmation in first touch |
One caveat worth flagging: Google has been changing how domain reputation surfaces inside Postmaster Tools, moving away from a single simple grade toward a broader mix of signals such as spam rate, authentication pass rates, and compliance status. If your deliverability troubleshooting process still assumes one clean High/Medium/Low/Bad tier, check that it still matches what the tool currently shows before you act on it.
Weighted checklist
Score each item 0–2 (0 = not in place, 1 = partial, 2 = solid) and multiply by weight. This prioritizes the changes that reduce wasted attempts and protect deliverability first.
| Area | Check | Weight | Why it matters |
|---|---|---|---|
| Definitions | All teams use the same formulas and denominators (per 100 dials; per 100 sent; per 100 delivered) | 5 | Stops reporting drift and makes tests comparable |
| Instrumentation | ATS/CRM captures dial outcomes, delivery/bounce type, replies, positive replies, and suppression reasons | 5 | Without fields, you can’t audit or improve |
| Phone reachability | Phone records include recency metadata and a refresh cadence for active segments | 4 | Prevents wasted dials and repeated carrier failures |
| Email reputation | Deliverability monitored with Google Postmaster Tools; hard/soft bounces tracked separately | 4 | Protects domain and keeps the delivered denominator real |
| Suppression | Central suppression list enforced across tools (opt-outs, complaints, wrong-person) | 4 | Reduces risk and prevents repeat mistakes |
| Identity quality | Wrong-person outcomes are logged and fed back into matching rules | 3 | Improves candidate experience and recruiter efficiency |
| Execution | Call blocks and email sends are scheduled by time zone and role patterns | 3 | Improves Answer Rate and reply likelihood without more volume |
Outreach templates
These templates are built to reduce wrong-person outcomes and keep measurement clean. Keep the structure stable while you test one variable at a time — changing the opener, the subject line, and the CTA in the same week makes results impossible to attribute.
Phone opener (30 seconds)
- Confirm identity: “Hi Dr. [Last Name]—this is [Name]. Quick check: is this still the best number for you?”
- If yes: “Thanks. I’m recruiting for a [Role] at [Facility/Group] in [Location]. Do you have 60 seconds now, or should I call back at [two specific windows]?”
- If wrong person: “Appreciate it—sorry about that. I’ll remove this number.” (Log wrong-person + suppress.)
- What to log: dial outcome, connected flag, human answer flag, wrong-person flag, suppression reason if applicable.
Email 1 (identity-first)
Subject: Quick confirm — [Role] at [Facility/Group]?
Hi [First Name] — I’m recruiting for [Role] at [Facility/Group] in [Location]. Before I send details, can you confirm this is the right email for you?
If not, reply “no” and I’ll suppress you.
— [Name], [Title] at Heartbeat.ai
What to log: sent, delivered, bounce type (if any), reply, positive reply, suppression reason.
Email 2 (details + next step)
Subject: Details + call window?
Thanks, [First Name]. The role is [2–3 specifics: schedule/call/setting]. If you’re open to a quick call, what’s a good window this week?
If you’d rather not get outreach from me, reply “opt out” and I’ll suppress you.
Common pitfalls
1) Counting “connected” differently across dialers
Some dialers treat voicemail as connected; others don’t. Switch dialers without updating your mapping table and your Connect Rate will jump or drop with no real change in reachability behind it.
2) Measuring replies on sent instead of delivered
Reply Rate is replies divided by delivered emails. Use sent as the denominator and you’ll mask list hygiene problems while misreading how well the message itself is performing.
3) Blending wrong-person outcomes into “not interested”
Wrong-person is an identity/data failure. “Not interested” is a targeting or offer failure. Keep them separate so the fix goes to the right team.
4) Treating suppression as a manual side task
Suppression has to be enforced across tools. If opt-outs only live in an inbox label, you will re-contact people and generate complaints that were entirely avoidable.
5) Letting definitions live in more than one place
If metric definitions are scattered across docs, they drift. Run this page like a product: one stable, linkable definitions source that every metric and claims page points back to, with a visible last-reviewed date and a lightweight change log recording what changed and why.
- Owner: recruiting ops (or RevOps) owns the definitions; marketing can format the page, but ops owns the meaning.
- Cadence: review whenever the dialer, ESP, or ATS changes, and quarterly otherwise.
How to improve results
Improvement starts with measurement hygiene. If you can’t trust the denominator, you can’t trust whatever change you think you’re seeing.
Measurement instructions
Build a weekly scorecard that reports each metric with its canonical denominator plus raw counts next to the rate.
- Connect Rate = connected calls / total dials. Report: connected calls per 100 dials + raw counts.
- Answer Rate = human answers / connected calls. Report: human answers per 100 connected calls + raw counts.
- Deliverability Rate = delivered emails / sent emails. Report: delivered per 100 sent + raw counts.
- Bounce Rate = bounced emails / sent emails. Report: bounces per 100 sent, split hard/soft + raw counts.
- Reply Rate = replies / delivered emails. Report: replies per 100 delivered + raw counts.
Track wrong-person rate per channel too — phone: per 100 dials; email: per 100 delivered — along with suppression volume by reason.
Operational levers that usually move the numbers
- Connect Rate: refresh active segments; call in role-appropriate windows; stop repeating attempts to stale numbers; keep caller ID strategy consistent. Heartbeat.ai supports workflows built around ranked mobile numbers by answer probability, so recruiters spend dials where an answer is more likely.
- Answer Rate: adjust call blocks; tighten targeting; confirm identity in the opener to reduce defensive screening.
- Deliverability Rate: monitor domain reputation signals through Google Postmaster Tools, suppress risky segments quickly, and keep bounce handling strict.
- Reply Rate: shorten the first email, confirm identity, and ask for one specific next step — a call window works better than an open-ended question. Keep the template stable while testing a single variable.
ATS/CRM field map
A minimal field map that supports the definitions above and keeps reporting auditable across tools.
| Metric | Minimum fields/events to log | System of record |
|---|---|---|
| Connect Rate | dial_timestamp, dial_outcome, connected_flag | Dialer (synced to ATS/CRM) |
| Answer Rate | human_answer_flag, call_duration_seconds (optional), answer_timestamp | Dialer |
| Deliverability Rate | email_sent_timestamp, delivered_flag, bounce_flag, bounce_type | Email provider / outreach tool |
| Bounce Rate | bounce_flag, bounce_type (hard/soft) | Email provider / outreach tool |
| Reply Rate | reply_flag, reply_timestamp, reply_thread_id | Email provider / outreach tool |
| Positive Reply Rate | positive_reply_flag (manual tag or classifier), tag_timestamp | ATS/CRM (review workflow) |
| Wrong-person rate | wrong_person_flag, wrong_person_channel, confirmation_timestamp | ATS/CRM |
| Suppression | suppression_flag, suppression_reason, suppression_timestamp | ATS/CRM (enforced across tools) |
Legal and ethical use
This page defines measurement terms and operational logging. It is not legal advice. Use these metrics to run legitimate recruiting outreach with clear opt-out handling and respectful contact frequency.
- Honor opt-outs and suppress across all tools.
- Minimize data: store what you need to recruit and measure; avoid collecting sensitive information you don’t need.
- Be transparent: identify yourself, your purpose, and provide a simple opt-out path.
Do not represent any dataset as “HIPAA compliant,” “safe harbor,” or “guaranteed accurate.” Heartbeat does not provide legal counsel.
Evidence and trust notes
This page is part of the Heartbeat trust methodology hub. For broader context on how we define and test quality, start here: Heartbeat trust methodology.
Related trust detail: How we test contact data quality.
Implementation notes and editorial stability should follow user-first documentation principles. References:
FAQs
What is the connect rate definition for recruiters?
Connect Rate = connected calls / total dials. Report it as connected calls per 100 dials, and keep the definition stable across teams and tools.
What’s the difference between connect rate and answer rate?
Connect Rate is connected calls per 100 dials. Answer Rate is human answers per 100 connected calls. Use both so you can separate reachability from call timing and trust.
How do you define deliverability rate and bounce rate for recruiting email?
Deliverability Rate = delivered emails / sent emails (delivered per 100 sent). Bounce Rate = bounced emails / sent emails (bounces per 100 sent), split into hard and soft bounces.
How do you calculate reply rate?
Reply Rate = replies / delivered emails. Use delivered as the denominator so bounces don’t distort the result.
What should we log to make these metrics auditable?
Log the raw events that create the numerators and denominators: dials, connected calls, human answers, sent, delivered, bounce type, replies, positive replies, wrong-person confirmations, and suppression reasons.
Next steps
- Interpretation deep-dive: Connect rate vs answer rate.
- Operational tracking: ATS/CRM field schema for outreach metrics.
- Email measurement workflow: Reply rate tracking for physician outreach.
- Data freshness ops: Provider data refresh cadence.
- Instrument this in your workflow: Create a Heartbeat.ai account.
About the Author
Ben Argeband is the Founder and CEO of Swordfish.ai and Heartbeat.ai. With deep expertise in data and SaaS, he has built two successful platforms trusted by over 50,000 sales and recruitment professionals. Ben’s mission is to help teams find direct contact information for hard-to-reach professionals and decision-makers, providing the shortest route to their next win. Connect with Ben on LinkedIn.
