HubSpot Calling Quality Comparison Before You Switch Dialers

TL;DR: HubSpot does not carry your calls itself. HubSpot’s own technical requirements page names Twilio as the third-party service handling them, which means the audio thresholds you should be testing against are Twilio’s published numbers, not a vague sense that the CRM sounds worse than a cell phone. Twilio asks for round-trip latency under 200 ms, jitter under 30 ms, and packet loss under 3 percent, and it needs only 40 kbps up and 40 kbps down for an Opus call, or 100 kbps each way on PCMU. HubSpot separately asks for consistent download and upload speeds of 10 Mbps, roughly 250 times the bitrate of a single Opus call, so one call is not what saturates a line. The numbers that decide the audio are the latency, jitter and packet loss thresholds, plus whether your firewall passes Twilio’s traffic. Twilio’s media traffic runs over UDP ports 10,000 to 60,000 and its signaling runs over TCP port 443 to hosts including chunderw-gll.twilio.com and eventgw.twilio.com, and if your network blocks those, calls fail in ways no headset swap will fix. Then there are the operational traps that have nothing to do with audio: calling minutes are aggregated and shared across every user in the account, they reset on the first day of the next month rather than your contract renewal date, and the Call button goes dark when the pool runs out. Choosing “call from phone” burns twice as many minutes because HubSpot places two separate calls. Safari is not supported for inbound browser calling, mobile and tablet browsers are not supported, and inbound calls only ring in the browser when an assigned user is logged in, marked available, and has the calling window open. Otherwise they go to voicemail or log as missed. Test with the call index, which records call status as Missed, Canceled, Completed, Busy, Failed, or No answer and tags call source as VoIP, Zoom, or Integrations platform, and compare native calling against any third-party dialer on the same numbers, the same network, and the same week.

A rep says HubSpot calls sound bad. Somebody suggests the dialer. Two weeks later the team is in a vendor demo.

That sequence happens constantly, and it skips the only step that would tell you whether the dialer was ever the problem. Call quality on a browser-based phone is a chain: the rep’s microphone, the browser, the local network, the firewall, the carrier route, the recipient’s carrier, and the recipient’s own handset. Swapping the software at one end of that chain is a strange first move. Which link actually failed? Usually nobody checked.

So here is a HubSpot calling quality comparison built the other way around. Start with what HubSpot documents about its own calling stack, get the numbers you are allowed to test against, find out which of your problems are configuration rather than audio, and only then put native calling next to a third-party dialer. By the end you should be able to say which link in the chain is failing, with evidence, before anyone signs anything.

What HubSpot calling quality actually depends on

Start with the single most useful fact about HubSpot calling, and it is one most buyers never learn: HubSpot is not the carrier. Its technical requirements documentation states plainly that calls are handled by Twilio, a third-party service. HubSpot builds the interface, the logging, the routing rules, and the reporting. The audio itself rides on Twilio’s network.

That changes the question. “Is HubSpot calling quality good” is unanswerable. “Does my network meet the requirements Twilio publishes for the browser calling it provides” is a test you can run this afternoon.

So what should you be measuring against? Twilio publishes real thresholds for its Voice SDKs, and they are tighter than most sales teams expect:

• Round-trip latency under 200 ms. Past that, the conversation starts stepping on itself. Reps interrupt, buyers repeat themselves, and both sides read it as rudeness rather than lag.
• Jitter under 30 ms. Jitter is the variation in packet arrival time. It is the number behind the complaint reps actually voice, which is that words go missing or speech sounds robotic.
• Packet loss under 3 percent. Small enough that a speed test will never surface it.
• 40 kbps up and 40 kbps down per call on the Opus codec, or 100 kbps each way on PCMU. Twilio documents that Opus can be configured down to 16 kbps.

Now put that next to HubSpot’s own guidance, which asks for consistent download and upload speeds of 10 Mbps. Ten thousand kilobits against forty. That is roughly 250 times the audio bitrate of one Opus call.

So why ask for 10 Mbps at all? Read the gap carefully, because it is the whole point. HubSpot is not telling you a call needs 10 Mbps. It is telling you it wants that speed to be consistent, because a browser session doing signaling, CRM updates, and audio at once is fragile in a way a raw throughput number does not capture. The word doing the work in that sentence is “consistent,” not “10.”

Which is why “we have gigabit fiber” is not a defense. A gigabit line with a saturated uplink at 4pm, a mesh access point three rooms away, or a VPN concentrator adding 80 ms of round trip will fail every threshold above while passing every speed test. Bandwidth is the number people check because it is the number that appears on a speed test, and consistency is the number that decides the call, even though it is not what a speed test measures. Check the one nobody checks.

The HubSpot call quality problems that are really configuration

Before you compare anything, clear the faults that are not about sound at all. These are documented, they are binary, and each one produces a symptom a rep will describe as bad call quality.

The firewall. Twilio’s media traffic needs UDP on ports 10,000 through 60,000, and its signaling needs TCP port 443 to a specific set of hosts, among them chunderw-gll.twilio.com, chunderw-vpc-gll.twilio.com, voice-js.roaming.twilio.com, eventgw.twilio.com, and sdk.twilio.com. There is also a published media IP block, which you should take from Twilio’s current requirements page rather than from any article, because those blocks get revised. HubSpot’s own documentation dates the range it cites to a specific day in 2023 for exactly that reason.

What does that look like to the rep? Not like a firewall problem. A firewall that permits signaling on 443 but drops the UDP media range gives you a call that connects, rings, and answers with silence. One-way audio and dead air are the classic signature. The rep sees a connected call and concludes the dialer is broken. Nobody thinks to ask the network team, because from the CRM’s point of view nothing failed.

The browser. HubSpot does not support Internet Explorer, and it does not support a browser on a mobile device or tablet. For those, the documentation points you to the HubSpot app instead. More surprising, and worth checking before you blame anything else: Safari is not supported with inbound browser calling. So where does that leave a Mac-heavy team whose reps live in Safari? Watching inbound calls quietly not arrive. That is not a quality issue. That is an unsupported configuration.

The call window. HubSpot’s documentation is explicit that the call window has to stay open to make calls. Why would a rep close it? Because reps close tabs, and because every other app on the machine keeps working in the background.

The microphone. HubSpot requires access to the microphone, and the user has to confirm which audio device the browser is using. A rep who granted permission once, then plugged in a new headset, can end up broadcasting the laptop’s built-in microphone with the headset on their head. Who notices? Not the rep. They hear the buyer perfectly. The buyer hears the room.

The connection type. HubSpot recommends wired ethernet as the alternative to wireless, and it points to Twilio’s network test tool at networktest.twilio.com. Run that from a rep’s actual machine on the actual office network, not from IT’s wired desk.

Work that list first, because every item on it is free, takes an afternoon, and removes a variable that would otherwise contaminate every measurement you are about to take. Skip it and you will run a careful comparison of your own misconfiguration.

Why inbound HubSpot calls go to voicemail instead of ringing

This one deserves its own section because it looks like a quality failure and it is actually a coverage failure.

HubSpot documents that for an inbound call to ring in the browser, at least one assigned user has to be logged in, marked available, and have the calling window open. If no eligible user is detected, the call goes to voicemail or logs as missed.

Sit with that for a second. Three conditions, every one of them a thing a rep either does or forgets to do, and all three have to be true at the same moment the buyer dials. Logged in is easy. Calling window open is a habit nobody trained, and marked available is a status field reps set once on Monday and never touch again, which means your inbound coverage quietly depends on the least memorable step in the workflow.

So what does the failure look like from the outside? A prospect who submitted a form ten minutes ago calls back, gets voicemail during business hours, and forms an opinion about your company. Internally, the record shows a missed call. Nobody logged a complaint about audio, because there was no audio.

So what fixes it? Not a better dialer. What fixes it is a written rule about who is marked available during which calling block, plus an inspection somebody actually runs on a schedule instead of assuming the setting stayed where it was left. If you are already tracking how fast your team gets back to inbound leads, this is the same problem wearing a different hat: the lead raised a hand, the system tried to connect, and the handoff dropped it.

Two more documented details worth knowing before you rely on voicemail as the safety net. Voicemails can be up to 3 minutes long and do not count toward your calling minutes, though transcribing them does consume transcription minutes. And voicemail is only available for inbound browser calls, not inbound forwarded calls, and it requires call recording to be enabled. If you forward inbound calls to a mobile, the safety net is not there.

HubSpot calling minutes are a shared pool, not a per-rep allowance

Now the part that decides whether native calling survives contact with a real outbound team, and it has nothing to do with how the audio sounds.

HubSpot documents that calling minutes are aggregated and shared across all users in a HubSpot account. One pool. Every rep drawing from it, with no documented per-rep cap standing between your heaviest dialer and everybody else’s remaining month. The number of minutes depends on your subscription, and HubSpot points to its own product and services catalog for the per-plan allocation rather than publishing a single figure, so confirm your specific number there rather than trusting anyone’s summary.

What happens when the pool empties? HubSpot documents that too. A call already in progress can usually finish, but new calls stop: the Call button in the CRM is disabled until the minutes reset. And the reset is calendar-based. HubSpot’s documentation is specific that calling minutes reset at the start of the next month and do not reset on your contract renewal date.

Model that as a queue and the risk becomes obvious. A shared pool with no per-rep cap means the heaviest dialer on the team spends everyone’s minutes. Nothing throttles that. So when does it break? The failure mode is not gradual degradation, it is a cliff, and the cliff arrives on the day of the month when your pipeline can least afford it. If the pool runs dry on the twenty-second, your whole team stops calling for nine days.

Then there is the detail that quietly doubles the burn rate. HubSpot documents that the “call from phone” device option uses twice as many calling minutes because it makes two separate calls. Think about who picks that option. It is the rep whose browser audio has been rough all week, which is exactly the rep already making the most calls, so the setting that doubles consumption gets chosen by the person consuming the most. A team that answers call quality complaints by telling reps to use their phones has halved its remaining runway without ever deciding to.

Two more constraints belong in the same budget conversation. Calling countries outside HubSpot’s supported list requires setting up Twilio Connect, and that route is documented as available to users with Sales Hub or Service Hub Professional or Enterprise seats. And HubSpot notes that contacts who have opted out of all communication require a one-time legal basis to communicate before you call them, which is a compliance gate rather than a technical one, but it lives in the same workflow.

None of this appears in an audio test. All of it decides whether native calling works at your call volume. If minutes and plan gating are shaping the decision, it is worth reading how the rest of HubSpot’s pricing tiers gate the features teams assume are included, because calling is not the only place this pattern shows up.

What the HubSpot call index will and will not tell you

You cannot compare call quality on vibes. You need an instrument, and HubSpot ships one.

So what can you actually measure? More than you would guess. The call index is available across all products and plans, and it aggregates more than native calls. HubSpot documents that it shows inbound forwarded calls, inbound in-app calls, inbound voicemails, outbound manually logged calls, outbound calls, and calls from third-party call integrators, naming Zoom and Aircall as examples. That last part is what makes a real comparison possible: native and third-party calls land in the same index, so you can measure them against each other in one place.

Two default properties do most of the diagnostic work. Call status carries the values Missed, Canceled, Completed, Busy, Failed, and No answer. Call source carries VoIP, Zoom, and Integrations platform. Between those two fields you can separate “the call never connected” from “the call connected and sounded bad,” and that is the single most important distinction in this whole exercise, because the two have completely different causes, completely different owners, and completely different fixes. Anecdotes blur them every time.

Now the limits. Call analytics and transcripts require Sales Hub or Service Hub Starter, Professional, or Enterprise. HubSpot documents nine reports there, including call totals by day, calls by rep, duration averages, outcomes, calls against goal, team activity, and historical calling minutes. That last report is how you watch the shared minute pool drain week by week instead of finding out it is empty on the morning a rep tells you the Call button stopped working.

And what does the index not give you? The technical layer. There is no mean opinion score, no jitter reading, no packet loss percentage. It tells you the call failed. It does not tell you why. That is the gap your test protocol has to fill, using Twilio’s network test alongside HubSpot’s own records.

One consent detail while you are in the recording settings. Recording is an account-wide setting, enabled by default, and HubSpot’s documentation describes the notice callers receive, which states that the call is being recorded and that they consent by staying on the line. That is HubSpot describing its own product behavior, not a ruling on your obligations, which depend on your markets. If you plan to review recordings as part of the comparison, and you should, that is also the foundation for coaching reps from real recorded calls rather than from memory.

Run a HubSpot calling quality comparison in one week

Here is the protocol. It is deliberately boring, because a comparison that changes five variables at once produces a story instead of a result.

1. Clear the configuration faults first. Firewall ports and hosts allowed, a supported browser, no Safari for inbound, microphone device confirmed, call window open, wired ethernet on at least one test machine. Do not start measuring until this list is clean, or you will measure your firewall and call it audio.
2. Run the network test from the rep’s seat. Twilio’s network test tool, on the rep’s own machine, on the office network, at a busy hour. Record latency, jitter, and packet loss against the published thresholds of 200 ms, 30 ms, and 3 percent. Now you have a pass or fail, not an opinion.
3. Fix the number of destinations at five. Why five and not fifty? Because you are going to call all of them again on every leg of the test. One local landline, one local mobile, one long distance, one in a region your team actually sells into, and one internal phone you control so you always have a listener who will pick up. Same five numbers for every leg of the test.
4. Test one variable per leg. Native calling on ethernet. Native calling on Wi-Fi. Native calling with a wired headset versus the laptop microphone. Then the third-party dialer, same machine, same network, same headset, same five numbers. One change at a time.
5. Test both directions. Inbound and outbound take different paths and fail differently. Inbound is where the available-user rule bites, so confirm a call rings in the browser rather than rolling to voicemail.
6. Repeat at three times of day. Morning, mid-afternoon, and end of day. Network congestion is a schedule, not a constant, and a single clean test at 8am proves nothing about a 3pm call block.
7. Score both ends of every call. The rep rates clarity, delay, and volume consistency. The person on the other end does the same. A rep-only score misses one-way audio entirely, which is the exact failure a blocked UDP range produces.
8. Reconcile against the call index. Pull call status and call source for every test call. Count Failed, Busy, and No answer separately from Completed. If your subjective scores and the index disagree, trust the index and find out why.

A fair comparison changes one variable at a time. That is the entire discipline, and it is the step teams skip because it feels slow. Switch the provider, the headset, the network, the browser, and the destination all in the same week and you will finish with a strong feeling, a vendor preference, and no finding you could defend to anyone who asks.

Write the results down in a table with a row per leg. When someone asks in three months why you chose what you chose, that table is the answer.

HubSpot calling quality compared with mobile and desk phones

Reps compare browser calling to their cell phone constantly, and the comparison is not unfair. It is just imprecise.

A mobile call depends on coverage, network load, device condition, carrier routing, and the recipient’s network. A desk phone may be traditional telephony, VoIP, or a hybrid. Neither is a fixed benchmark, which is why “my cell sounds better” is a data point about one rep, one location, and one route, not a verdict about a platform.

So which one is better? Wrong question. What is true is that the failure modes differ, and that difference is worth naming:

• A mobile call degrades gradually. Coverage weakens, quality drops, both parties adapt. Everyone has a script for it.
• A browser call fails discretely. It connects with no audio, or drops cleanly, or never rings. There is no gradual warning, so it reads as a broken product rather than a bad connection.
• A mobile call leaves no CRM record by default. Someone logs it later, or nobody does. The deal history has a hole in it.
• A browser call is logged whether the rep cooperates or not. Direction, status, outcome, recording, and association all land on the record.

That last pair is the trade most teams are actually making, and it almost always goes undiscussed. Which side of it matters more? Depends on the horizon. The cell phone wins the audio argument in the moment, and the CRM wins the argument about what happened on the deal three weeks later, when the rep has left the company and somebody else has to pick up a record with a hole in it.

Remember the minute math here too. Routing browser calls through “call from phone” to get the mobile audio path costs two calls’ worth of minutes from the shared pool. You can make that trade deliberately. Just do not make it by accident, one rep at a time.

When to compare HubSpot calling against third-party dialers

Native calling is the right answer more often than vendors admit. If reps already work inside HubSpot, calling volume is moderate, your destinations sit inside the supported country list, and your pilot clears Twilio’s thresholds, adding another system buys you complexity and a second bill.

So when is it not the right answer? Grant the premise, then mark the boundary. Evaluate an integration when the constraint is structural rather than acoustic:

• Minute economics. A shared account-wide pool with a hard monthly cliff is a poor fit for a team whose plan is to dial more next quarter than this one.
• List-based outbound. If the workflow is a rep working a list of several hundred records in a block, the question is what advances the list and what happens after no answer, not what the audio sounds like.
• Coverage rules. The available-user requirement for inbound browser calls is a real operational constraint if inbound coverage has to hold across time zones.
• Geography. Destinations outside the supported list mean Twilio Connect, which means Professional or Enterprise seats.
• Device support. Reps who need to work from a tablet or a mobile browser are outside the supported configuration.

Notice what is not on that list: an assumption that a third-party provider sounds better. Different providers do use different infrastructure and routing, so results genuinely can differ, but that is a reason to test rather than a reason to believe. Assume nothing. Run your own five numbers.

Kixie publishes this article and sells sales engagement software for business calling and texting, with PowerDialer as the list-based outbound calling product. Hold it to the same standard as anything else. Run it through the same protocol, on the same numbers, on the same network, in the same week as native calling, and check whether the activity lands on the HubSpot record the way you need it to. If you are shortlisting, the wider field is covered in our comparison of the best HubSpot dialers and in a closer look at HubSpot calling alternatives for teams that have outgrown native calling.

A vendor demo teaches you the workflow. It tells you nothing about your firewall.

HubSpot calling quality comparison questions

Is HubSpot calling quality worse than a regular phone call

No published benchmark settles that, and HubSpot does not claim one. What HubSpot does document is that Twilio handles the calls, which means the fair test is whether your network meets Twilio’s published requirements of under 200 ms round-trip latency, under 30 ms jitter, and under 3 percent packet loss. Meet those and your network is not the explanation. Miss them and fixing the network comes before changing providers.

Why do HubSpot calls sound choppy

Choppy speech and missing words point at jitter and packet loss rather than bandwidth. Check those against the 30 ms and 3 percent thresholds using Twilio’s network test, then check whether the UDP media range of 10,000 to 60,000 is open through your firewall. Wi-Fi interference, a saturated uplink, a VPN hop and a Bluetooth headset are all common contributors, so test them one at a time.

Why do inbound HubSpot calls go straight to voicemail

Because the three conditions for an inbound browser call are not all met. HubSpot requires at least one assigned user logged in, marked available, and with the calling window open. If no eligible user is detected, the call goes to voicemail or logs as missed. Check the availability status and the open call window before you look at anything technical.

How do HubSpot calling minutes work

They are aggregated and shared across all users in the account, and the allocation depends on your subscription, which HubSpot lists in its product and services catalog. They reset at the start of the next month rather than on your contract renewal date. When they run out, a call in progress can usually finish but the Call button is disabled. Choosing “call from phone” uses twice as many minutes because it places two separate calls.

Does Safari work for HubSpot calling

Not for inbound browser calling. HubSpot’s documentation states Safari is not supported there. Internet Explorer is unsupported outright, and a browser on a mobile device or tablet is not supported either, with the HubSpot app being the documented route for those devices.

Will a third-party dialer improve HubSpot call quality

It might, because providers use different infrastructure and routing, but do not assume it. Split the causes first. A blocked UDP range or a saturated uplink sits on your network, and a new dialer runs across that same network, so it arrives with the problem intact. A HubSpot-specific rule, such as its unsupported-browser list or a rep who is not marked available, does not carry over; a different provider will have its own rules to check instead. Clear the configuration faults, then test.

How often should we retest call quality

Retest after anything that changes the chain: a new office or access point, a VPN or firewall change, a browser policy update, a headset rollout, a new calling region, or a plan change that moves your minute pool. A quarterly spot check on the same five numbers catches drift a one-time pilot cannot.

What to inspect first on HubSpot calling quality

A HubSpot calling quality comparison is not a popularity contest between vendors. It is a fault-finding exercise with a decision at the end.

So where do you start? At the cheap end. Confirm the UDP media range and the signaling hosts are open. Confirm every rep is on a supported browser, with no Safari on inbound. Confirm the microphone device and keep the call window open. Run Twilio’s network test from a rep’s seat at a busy hour and write down latency, jitter, and packet loss against 200 ms, 30 ms, and 3 percent. Check who is marked available during each inbound block. Pull the historical calling minutes report and find out which day of the month your shared pool runs out.

Only then compare providers, one variable at a time, on five fixed numbers, across three times of day, scored at both ends and reconciled against the call index.

Do that and the answer stops being a matter of opinion. You will know which link in the chain is failing, whether a different provider actually fixes that specific link, and what leaving it broken costs you in connected calls per rep per week. That is a decision you can defend in a room.

Sources

How this article was built: every statement about what HubSpot natively supports, requires, or restricts comes from the current HubSpot Knowledge Base documentation linked below and is reported with HubSpot’s own scope and wording intact. Every audio threshold and network value comes from Twilio’s current published requirements for its Voice SDKs, cited because HubSpot’s own technical requirements documentation names Twilio as the third-party service handling its calls. The comparison of 10 Mbps against 40 kbps is arithmetic on those two published figures and is presented to explain why consistency rather than raw bandwidth governs call quality; it is not a capacity guarantee for any specific network. The test protocol, the queue and coverage failure modes, and the mobile-versus-browser trade-offs are reasoned from those documented constraints and are written so you can substitute your own destinations, regions, plans, and volumes. Plan names, minute allocations, supported countries, IP and port ranges, and supported browsers change without notice, so confirm each against the linked documentation for your own account before acting. Third-party dialer behavior varies by product, so confirm any vendor capability against that vendor’s current documentation and a live test on your own network. Nothing here is legal advice; consent, recording, and retention obligations depend on your contact types, markets, and campaign design, and state law adds requirements federal rules do not. Kixie publishes this article and sells sales engagement software for business calling and texting.

• HubSpot Knowledge Base: Technical requirements to use the calling tool. Source for the statement that calls are handled by Twilio as a third-party service, the request for consistent download and upload speeds of 10 Mbps, the firewall guidance covering the Twilio media IP block 168.86.128.0/18 and the UDP port range 10,000 to 60,000, the lack of support for Internet Explorer and for a browser on a mobile device or tablet, the recommendation of wired ethernet over wireless, the microphone access and audio device confirmation requirement, the note that country-specific calling restrictions apply, and the reference to Twilio’s network test tool at networktest.twilio.com, accessed August 27, 2026.
• Twilio Docs: Voice SDK network connectivity requirements. Source for the round-trip latency requirement of under 200 ms, jitter under 30 ms, packet loss under 3 percent, the Opus bandwidth requirement of 40 kbps uplink and 40 kbps downlink with configuration possible down to 16 kbps, the PCMU requirement of 100 kbps each way, the media IP range and UDP port range 10,000 to 60,000, and the signaling requirement of TCP port 443 to hosts including chunderw-gll.twilio.com, chunderw-vpc-gll.twilio.com, voice-js.roaming.twilio.com, eventgw.twilio.com and sdk.twilio.com, accessed August 27, 2026.
• HubSpot Knowledge Base: Receive calls in the HubSpot browser. Source for the statement that Safari is not supported with inbound browser calling, the requirement that at least one assigned user be logged in, marked available, and have the calling window open for inbound calls to ring in the browser, the behavior that calls go to voicemail or log as missed when no eligible user is detected, the Sales Hub and Service Hub Starter, Professional and Enterprise plan requirement, and the call recording notice under which callers consent by staying on the line, accessed August 27, 2026.
• HubSpot Knowledge Base: Make calls in the HubSpot browser. Source for the statement that the “call from phone” device option uses twice as many calling minutes because it makes two separate calls, the requirement that the call window remain open to make calls, the note that calling minutes reset on the first day of the next month, the requirement of country codes for supported countries outside the United States, the Sales Hub and Service Hub plan and seat requirements, and the one-time legal basis required before calling contacts who have opted out of all communication, accessed August 27, 2026.
• HubSpot Knowledge Base: I have hit my HubSpot calling limit, what do I do now. Source for the statement that calling minutes are aggregated and shared across all users in a HubSpot account, the option to purchase additional minutes, and the Twilio Connect route for calling countries not included on the supported country list, documented as available to users with Sales Hub or Service Hub Professional or Enterprise seats, accessed August 27, 2026.
• HubSpot Knowledge Base: Calling frequently asked questions. Source for the behavior when the minute limit is reached, where a call already in progress can usually finish but the Call button in the CRM is disabled until minutes reset, the statement that calling minutes reset at the start of the next month and not on the contract renewal date, and the account-wide call recording setting that is enabled by default, accessed August 27, 2026.
• HubSpot Knowledge Base: Review calls in the call index. Source for call index availability across all products and plans, the call types it displays including inbound forwarded calls, inbound in-app calls, inbound voicemails, outbound manually logged calls, outbound calls and calls from third-party call integrators such as Zoom and Aircall, the call status values Missed, Canceled, Completed, Busy, Failed and No answer, the call source values VoIP, Zoom and Integrations platform, the requirement of Sales Hub or Service Hub Starter, Professional or Enterprise for call analytics and transcripts, the nine available call analytics reports including historical calling minutes, and the voicemail rules covering the 3 minute length limit, the exclusion from calling minutes, the consumption of transcription minutes, availability for inbound browser calls but not inbound forwarded calls, and the call recording prerequisite, accessed August 27, 2026.

Sources verified and content reviewed by the Kixie Research Team on August 27, 2026. All source links checked on August 27, 2026.