Commentary: Government Chatbots Shouldn't Rely on Extra Apps

With the popularity of chatbots rising to the top of many public-facing government initiatives, it’s becoming essential to evaluate where the data lives and how it gets exposed. This requires us, as public servants, to analyze and provide the best solutions while considering the residents’ investments in their communities, better known as taxes.

As a taxpayer myself, I would like to see the best return on investment (ROI) for the money I pay. ROI is a concept that some do not view as a high priority in government agencies. In private industry, it plays a much larger role to the end product. In fact, it becomes a sales point!

Where data lives and how it is accessed are issues that require more strategic analysis than one might think. With more cloud usage — solutions deployed to Azure or Amazon AWS, for example — comes more strategic architectural design for performance reasons.

Another issue is that some data is public and does not require as much security, while other data might require that certain business rules be applied — HIPAA regulations, address redaction, etc.

Accessibility is another challenge, in that some data that’s posted in one place — i.e., the Frequently Asked Questions on a government website — isn’t readily accessible due to vendor constraints and architectural designs, or lack thereof. This causes replication of effort. This is not exactly 100 percent the case, as chatbot response design requires a bit more processing. The good news is that even with replication of effort, this is where the ROI pays off: If you attack items that generate the most desk time and phone calls to a department, you begin to realize the time savings, and then you can begin to see the reduction of handling the public’s requests. Thus, the cost of the duplicate effort up front is acceptable, as long as it is temporary. 

This replication of effort can cause a vendor to jump and provide their own version of a solution, such as the chatbot concept. The problem with this, put simply, is isolation. In some cases, it isolates the solution from accessing other data points or exposed services — GIS data, for example — that aren’t necessarily supplied by the same vendor. APIs and code libraries that are built to allow integration points into the solution become essential and required for optimal success of the product. The question is: How well does the solution interface with other products? The service bus architecture begins to play a big role in this. But this becomes more difficult as many governments leap into the cloud: There will be a time when they arrive at a hybrid model, both on premises and in the cloud, where a service bus design will cause performance constraints on the solutions. This, in turn, can cause delays. I have mentioned in the past that a chatbot might take half a minute to respond because of such constraints. This is OK, but it will require that the consumer be provided feedback and an expectation of the result.

In addition to replication of effort, another hurdle is the inability to leverage digital personal assistants — Google Assistant or Amazon Alexa, for instance — that are already successful. This is apparent in systems designed for back-end solutions with Interactive Voice Response (IVR). The problem is you lose access to an established user pool of people using Google Assistant or Alexa.

At some point, government has to leverage what is already “winning” the market and provide a more seamless solution. With advances in technology, it seems every solution has a separate application to download. This is not sustainable, as it requires users to have more space on their devices (and potentially a larger expense), reducing the likeliness that they use the solution.