うまく聞き取れるだろうか、意図を読み違えないだろうか。導入前の議論は、たいていここから始まります。ところが実際に設計へ入ってみると、時間を取られるのは別のところだったりします。

問い合わせのパターンを洗い出し、言い回しの揺れを想定し、分岐を作り込む。ここまでは準備できます。

それでも外れます。「先週出した申請の件なんですけど」。用件を言っているようでいて、こちらの分類のどこにも入りません。「これ、前任者がやっていた処理なんですが」。そもそも何の話なのかが、その一言では特定できません。

しかも分岐を細かく作り込むほど、外れたときに落ちる場所が遠ざかります。精度を上げる努力が、外れたときの被害を大きくしてしまうこともあるのです。

申請番号と所属部署で本人を特定する、という設計にしたとします。でも、ここで止まることが、想像よりずっと多いのです。

例えば、申請者が番号を控えていない。部署名が組織変更前の呼び方のまま。本人ではなく、上司が部下の分をまとめて聞いてくる。どれも珍しい話ではなく、毎日のように起きます。

設計で決めることは、かなり細かくなります。何回まで聞き直すのか。2回か、3回か。どの時点で人に引き渡すのか。など

そして、見落とされやすいのが引き渡し方です。すでに入力された番号を一緒に渡さなければ、相手は同じ番号をもう一度伝えることになります。自動化したのに手間が増えた、という不満はこういうことから生まれます。

渡すときに何を持たせるかも、一つずつ決めていくことになります。入力済みの情報、何回目で外れたのか、どの質問で止まったのか。この3つがあるだけでも、受け取った側が問い合わせ相手に行う初動が全く変わります。

そして最後に、必ずこの問いが残ります。業務時間外に想定していた回答から外れた人は、どこへ行けばよいのでしょうか。

担当者がいない時間帯なら、折り返しの予約を取るのか、翌営業日を案内して終えるのか。ここが空欄のままだと、どれだけ丁寧に分岐を作っても設計は終わりません。

すべてが自動で完結することはない、ということは最初からわかっています。決めなければならないのは、完結しなかった分をどう扱うかなのです。

AIを入れる話をしていたはずが、うちはどの相手にどこまで手をかけるのかを決める話になっている。難所は、聞き取れるかどうか、意図を読み違えないだろうか、ではないところにあります。

皆様の現場ではいかがでしょうか。