Local Presence Dialing today only works within US/Canada area codes. For agencies and businesses operating across multiple countries, there's no equivalent. The team has to manually select the right number from the dropdown every time, for every call and every SMS. One forget, and the message goes out from the wrong country.
Real-world example
We're an Australian agency. One of our clients operates internationally and has numbers in Australia, the US, the UK, and Canada in their sub-account. Their team calls and texts contacts in all four countries every day. Right now they're stuck either:
Manually picking the right number every send (high friction, easy to forget), or
Setting one default and accepting that calls/SMS to other countries go out from the wrong national number, which kills answer rates and triggers spam labels on the receiving carriers.
Proposed solution
Extend the dynamic selection logic so it works on country code, not just area code:
Detect the contact's country code (+1, +44, +61, etc).
Look at the numbers available in the sub-account.
Auto-select the matching country number as the outbound caller ID / SMS sender.
Fall back to the sub-account default if no country match exists.
Toggle on/off at the sub-account level, same as current LPD.
Why it matters
Spam labelling and deliverability: A local number gets answered far more often than a foreign one, and avoids spam flags on the recipient carrier.
Reduces human error: No more team members forgetting to switch and sending an SMS to a US customer from the AU number (or vice versa).
Saves clicks at scale: For any team doing volume across multiple countries, this is dozens of clicks per day per user.
Unlocks GHL for cross-border use: Today, agencies with international clients have to either accept the manual workflow or look at third-party dialers. This would close the gap.
The infrastructure already exists for US/Canada via LPD. The request is to apply the same selection logic at the country-code level, with the same fallback behaviour.
Voice and SMS both, ideally.
Thanks!