Twilio Phone Client
My roles
Timeline
01
Context
Twilio provides APIs to send/receive SMS and calls. However, it does not provide an easy way to do these things as a human. This is by choice, but it has nevertheless been a frequent request from our users.
Additionally, due to regulatory requirements, getting a local phone number from Twilio in most countries requires some paperwork and days of processing. This complicates delivering instructor-led training in such places.
That’s because learners need a phone number from Twilio if they want to receive messages or calls. They can use US phone numbers which are easy to procure, but testing with US numbers from local phones often comes with additional cost.
02
Problem statement
Twilio’s training participants need an easy way to interact with Twilio’s US phone numbers, without having to use their personal non-US handsets.
03
Design process
This was a problem I wanted to tackle for a very long time. In my roles both as a Twilio trainer and a developer living in Asia, I kept running into the limitations of local phone numbers and the difficulty of interacting with US ones almost daily.
There were existing projects that tackle this problem individually for SMS and calls. But I wanted something universal so that we didn’t have to give each learner two separate clients. And something reactive that would immediately notify the user when a new message came in, without having to refresh the page.
When Twilio released its contact center platform customizable through React and I needed to learn this new framework, I used this as a learning exercise.
A softphone client is a solved problem from a UX perspective, so I didn’t need to reinvent the wheel. Other than the standard essential features, I wanted the following:
Voice
- Ability to receive calls and be notified when a new call comes in, even when interacting with the SMS part of the app
- Dialpad should play DTMF codes when in a call to be able to navigate DTMF IVRs
- Indicator for how long a call has been in progress
SMS
- Threads where messages from the same sender are displayed together, chronoglogically
- Ability to send a message to a recipient using a phone number; if a thread for that number already exists message should be added to it, if it doesn’t a new thread should be created
- Ability to display details like timestamp, message SID and number of segments for each message
04
Development
The voice part of the app is a fairly standard use case for Twilio’s Voice JavaScript SDK.
The messaging part was more of a challenge. Twilio’s Programmable SMS API doesn’t have a JS SDK. But Twilio does have another messaging product with a JS SDK: Programmable Chat. So to facilitate the real-time updates and threading, I bridged the two products and used Programmable SMS for the GSM side and Programmable Chat for the client side.
05
Impact
This became a surprisingly successful project with more users than I would have imagined.
It was referenced in official training materials as the recommended way for non-US learners to test Voice and SMS APIs.