This is a bit of a ways out, but this app has relatively few dependencies, and (I think) all configuration occurs (or could occur) via environment variables.
which would bring someone to a simple web form to configure stuff, like so:
In our case, the stuff they'd have to configure would be:
PHONE_NUMBER_TO_CONNECT: the phone number of the office to call, for example '+14151112222'
BUTTON_SEQUENCE_TO_REACH_HOLD: a button sequence that gets you to the "holding" part of the phone system, for example "www1ww1ww2" for "wait 1.5 seconds, press 1, wait 1 second, press 1, wait 1 second, press 2"
TWILIO_SID: your Twilio SID
TWILIO_AUTH: your Twilio auth token
TWILIO_PHONE_NUMBER: your Twilio-purchased phone number
URLs for three voice files:
a. "Welcome" message for user
b. "Loop message" for agency representative (eg, "Hi! This is Leo, head of HSA. I have a client waiting on the other line for you. Press 1 to connect.")
c. "Sorry!" message if the rep hangs up
Anyway, this is neat, and DEFINITELY not v1, but an interesting model to test out, esp since with this approach an agency could just deploy this for themselves with like 20 minutes of work.
cc @RebeccaCoelius @migurski @cydharrell @lanebecker for the product intrigue
This is a bit of a ways out, but this app has relatively few dependencies, and (I think) all configuration occurs (or could occur) via environment variables.
That makes letting people deploy via Heroku Button ( https://blog.heroku.com/archives/2014/8/7/heroku-button ) pretty darn easy, which would be cool for a host of reasons.
Basically, we'd have a button in our README:
which would bring someone to a simple web form to configure stuff, like so:
In our case, the stuff they'd have to configure would be:
Anyway, this is neat, and DEFINITELY not v1, but an interesting model to test out, esp since with this approach an agency could just deploy this for themselves with like 20 minutes of work.
cc @RebeccaCoelius @migurski @cydharrell @lanebecker for the product intrigue