View profile

Call Theory Braindump - Issue #10

Patrick Labbett
Patrick Labbett
Today I’m walking through the IVR I created for Call Theory’s new technical support line using Twilio Studio.
Yes, you heard that right: I’m working on not taking calls directly on my personal cell phone!
Mental health powers, activate! - The Wonder Twins, probably
Get comfy - this is a long one.

Twilio Studio
Why did I use Twilio Studio?
Being the technical support line for Call Theory, I wanted the ability to quickly modify the IVR without needing to make code changes on my servers.
  • I wanted a quick feature toggle in the event of unplanned events
  • I wanted to be able to re-route on the fly (voice and text)
  • I wanted minimal reliance on my server infrastructure
  • I wanted scalable infrastructure for down the line
  • I didn’t want to do a lot of infrastructure work to start
So it’s pretty easy to see how Twilio Studio - a serverless workflow management engine for inbound call and messaging flows through Twilio, would make sense. Already being a Twilio customer (since…well, forever) it was an easy onboarding.
Time commitment
Granted, I have a deep-understanding of and experience using Twilio APIs, so the time commitment for me will be different depending on your familiarity with the platform.
Otherwise, I had only looked at Twilio Studio once or twice in the past for a few minutes just to follow up on blog announcements I had read.
From nothing to a fully integrated IVR broken down:
  • Getting comfortable in general usage of Studio - 1 hour
  • Scoping capabilities of Studio for my IVR - 1 hour
  • Writing integrations for the IVR - 1 hour
  • Building the IVR - 3 hours
  • Revising the IVR (troubleshooting, optimizing experience) - 2 hours
So it was roughly 8-hours over the course of a weekend.
Goals of the IVR
Designing and implementing a new IVR (or even just making changes to your existing ones) will go much easier if you have specific goals you want the IVR to achieve.
For my purposes, this is what I was looking for:
  • A single phone number for clients to call, text, or MMS
  • Reduce friction using the IVR as to not further exasperate tensions during emergency technical support situations
  • An automated way to filter technical support calls for active customers
  • Integrate caller information into answering service scripting
  • Automated decision-making based on holidays and working hours
  • A shortcut to skip the PIN for customers who won’t use the portal
One number to rule them all
Before this update, I had a local number, a toll-free number, an emergency number, and most of my clients had my personal cell phone number.
I needed to make easier for clients (and myself) - so consolidating to a single technical support line seemed like the right call.
Reducing friction
You’ll see many of the goals are about reducing friction for customers or myself.
  • A single number makes it easier for clients to know where to call.
  • A single number makes it easier for me to tell clients where to call.
  • Automated filtering ensures I can list the phone number publicly so customers don’t have to login to get the support number.
  • Give answering service agents information about the caller when routed to them to reduce duplicate information gathering.
  • Ensure my IVR disclaimer aligns with ongoing holidays and business hours to avoid frustrations with incorrect recordings.
  • Not every customer I have cares about or uses the portal - they just want my support help. I need a way for them to get through without too much hassle.
Another improvement to reduce friction was to also enable users with active MFA setup (via Authy) to automatically bypass the support PIN when calling from that number.
This was to both promote the use of MFA (which will be required at some point) and to reduce the friction of calling the IVR for those who regularly and securely utilize the portal.
Automated filtering
The emergency support number used to be “hidden” behind a paywall on the Call Theory portal.
It still sort of is - you are asked to upgrade before it will display - but the number is also publicly listed on the new contact page now.
The goal here was to stop taking calls directly, and ensure all clients had fast access to emergency contact information. Being publicly listed, the number now needed to have filtering built-in (to avoid anything that wasn’t an active support customer.)
I ended up choosing a Support PIN methodology. Each user has a randomly generated (and unique) PIN visible on their dashboard that must be entered before being connected with technical support dispatchers or engineers.
The PIN is available per user within your organization, but you are welcome to share it freely with your employees
The PIN is also displayed on the Call Theory Support page next to the number, so you don’t have to jump back to the dashboard to get it.
The 24/7 technical support number is also displayed alongside the PIN on your dashboard, so no matter which section you use, you will have the PIN readily available.
Empowering call center agents
The goal behind using a PIN was to ensure that only customers on the Level Up plan could get through - so the PIN links backs to the Call Theory account for plan verification live during the IVR call.
Since we are already performing this action, I wanted to reduce the friction between the initial agent answering the call, and the customer experiencing an issue.
As a result, the IVR will save an in-memory-only copy of the link between the support PIN and the caller’s number so that the answering service scripting can use an API (in Amtelco world, the Web Service scripting element) to pre-fill that information into the script.
  • Name - Pre-fill the Name field in the script
  • Company - Pre-fill Company field in the script
  • Phone - Used for our engineers to call the person back
  • Email - Used for creating tickets in the Call Theory ticketing system
  • Time zone - Context on time difference from caller
  • User Account Age - For thank you transition messages
  • Team Account Agent - For thank you transition messages
  • Plan - The name of the current plan the user is on - should always be Level Up at this time due to IVR filtering
Holidays and working hours
A few years ago, I built an automated system for managing holidays for my weekly office hours emails reminders.
If you are a subscriber, please join us!
Using this same baseline model, I was able to quickly implement a check on whether the current day was in my existing holiday list and inform the IVR.
This lets me have one place to update my holidays and working-hours to change the behavior for both Office Hours email reminders and IVR emergency disclaimers. Nice!
Easy mode for owners
Did you know that not all of my customers use the Call Theory portal? Shocking, I know. There are those who signed up to support me (or, rather, to get support from me) and have never logged back in since.
They aren’t going to login to get their support PIN. They are just going to keep calling my cell phone or get annoyed until they find another option. Not ideal.
As a result, I implemented a quick check for these customer’s phone numbers before asking for a PIN to route them (skip ahead) properly within the IVR.
You too can enjoy this access through any of the following methods:
  • Setting up your MFA and calling from that number
  • Upgrading to Call Theory Managed Services
  • Emailing with the number and reasoning
Studio Integration
First I want to explain how I approached the integration between Studio and Call Theory plans. The portal application that runs includes a JSON API - so I leveraged it to add in 4 new API routes:
  • Support PIN lookup
  • MFA check and skip
  • Office hours and holiday check
  • Answering service
Twilio Studio includes a Make HTTP Request widget which provides a Success and Fail “transition” - i.e., when you make a HTTP request it will be either successful (2xx messages) or failed (4xx, 5xx errors.)
As a result - and to keep it simple (no parsing) - my API integrations return a 200 OK or a 400 Bad Request with an empty body and I’m not doing any additional parsing of the responses.
Think of it as Studio asking my API a yes or no question and getting a yes or no response:
  • Is MFA enabled to skip entering a PIN? No.
  • Is the PIN entered right? Yes.
  • Is it a holiday or after hours? Yes
This also promotes me keeping the logic in my application and not co-mingling logic between Twilio Studio and my API endpoints.
The exception is the Answering Service API route which returns a JSON object of the data for the call center platform to consume and integrate into the agent scripting.
Make HTTP Request widget in Twilio Studio
Make HTTP Request widget in Twilio Studio
A quick note on Studio
The interface is really nice, but it can be… challenging… to arrange things so that they make sense visually. Take your time when doing this as it will make repeat visits to update your workflows (Studio Flows) much easier.
I also went the route of making distinct widgets for each workflow instead of trying to re-factor and make all of my widgets more re-usable.
Since my IVR will be fairly simple, I want the capability to tweak minor things between different flows without having to figure out how to build that update into a re-usable component (and potentially impacting other unrelated flows.)
If my IVR was more complicated than this, I would likely have spent the time making things more re-usable to reduce the overall number of widgets needed.
The full IVR flow
Call Theory Technical Support IVR, full Studio Flow
Call Theory Technical Support IVR, full Studio Flow
All Studio Flows start with a trigger - for my purposes I’ll be sticking with the Incoming Message and Incoming Call triggers to handle inbound SMS/MMS and voice phone calls, respectively.
All Studio Flows start with a trigger...kinda like Amtelco's MergeComm!
All Studio Flows start with a trigger...kinda like Amtelco's MergeComm!
Incoming Messages
This is the simplest part of the flow. It’s just so that I can tell customers to text pictures to the technical support number instead of my work phone number.
Widget 1: sms_setup
This Set Variables widget sets a variable (like a Set Field in Amtelco world) that holds my support phone number.
This is where we will send the messages to when they come in. I can use this variable later in the flow to avoid hard-coding values and allow quick updating of number usage across the flow.
Widget 2: text_patrick
This Send Message widget does exactly that - it sends an SMS/MMS Message to the number we setup in the previous widget. I’ve modified the parameters so that it will send a text message that includes an identifier [CT], the original number that texted the message, and the content of the message.
You can’t spoof SMS messages. Attempting to re-use the caller ID for sending the SMS to another number will fail and alert you in the Error Logs that it’s not a valid number for sending SMS.
There is no response back to the end-user - it’s just a central place to receive MMS from customers without putting the onus on a single technician to answer their text messages 24/7.
The entire SMS/MMS flow for Technical Support
The entire SMS/MMS flow for Technical Support
Incoming Calls
This workflow is much more complicated and would take me way too long to write out in the same detail, so I’m going to cover the big points of the workflow.
Widget #1: api_key_setup
We will start off with pretty much the same way we started off the SMS flow - setting up a few variables for us to use down the line.
  • An API key for accessing the API routes created earlier
  • A phone number for forwarding the call to a technicians work phone
  • A list of numbers to dial (simulring) to reach my answering service
I did not re-use the same Set Variables widget from the SMS trigger to avoid having to do parsing on what widget to go to next. I have a designated Set Variables for each trigger type, even if it means potential variable duplication at the start of each flow - partly to ensure we don’t impact other flows when messing with variables.
I use a Set Variables widget for each trigger to keep flows isolated. Your requirements my differ.
I use a Set Variables widget for each trigger to keep flows isolated. Your requirements my differ.
Widget Grouping: VIP Setup
A VIP in the context of this IVR just means one of two things:
  • I manually programmed their number into a list to check for skipping the IVR because they can’t or won’t use the portal themselves.
  • The user has enabled MFA and is calling from that phone
So basically we use the {{}} variable from Twilio Studio (the persons number) and compare it against a list of phone numbers using the Split Based On… widget.
If it’s in the list, they are a VIP, and get sent to the welcome_vip widget.
The welcome_vip and welcome_message widget recordings are the same. The only difference is that non-VIP users can begin entering their PIN as soon as the message begins playing.
VIP means skip requiring the PIN because we know who they are, probably.
VIP means skip requiring the PIN because we know who they are, probably.
Widget Grouping: PIN Validation
This widget grouping includes:
  • Gathering the PIN
  • Checking the PIN against the API
We haven’t talked about recordings much yet. Let’s keep it simple for now: I uploaded professional recorded files to the Call Theory portal that are referenced by Twilio Studio widgets. In order to get the verbiage I was hoping for without paying for a re-read I ended up duplicating widgets (instead of mashing and duplicating recordings.)
So the basic workflow comes out like this:
  • Welcome message starts playing - they can enter their PIN here without waiting
  • PIN is checked via the API call with a Success or Failure
I split checking the PIN from two different voice prompts into different flows to avoid....parsing!
I split checking the PIN from two different voice prompts into different flows to avoid....parsing!
Widget Grouping: Disclaimer and Forward
This widget grouping makes an HTTP request to check if the office is open (Success, 200 OK) or closed (Fail, 400 Bad Request) and then plays a disclaimer about emergency rates on holidays/afterhours, or a reminder to visit the Call Theory website during working-hours.
Next, it connects the call to my work phone - just like normal.
The final section of the voice IVR trigger in this flow
The final section of the voice IVR trigger in this flow
Now that this IVR is in place, I’m ready to swap over to an Answering Service to better protect my time.
But how do I actually swap to the answering service when I’m ready?
  • Log into Twilio
  • Open the Studio Flow for Call Theory Technical Support
  • Drag the green lines from the connect_to_patrick widget to the connect_to_answering_service widget.
  • Click Publish.
Drag and drop flow-reorder, from a browser, on-demand.
Drag and drop flow-reorder, from a browser, on-demand.
The Connect Call To widget has a few options, but I’m going to focus on:
  • Single Number
  • Multiple Numbers (Simulring)
The Single Number option is pretty self-explanatory - it will connect the call to the number specified.
The Simulring option is a bit more interesting. We can specify a comma-separated list of E.164 formatted numbers and Twilio will initiate an outbound attempt to each number.
The first number to answer the simulring (in telecom terms - meaning auto-answer, agent, greetings, answering machines, etc.) will get the call and all other attempts will be cancelled out.
Since my answering service provides a primary and a backup DID for call-forwarding, I can setup Simulring to ring both DIDs at once.
Whichever gets answered first cancels the other call. The result is the answering service only gets one call. But if their carrier provider has issues and a DID fails, the other number will still get rang without any operational changes.
Again, nice!
That Telephone Voice
I briefly referenced professional recordings earlier, but to give some additional context - I worked with one of my favorite voices in the industry: Allison Smith.
She is pretty much the voice of VoIP, having done Asterisk (i.e., Genesis) voices with Cepstral and being a mainstay in almost every popular telecom system in the last 20 years at some point.
Give her a try if you are in the market - I really enjoyed working with her. Sorry, I don’t have a referral link or anything nifty.
Allison Smith’s website:
5/5 would recommend
Wrapping up
So as a recap, my technical support IVR:
  • Has only one number for customers to reach
  • Forwards SMS/MMS to technicians work devices
  • Filters out non-contract customers from technical support calls
  • Fast-tracks those with MFA enabled or who won’t use the portal
  • Checks against my office hours/holiday schedule for disclaimer details
  • Can be swapped between my answering service and myself on-demand via a web-browser
  • An API integration for call center to help process the calls faster
There are a few things I’d still like to do at some point:
  • Add Voice Response to the IVR (Say instead of press digits)
  • Move hard-coded VIP check to another API method
  • Change the SMS/MMS forward to an email submission to my support desk software
I didn’t build this for fun. I will be using it to protect much of my time and focus on projects, prep for training, and finally getting to the point of hiring Call Theory Employee #1.
If you happen to call the Call Theory Technical Support line and get the answering service - now you’ll know why.
Thank you again for all of your support and for reading this giant wall of text. I hope my latest brain-dump provides some measure of helpful information in some form.
-Patrick Labbett
Link spam below.
Call Theory - Support for call centers
Official NotifiUs, LLC business information.
Safely transfer credentials
Patrick Labbett - Ohio is for heroes
Did you enjoy this issue? Yes No
Patrick Labbett
Patrick Labbett @calltheory

Security, infrastructure , technology, telecom, tools, insights, customer service, and shared frustrations with the call center and answering service industries in mind.

In order to unsubscribe, click here.
If you were forwarded this newsletter and you like it, you can subscribe here.
Created with Revue by Twitter.
NotifiUs, LLC dba Call Theory, 3963 Mad River Road, Grove City, Ohio 43123