There’s no particular reason you couldn’t build a tel: URI (<a href="tel:...">) with those tokens in it.
As with other non-universal URI schemes, you’d want to test those links on a variety of devices (including desktops with softphones) so you know what to expect when people say they don’t work as expected.
Thanks Sanford. Yeah I imagine there will a lot of trial and error in testing this. Fingers crossed a participant ID can get added to a link. I'd still plan to give the event id and participant ID separately in the email, but want a one-touch option as the ideal way to join by dial in only so we're not relying on someone to enter a participant ID after the fact.
Again, would much prefer that everyone just use the {{member.webinar url}} token, but understand if the user literally can't even open the link to then choose a dial in option. We can obviously tell folks to register and we'll send a recording, but that's not the best experience. Curious on what other community members have done about this. Every org I've been at has had this issue to an extent and I've never seen a solution that satisfies everyone at scale.
Following up on my own comment here after doing some testing today. Realized real quick it is NOT possible to associate a phone number to a registered individual if they do not additionally join by computer:
Per zoom: "You will be prompted to enter your unique participant ID. This only applies if you have joined on the computer or mobile device or are a panelist in a webinar. Press # to skip."
I had originally misunderstood this to mean any participant can enter a participant ID back to associate them to a person on the registrant list. Not the case. In actuality it's just a code used to tie together audio back to one unique individual who joined separately by both phone and by computer. It's a numerical code like "#243910#", and it changes every time you join. It's not an actual fixed value for a person, and it's not the registrant ID mentioned in the thread above. That {{member.registrant id}} token btw, while unique to an individual, generates an encoded value like "HE7bx6_tTROzVDgGdh3ueQ". Couldn't work in a phone number even if we wanted it to :).