Requirements

Functional requirements

• Visual accessibility: There are many best practices when it comes to accessibility for the visually impaired. The chat tool should have high-contrast and work with screen readers at the very least. You should not choose vendors that don't meet these requirements -- or you should push your vendor to update their tool for ALL customers to begin meeting these requirements.

• Translations: Based on the demographics of your state, there are likely one or two other languages that your site -- and all corresponding tooling like chatbots -- should be available and fully translated into. When it comes to chatbots, Rhode Island with Twilio gets top marks for availability in 5 languages (English, Spanish, Portuguese, Arabic, French).

  • This is much easier to do for Prompted and Support chat systems rather than free-text or live, because there is a known set of inputs from the customer (clicking on links or options) and outputs (pre-written responses). That doesn't mean multiple languages shouldn't be supported in Live and Free-text chat systems.

  • When choosing a vendor and building the contract, UI agencies should ask how the vendor will support them in providing help in multiple languages.

• Mobile-friendly: For many people, their only way of accessing the internet is through their mobile phones, potentially with limited data plans. Chat integrations should be designed with this smaller screen in mind and be evaluated for how much data they use in the course of operating. If your integration is anything other than directly "out of the box," you should request support be made available to you for ensuring a great mobile experience.

Non-functional requirements

• Availability: You should make sure that the chat is available on any/all pages of your site (or sites!) that get meaningful traffic by people who might be looking for help with unemployment insurance. This would include any separate sites you might have for, e.g.: UI Agency administration, Standard UI/PEUC management, PUA management, re-employment services and support.

• Specificity: In addition to wanting to put your chat content on multiple parts of your site or sites, you want to make sure that chat content from non-UI sites doesn't show up here. This shows up frequently in Support Chat implementations that draw on FAQ content from across the DOL. You should ask the vendor how to set up multiple instances of the chat

• Data usage and speed: If the chat implementation is slow, it increases the odds of someone abandoning chat and turning to a different support channel. People are used to the internet being blazing fast and might find that more annoying and cumbersome than putting their phone on the table and doing other things while on hold. Part of chatbot speed is also related to how it is using data; this is also important as it relates to burdening people with limited data plans as little as possible.

• Quality assurance:

  • It should be easy to test the chat before it becomes available on the website. This is especially true for live chats, to make sure that agents are comfortable with their side of the interface.

  • If the chat is available on multiple pages or sites, it should be easy to test it before it goes live on those different pages. Testing on multiple pages is important to ensure that the chat is always "on top" of the content of the rest of the page; you don't want page content hiding the chat