The Twilio Erlang library has a built in Extended TWIML library that is compiles to a human readable statement of the state machine and the state machine that implements it. It also guarantees that the state machine doesn't hang for the user.

So for example you write:

     SAY1 = #say{text = "My you are looking swish"},
     RESPONSE1 = #response_EXT{title = "Praise", response = "1", body = [SAY1]},

     SAY2 = #say{text = "What you looking at, fannybaws?", language = "en-gb"},
     RESPONSE2 = #response_EXT{title = "Abuse", response = "2", body = [SAY2]},

    SAYD = #say{text = "can you no use a phone, bawbag?", language = "de"},
    DEFAULT = #default_EXT{title = "a slagging", body = [SAYD]},

    % now put them all together
    [#gather{numDigits = 1, autoMenu_EXT = true, after_EXT = [RESPONSE1,
                                                              RESPONSE2,
                                                              DEFAULT]}];

and it compiles to:

    1 - GATHER (request Keypad Input)
        1.1 - SAY "Press 1 for PRAISE. Press 2 for ABUSE. Do nothing for A SLAGGING"
        1.2 - end of Gather (wait for response)
        1.3 - Response 1 : PRAISE
            1.3.1 - SAY "My you are looking swish"
            1.3.2 - HANGUP
        1.4 - Response 2 : ABUSE
            1.4.1 - SAY "What you looking at, fannybaws?"  en-gb
            1.4.2 - HANGUP
        1.5 - Default : A SLAGGING
            1.5.1 - SAY "can you no use a phone, bawbag?"  de
            1.5.2 - HANGUP

Disclaimer: I wrote it...

This article is fantastic and describes the Canonical Right Way to model Twilio call flows which every serious user of Twilio seems to independently rediscover but which no one has covered at this length in a public post before. I strongly, strongly suggest you read it.

I worked at a business services group that implemented IVR applications for years, using vxml, and this pretty much describes exactly how that company built their products.

Another coachup dev here: how have others' experiences with Twilio been?

We actually moved off Tropo because Twilio seemed to be better documented and we were having SMS deliverability issues with Tropo.

Anyone used Twilio for SMS? That's next up on our Twilio integration.

Yep, we're (heavy) users of Twilio SMS. Aside from maybe two incidents that I can think of in the last 3 years, they've been rock solid for us. I am struggling to remember any customer complaints from SMSes not being delivered -- while I think our scale guarantees that this has probably happened (yay telephony), it doesn't happen often enough for it to impact customer results for us. (The typical customer will be sending dozens to hundreds of them a week, so one or two going undeliverable do to carrier issues/user error/etc is not the worst thing in the world for us.)

Used Twilio at two companies, primarily for voice. Support has always been stellar. The biggest advantage has been not worrying about infrastructure as we grew from X,000,000 minutes per month to XX,000,000. Essentially, you convert any CAPEX to OPEX, with all benefits and penalties thereto.

SMS, we had to move over in a pinch (less than a day from zero to production), so integration is definitely super easy. Our volume was much less impressive - XXX,000 per month.

The biggest outages have been during elections season. That said, Twilio has taken a lot of steps to ensure that won't happen next time around. The response times and follow-ups to any outages have always been very quick and transparent, which is all one can ask of a vendor.

As far as I know, Twilio is still the major provider for that company, but I have moved on to ad tech space. :)

As patio11 said, this is a good approach and that was a well written post. I wrote twilioflow for similar reasons, including ease of testing interactions.

https://github.com/dkeskar/twilioflow

Its been 3 years and Twilio has come a long way. All the best to you guys!

What IS a state machine?

"A finite-state machine (FSM) or finite-state automaton (plural: automata), or simply a state machine, is a mathematical model of computation used to design both computer programs and sequential logic circuits. It is conceived as an abstract machine that can be in one of a finite number of states. The machine is in only on one state at a time; the state it is in at any given time is called the current state. It can change from one state to another when initiated by a triggering event or condition; this is called a transition. A particular FSM is defined by a list of its states, and the triggering condition for each transition." Source: http://en.wikipedia.org/wiki/Finite-state_machine

Basically, it's a way to track known "state" of a system and know valid and invalid (or prohibited) operations that can be performed and what "next" state these operations move the system to.

For example, in a phone call, if the state is "ringing", your next options can be "answered", "no answer", "busy", or "failed" (including refusal to route, not in-service numbers, etc.). If you try to move the call into some other state, for example, "queued", a state machine should refuse to do so and respond with an error.

A more complex example could be in managing conference rooms or call transfers.