Our group has been working through ideas over the past week to offer up solutions. These solutions are built leveraging the technologies we use to build enterprise solutions. In this post I will walk through a solution we were building leading up to the Hackathon. The content will be high level and include links back to relevant documentation where appropriate.
Operation: Work From Home
Many businesses in our current crisis have been deemed essential and must find solutions to keeping both workers and customers safe. What aspects of the business can be conducted not requiring the worker or customers to come into direct contact? Twilio and other telecommunications technologies can help move businesses into a remote-friendly world.
Our group started with a simple premise: create simple solutions that require the least amount of buy-in from the business. We want to create solutions that do not require the business to invest into hardware or that are permanent. The solution should not require the business to become experts on the technology or need a dedicated person to babysit a console dashboard.
Workers are currently receiving phone calls from customers via the main business line or other workers transferring a call. To work remotely the calls received on the main business line would need to be routed to a worker’s home or cell phone.
This feels like it could be a cut and dry scenario. Have the business port the number to Twilio, setup Flex/TaskRouter with the workers in appropriate queues, and create a Studio flow to direct customers to the correct queue. This makes a few assumption that a business may not want to buy into. If the business buys into Twilio
- Porting number to Twilio
- How long until the carrier starts routing traffic transfers control?
- What process would the Business need to take to return control if they do not need Twilio post-crisis?
- Will all workers have a computer at home?
To make the process more reversible for the Business we can look into options for forwarding calls from the main business line to a Twilio owned phone number. Most carriers offer an option to either forward from the line itself or use tools to direct incoming calls to a new number. This process is much quicker than requesting a number port and waiting for the operation to complete.
If our workers do not have a computer at home, we need to consider changing the assumption to require them to have either a home or cell phone available. Without a computer we cannot consider using Flex in its current state, lack of mobile client. We can tie a worker’s home or cell phone to a worker in TaskRouter with some additional heavy-lifting to connect that worker with a calling customer.
We will split the solution into two parts: Worker Intake and Basic Flow. Worker Intake will cover the responsibilities of a worker getting enabled for remote work. Basic Flow will cover the experience from the customer and how they are connected with a worker.
Choosing a Global Software Development Partner to Accelerate Your Digital Strategy
To be successful and outpace the competition, you need a software development partner that excels in exactly the type of digital projects you are now faced with accelerating, and in the most cost effective and optimized way possible.
The diagram above outlines a simple intake system for enabling workers to handle remote calls. The worker would place a call or send a text to a Twilio number and that would start a Studio flow. That flow would determine if that work is entering an online or offline state. This state indicates what activity to provide to the TaskRouter worker. When going online the worker also needs to indicate which skill or queue they are servicing. After the data has been gathered Functions will be called to create or return a worker’s ID (SID) and update activity and attributes.
The diagram above outlines the basic flow including the customer experience and the heavy-lifting required to connect that caller with a worker. A caller would be forwarded from the main business line into a Twilio number and that would start a Studio flow. The Studio flow would be business specific and determine the appropriate queue for the customer. When that call is enqueued into TaskRouter it will execute a workflow looking for eligible workers based on worker and task attributes.
Assuming a worker is found a reservation is placed on the worker and an assignment callback will execute a Function to place a call to that worker based on the phone number used in the intake system. It does get tricky that a worker can have any number of life events happen that prevent them from answering in a timely fashion. To avoid an answering machine connecting with a customer we can use AMD, answering machine detection, when placing the call to know if a machine or human answered the call. If a machine answers the call we will need to reject the worker’s reservation to put them back into an available state and hangup on the answering machine.
We can also run into issues placing a call to a worker’s phone number which may either fail the call or report the line as busy. In either case we will need to reject that worker’s reservation to allow TaskRouter to continue searching for workers. In the event that no worker’s are available we may want to either direct that caller to a voicemail box or run custom TwiML. We can handle this case by creating special queues with no workers in them and listening to TaskRouter events when that special queue is entered.
If there was no problem calling the worker then we can dial the queue supplying the reservation ID (SID) and that will connect the customer with the worker.
Tech and Further Reading
This is a good deal of information to digest without accompanying code. In this section I will call out the key documentation and areas to dive into that helped build this solution.
- Functions – Interact with other Twilio Services from Studio / TaskRouter
- Event Callbacks – Listen to TaskRouter Events to handle when no workers are available
- Assignment Callbacks – Handle connecting workers with customers
- Workflows – Getting calls assigned to workers
- Reservations – Accept or Reject customer call
- Workers – Create/Update worker objects
- Call Resource – Placing calls to workers
- Status Callbacks – Determine if called failed or busy
- AMD – Detect if an answering machine answered call to worker
The diagrams in this were created using diagrams.net and the source can be found at the following link – Operation: Work from Home.xml. Download and open this file at diagrams.net to see the original work.