“Betwixt & Between” is another phrase that begins many Celtic tales, together with “Once there was a time that was no time….” It describes a state being neither fully this nor that, but a little of each, some of neither, and perhaps something else altogether! “A time that no time” speaks to a setting completely outside of time as we know it, where there are either no rules of time at all, or so many complex rules as to confuse the hapless time-traveler! And that was exactly the way to describe this project for a large cable company (the name has been fictionalized, here) with a need for a robust application to serve customers wanting to put their services on vacation hold.

What made it “betwixt & between” and “a time that was no time”?

• The modalities were not fully committed to either IVR of chatbot. It was a bit of each, a bit of both, some of neither (the data store that would serve both). This “each, both, and neither” nature had to constantly be taken into account when designing.

  • The design was primarily for chatbot, but need to present information identical to that in the IVR, in ways that would sync with the IVR and be mirrored there, so that it could be accessed and changed in either modality — without data loss!

• The business rules for vacation holds were so extraordinarily complex — and potentially confusing to users! — that it could seem like a vacation hold could happen only in “a time that was no time”. Distilling these rules into clear guidelines that took, and kept, the user in “normal time” with a clear understanding of what s/he could and could not do to create a vacation hold became a primary goal of the design.

The project

The project was part of a larger revamp of both the client’s IVR and chatbot applications, updating them to apply to their current technologies and services, and leveraging the power of AI to drive the system responses.

The modalities

As noted above, the primary modality for this design was chatbot. Part of the reason for this was to be able to offer the user a clear visual calendar display for choosing vacation hold dates. This also enabled us to blackout or dim dates that became inapplicable or unavailable, based on the business rules applied to the user’s account. In contrast, the corresponding design for the IVR would initially offer the range of dates available, but would then respond and correct users that made choices that did not conform to the applicable business rules.

​The strategy

The overall strategy was to use essentially a “funnel” approach, by first applying behind-the-scenes business rules that might apply to the user, including:

Eligibility rules

• Residential service(s) only

• Account must be at least 30 days old, with uninterrupted service the entire time

• Account must be in good standing, with no outstanding balance due

• Standalone Access or Voice Only are eligible, without changing plan

Business rules for creating a vacation hold

• Minimum 30 days of service between vacation breaks

• Each vacation hold must be at least 60 days, but no more than 270 days in a rolling 365-day period

  • The 365-day period must be measured both from the Vacation Hold Start date and End date, to ensure compliance

  • This could mean that the end date would need to be adjusted, depending on the chosen start date.

    • This could also make the vacation hold impossible, as the required 60-day minimum would exceed the 270-day limit.

    • The user must then be told that vacation hold is not available until XXX date.

    • Either the start date or the end date (or both) might need to change, in order to comply.

The outcome

The chatbot portion has been successfully deployed and is estimated to have achieved a 35% reduction in transfers to agent. Because the deployment is fairly recent, that figure is expected to increase and accelerate, once the accompanying IVR functionality is fully deployed.

The resulting bot itself was surprisingly unremarkable, a model of simplicity and clarity — as it should have been! — so it is not replicated here. But the underlying logic for creating this simple, easy-to-use interface and keeping the user in “normal time” instead of lost in “a time that was no time”, in the business rules….. Well, that was the interesting part, and is shown in the accompanying interaction flow (with the actual company name fictionalized).