Chatbot
development in Ottawa

A department of the Government of Canada that buys a chatbot, or a supplier who builds one for it, has to answer an early question. Does the bot only answer questions, or does it help decide something about a person? The answer sets how much paperwork, review and design work follows. It also changes the budget.

The Treasury Board Directive on Automated Decision-Making covers systems used to make or support administrative decisions about people. A bot that explains office hours, points to a form or summarises a published policy usually sits outside that line. It informs. The person still applies, and an officer still decides.

The picture changes once the bot starts sorting people. Telling a user that they seem ineligible for a benefit, ranking a request as urgent or routine, or sending some cases to a faster queue and others to a slower one can shape the outcome. At that point the bot is part of a decision, even if a human signs the letter at the end. Write this boundary into the specification before any design starts, because moving it later means rework.

For systems inside the scope, the directive expects an Algorithmic Impact Assessment. It is a structured questionnaire about the purpose of the system, the data it uses, the people it affects and how reversible its effects are. The result is an impact level, and each level carries its own set of requirements. Departments publish the completed assessment. Plan for that from the first sprint.

Higher impact levels bring heavier duties. Expect peer review of the system, testing for unintended bias in the data and the model, and a plan for monitoring results after launch. At the upper levels a person must make the final decision. The bot can gather facts and suggest a route. It cannot close the file.

Keeping a human in the loop is a design task, not a slogan. The officer needs to see what the user typed, what the bot concluded and why, in one screen. If the officer has to open three systems to check a suggestion, the suggestion gets accepted by default, and the safeguard exists on paper only.

The directive also asks for meaningful explanation to the person affected. For a chatbot this means plain wording at the moment the route is chosen. Say which answers led to it, say that a person reviews it and say how to ask for a different outcome. A bare verdict is not enough.

Logging underpins all of this. Keep the conversation, the version of the model and the rules in force, the suggestion made and the final human decision. Without that record nobody can audit a complaint or test for drift months later.

Suppliers should price these duties from the start. An assessment, a review and an explanation screen add weeks. Leaving them out of a bid is cheaper only until the department asks for them.

Every chatbot meets messages it cannot parse. Someone types half a sentence, pastes an order number with no context or asks two things at once. How the bot behaves in those moments shapes trust more than its best answers do. People forgive a bot that is honest about confusion. They leave a bot that answers the wrong question with confidence.

The first design choice is the threshold. Language models and intent classifiers both produce some measure of how sure they are. Below a certain level the bot should stop and ask, instead of guessing. Set that level with real transcripts, not in a meeting. Too high, and the bot pesters people with questions it could have answered. Too low, and it invents.

A good clarifying question is narrow. Asking the user to rephrase is lazy and usually produces the same words again. Offer two or three likely meanings as buttons instead. Did you mean a refund, an exchange or a delivery problem? The user taps one, and the conversation moves.

Short messages need their own handling. A single word such as invoice or password can mean a dozen things. The bot can reply with the few most common tasks linked to that word. It reads as helpful, and it teaches the user what the bot covers.

Then there are questions outside the scope entirely. A support bot for a software product will be asked about the weather, the stock price and jokes. Decide in advance whether it deflects politely or plays along briefly. Either is fine. Inconsistency is the problem.

Messages with two questions deserve care too. The bot can answer the first and then say it noticed a second one, instead of silently dropping it. Users rarely repeat themselves, so a dropped question is a lost request.

Loops are the most damaging failure. The bot asks, the user answers, the bot asks the same thing again. Put a counter in the flow. After two failed attempts on the same point the bot should change strategy: show a menu, offer a search of help articles or step aside. Repeating itself a third time is never right.

The wording of the fallback message matters. Avoid apologising at length. One short line that admits the gap, followed by a concrete next step, works better than a paragraph of regret. Keep the tone the same as the rest of the bot.

Finally, treat misunderstood messages as data. Tag every fallback in the logs with the original text. Once a week someone reads a sample, groups the patterns and decides which ones deserve a new answer, a new button or a clearer opening message. That review often shows that the confusion started in the greeting, where the bot promised more than it could do.