Amazon Echo: 5 Things I Would Change in the Programming Interface

I bought an Amazon Echo a few weeks back. My obsession for restructuring the middle tier of the legal market is well-known--I've discussed it elsewhere. I have recently been experimenting with "AI" chatbots. (Those quotation marks are indicators of irony or perhaps scorn rather than a signal to the reader that they enclose a carefully deployed term of art.) Very disappointed with the state of that technology. So I started thinking about just talking to the computer in natural-ish language and seeing if I could provide legal services that way.

I don't know why I took this turn, but I decided that a well-defined, tightly-constrained problem would be to let people draft qualified domestic relations orders (QDRO) through a voice interface. True, there are legal practitioners who make a science of the carefully-, perhaps unnecessarily cleverly-constructed QDRO. Those people dedicate their professional existence to understanding a slice of ERISA. Masters of all that can go wrong in dividing an ERISA-covered retirement plan and predictably gregarious participants in all manner of social discourse, they charge anywhere from $250 to $500 to draft a single QDRO. I can't say that the fee they charge is unreasonable given the work product they provide, but I often suspect that the work product they provide is unreasonably over-engineered. Would a $75 QDRO do the trick for most people?

[Read more about QDROs: QDROS Are Easy!]

Interaction Model

My dream interaction goes something like this:

Me: Alexa, ask Lawyer Services to Draft a QDRO
Alexa: Who is the plan sponsor?
Me: Best Buy
Alexa: I found 16 retirement plans for Best Buy, would you like me to email them to you?
Me: Yes
Alexa: OK.

{I read the email, which provides an ID # for each plan for clarity}

Me: Alexa, ask Lawyer Services to Draft a QDRO for plan 53243
Alexa: Drafting a QDRO for Best Buy Employee Retirement Savings.
Alexa: Will the plan be divided by percentage or dollar amount? Please say PERCENTAGE or DOLLAR AMOUNT.
Me: Percentage
Alexa: What percentage will the alternate payee receive? Please say a number between 1 and 100.
Me: 50 percent
Alexa: Are loans to be added back into the account balance before splitting the account? Please say YES or NO.
Me: Yes
Alexa: What percentage of the determination fee will be paid by the alternate payee? Please say a number between 0 and 100.
Me: 50
Alexa: Thank you. I have emailed your QDRO to you. Good bye.

5 Things I Would Change in Amazon Alexa

First, the interaction model and the responses your service sends back to Alexa have no way of giving Alexa a hint about what the user should say next. I would like to tell Alexa in the response that the next intent should be one of A, B, or C. I think that would improve the recognition performance and allow for a more natural interaction.

Second, when defining custom types in the interaction model, I would like to be able to include a normalized code. Now, Alexa sends your application the recognized speech as a slot value within the intent. I would like to define synonyms, which would improve the recognition rate, that translate to the same slot value. For example, in my skill, I have a Mongo database that contains every ERISA-governed retirement plan in the United States. I picked the 50,000 most commonly used plans and defined a custom type with those plan names as the custom type values. When Alexa recognizes a plan name, e.g. "Best Buy", I would like for it to send me a code such as "53243" rather than the words "Best Buy" as the slot value.

Third, in the Echo App, I would like to be able to send links or buttons in the response along with the session ID so that users can disambiguate through the app. For example, if I say "Draft a QDRO for Best Buy," the skill server is going to find 10 plans that have the phrase "Best Buy" in them. I would like to send a list of those plans back to the app and have the app display them to the user along with a widget of some sort (button, hyperlinked text, don't really care) that the user could touch that would have the effect of sending an intent to my skill using the same session id just as if the user had spoken the words. I understand that this would require the user of my skill to have his or her phone handy when using my skill, but for the types of database searches and interactions I need to perform in order to offer complex legal services, this is OK.

Fourth, building on the previous change, I'd like to be able to email a message from my skill to the user with a similar disambiguation list.

Fifth, I would like dynamically load custom type values on a per-user-basis into the interaction model. For example, I would like to use Alexa as a voice-enabled front end to my client billing system. That will require the user to be able to say something like "Alexa, tell Client Accounting to bill DALEY for 30 minutes for a telephone call to the judge." For this to work very well, I'll need a custom type that defines the client names (e.g. DALEY), but I don't want to update my custom-type within the interaction model each time one of the users of my billing system adds or removes a client. That would be inconvenient and we can only have 50,000 values right now anyway.

As a bonus suggestion regarding the Amazon Echo hardware, I really wish the Echo could connect to a Bluetooth speaker for output. The Amazon Echo speaker is OK, but not great. I have a house full of Bose Bluetooth speakers that sound amazing. If I could connect my Amazon Echo to one of those, I'd have a party in a can. (I understand that I can do that with the illusive Amazon Dot . . . but only if I can actually buy one!)

Other than the Bluetooth speaker issue, notice that all my suggestions relate to the programming interface. The device itself is a marvel. It looks good, works great, and I only wish I could afford to buy one for every room of the house (although yelling a request from another room works pretty well . . . I'm telling you, this thing is amazing!!).