Since Michael ran off to Iraq to make money hand over fist and left us without a phone system nerd, I was the lucky one that got elected to pick up the slack and figure out how to modify our IVR phone enrollment system this year…
Well, as I look at this code, I realize what a cluster fuck this is. I really don’t know that it’s actually that “bad”, in the scheme of IVRs, but it’s certainly not what I’m accustomed to:
Now, imagine 50+ pages of that (if you printed it out at 70% size that is). All the lines are intertwined and looping back and forth over each other.
So I got started thinking… This is really horrible. How could we simplify this?
Well, if we modularized this code a little more, it’d certainly help. There are several areas that would easily lend themselves to this purpose.
At the very beginning, we set all our initial variables to null (so we don’t get old loop data). Since we loop, we’re repeatedly jumping back up to those, meaning about a dozen seperate lines all returning to the very beginning of the file. We could easily break this out into a seperate subroutine that could be called in-line each time we need to call it, instead of looping back to the beginning every time we need to null out variables.
We could also break out each enrollment “section” into its own subroutine. We’re letting the user select their Medical coverage, their Dental coverage, etc. etc.. Why not put each selection in its own subroutine? There’s really no reason we couldn’t clean up the base flow by eliminating all this extra stuff and simply calling its own subroutine.
After thinking about the ways we could split everything out into subroutines, I started thinking “There has to be a way I could do this with less effort on the IVR side…”
Well, Ajax instantly came to mind, since it’s the “big thing” right now in the blogging world. Sure we can’t actually use it on the phone system, but maybe we could harness the same type of idea.
In an Ajax app, we’re doing JavaScript on the client side, which calls back to server pages (like a PHP or ASP script) for all the processing. That page simply spits out the return text, and the Ajax / Javascript just spits this out on the page, with a very minimum of processing on its end.
Well, this idea could be applied to the IVR, couldn’t it? It has built-in XML support, so why don’t we have it call pages on our intranet server (enroll_ivr.php?type=MED&level=3&plan=1), which goes through the steps we need:
- 1 – Check the validity of the input. If you can’t get level 4 with plan 2, spit out an error.
- 2 – Poll the database. Either retrieve current coverages so we can tell people what they have right now, or insert data into the database to store their selected coverages.
- 3 – Spit back result. Either an <error> segment in the XML, or a <result> segment, containing simple indicators of what to say back to the user.
So it really looks like this would work, making the system a lot easier for me to maintain in the future, at least for me. I imagine that this is a typical reaction for a new developer coming into a system. There are certain areas he doesn’t like or understand as well as others, so he tries to move everything towards the areas he understands. In this instance, I understand the line-by-line nature of a PHP script much better than the arrows-everywhere cluster fuck of this IVR system.
I guess the only problem now is timing. There’s not enough time to make these changes before the enrollment goes live… Hey, maybe I could get it done in time for next year’s enrollment…
And this is for a small TPA???? (what the heck is TPA anyway – excuse my ignorance).
I had to set up the automated attendant for the last company I worked for – 5 departments with a couple or three sub groups in each, and that was bad enough.
Management couldn’t make up their mind exactly what they wanted, and kept changing things every few months. So I got really p***ed off one day and created loops in everything, so that unless you knew EXACTLY which department you wanted you never got to a real person!
Not really relevant to your IVR, but your post reminded me of it, and now I’ve started my day with a smile! Nasty bastard aren’t I?
Heh… yes, this is for a small TPA… at least in the grand scheme of TPAs. TPA = Third Party Administrator. We process health insurance claims for self-insured companies. Basically, an employee goes to the doctor, who submits a claim to us. We process the claim and send a check to the doctor / patient based on their benefits. Their company then re-imburses us the money (or we pay directly out of their account, whatever). A mini-Blue Cross and Blue Shield, if you will.
Thankfully, the IVR was already set up last year, so I really only have to make “minor” changes in the grand scheme of things (add an option here, change a “2005″ to a “2006″ there, and so forth). The problem is… it’s not setup very logically. I really wish I had an extra 2 months to sit down and re-work the whole thing, but I guess I’ll just have to do what I can, and then try again next year.
Oh, did I mention that this particular system has to be live for their enrollment to start November 15th? Did I further mention that they haven’t decided what benefits they’re going to offer yet?
The person I really feel for is our web guy. We only offer an IVR for one company, but we offer web enrollments for at least 4 others that I know of, if not more. He also has to calculate exact premiums so people know how much is going to come out of their paychecks every week. Fortunately, I get to assume they can do that on their own and only ask what they want.
Loops? Sounds like fun… I was thinking about adding progressively more annoyed prompts whenever someone fucks up an entry. “I’m sorry, you picked an invalid option. Please try again.” … “I’m sorry, you picked ANOTHER invalid option. Please try again.” … “Alright, look, pick 1, 2 or 3 ya fucking moron! If you can’t handle it this time, I’m going to call your supervisor at home and tell them you’re a fucking moron and should be fired!”
Think anyone would notice? I mean, honestly, when you’re testing, 90% of your tests are to make sure everything works correctly, not what happens when you fuck up something…