tjd-poserver

Server for Protective Order Bot

This is a bot server using the Microsoft Bot Server Framework for NodeJs. It is a bot that will

1. See if it recognizes the user. If so, it will load a userProfile object from a MongoDB instance. If it does not recognize the user as a returning user, it will prompt the user for some basic profile data and save the user's profile.

2. Ask the user what the user needs, e.g. Family Violence Protective Order, QDRO, Original Answer.

Value-Add

The societal value proposition for this bot vs. a fill-in-the-blank PDF is that it asks the user for details about what's going on and then, based on experience, guides the user to the proper legal action (or inaction as the facts and law may be). For example, rather than ask "Do you want sole managing conservatorship or joint managing conservatorship?" it asks the user about parenting duties, experience in co-parenting, availability of both parents, etc. and then makes a recommendation. If we're going to replace the lawyers with bots, the bots have to be smarter than a fill-in-the-blank form.

Rather than ask the user to create a proposal for dividing marital assets, it produces a better proposal than most attorneys are capable of and does it in about 300 milliseonds.

The commercial value proposition is that it will channel otherwise non-fee-generating, self-represented litigants to the attorneys who want to subscribe to review more complex documents. The clients will pay a lot less than they would have with full service representation. The attorneys will make a lot less per client, but will have a lot more clients.

This same model, implemented by others and operating within a more complicated regulatory context, will have a similar effect on doctors for whom their practice mostly consists of office visits. E.G. my cariologist could be replaced by a bot and a vending machine that scans insurance cards with only about a weekend's worth of work by a distracted programmer.

Implementation

It implements a library of dialogs that the user traverses under the guidance of a state machine. It uses Google's geolocation rest service to validate addresses. It uses recognition rules to determine the type of court and court number from a combination of county and cause-number inputs. The recognition rules provide for the translation of the court number from a coded value (e.g. "Z" in Dallas County) to an actual court number (Z = "256th" in Dallas County). If there are no recognition rules for the particular county+cause combination or if the user insists on typing in an unrecognizable cause number where we do have recognition rules, then the user is prompted for the type of court and the court designation or number.

Contextualized Information Gathering

One of the principals behind the bot's design is that people may not want to disclose a ton of personal information right away. For that reason, it gets started with the barest essential information then asks for more as it needs more. This gives the user an understanding of why the user is being asked certain questions. As the bot knows more about the user, it asks fewer and fewer questions.

Remember

This is not just a channel into the human sales force or an order page. It is designed to completely satisfy the legal needs of about 20% of all litigants. With the implementation of the attorney review channel, this bot will serve the full legal needs of 25% to 50% of all litigants and free up a huge number of attorneys to go do something useful besides fill out forms.

External Services Used

1. Google.com to validate street addresses and lookup counties.
2. Stripe.com to handle credit card payments.
3. Authy.com for SMS-based 2FA.
4. Mongodb for document storage.
5. Microsoft Botbuilder API to handle the interaction between the client application and my server code.
6. Microsoft LUIS applications to handle conversational "menu" and navigation intents (e.g. "go back").