AIサービスの問い合わせを機能要望に直結させない：修正・説明・新機能を分ける

A&Aの考え方

問い合わせを一件受け取ったら、返信を書くのと同じ場で、それが「同じ操作で再現する不具合」「製品は想定どおり動いており、既にある機能にたどり着けていないだけの使い方の不足」「現在の機能では手順そのものが存在しない、まだ作っていない用途」のどれなのかを決めます。そのうえで分類ごとの行き先を先に決めておきます。不具合は原因の特定へ、使い方の不足は説明の修正へ、まだ作っていない用途は需要の記録へ。この三つを分けないまま顧客の文章のまま積むと、バックログは「顧客が書いた文の一覧」になり、次に何を作るかを決める材料にはなりません。

A&Aの考え方

分類を後回しにできない理由は、判断に必要な材料が会話と一緒に消えるからです。その顧客が直前に何をしていたか、同じ手順で再現したか、答えは既にドキュメントにあったのか。これは返信を書いている最中にはわかっていて、一か月後のバックログ整理の場では思い出せません。一人か二人で製品も書いている会社では、受付と開発が同じ人なので、文脈を二度目に組み立て直す機会そのものがありません。だから分類は、月次の整理ではなく受付の場に置きます。

A&Aの考え方

「要望の多い順に作る」という決め方には、分類を省いた分だけ具体的な失敗があります。既にある機能に顧客がたどり着けていないだけの声が、件数の上位に来ることです。機能は存在するのに同じ質問が十件届けば、集計上はそれが最優先の開発項目に見えます。しかし作るべきものは何もなく、必要なのは画面内の案内かドキュメントの一節です。ここを取り違えると、開発の時間を使って同じ機能への二つ目の入口を作ることになり、入口が二つある分だけ次の問い合わせが増えます。

A&Aの考え方

逆向きの取り違えもあります。「説明すれば済む」と分類した案件のうち、説明を直しても同じ質問が続くものは、実際には不具合か、まだ作っていない用途です。つまり分類は一度で確定させる必要はなく、行き先ごとに「次に同じ質問が来たら分類を変える」という条件を書いておけば足ります。件数の集計に意味が出るのは、この分類が付いた後です。分布——たとえば十件のうち不具合が二件、説明が六件、新しい用途が二件といった具合に——を見れば、次の一週間を開発に使うべきか、文章に使うべきかがそのまま読めます。

A&Aの考え方

この記事から取り出せる構造は、三つの分離です。種類の判定が切り分けの最初の工程に置かれていること。種類が次の調査経路を選ぶので、分類がラベルではなく作業の分岐になっていること。そしてバックログへの接続が、一件ごとではなく月次の集計を経ていること。ここまでが出典の記述です。出典が述べているのは切り分けの最初という位置であり、それを返信を書く受付の場に重ねるのはA&Aの移し替えです。同じ構造を一人・少人数の会社に移すとき、エージェントを十八個の道具に繋ぐ部分は要りません。必要なのは、受付時に種類を選ぶ欄と、月に一度その集計を読む予定だけです。これはA&Aの読み方であり、出典が小規模事業について述べたものではありません。

A&Aの考え方

望んでいることと嫌っていることが別の軸で並ぶという書き方は、分類の設計にそのまま効きます。満足度という一つの数字に潰すと、この二つは足し合わされて消えるからです。またA&Aの読みとして、二つの出典からは同じ順序が取り出せます。集計された傾向を先に見て、それから個別のやり取りに戻って根拠を確かめる。逆順——気になった一件から一般化する——を避けるための順序です。A&Aの解釈として、少人数の会社でこの順序を守る最小の仕掛けは、分類欄に加えて「その問い合わせをそう判断した材料」を一行だけ残しておくことです。再現手順、顧客が実際に踏んだ画面、既存のドキュメントに該当箇所があったかどうか。月次でまとめを読むときに戻る先が、この一行になります。

A&Aの考え方

ここからはA&Aの提案です。出典が名前を付けているのは、Gumloopの「ワークフローの失敗／使い方の質問／エージェントの問題」という切り分けまでで、本稿の三分類そのものではありません。その考え方を借りて組み直した三つに、実務で現れる三つを足して六行にします。足すのは「動作は想定どおりで、約束の書き方が誤解を招いているもの」「他の顧客の業務には当てはまらない一件限りの要求」、そしてAIを使うサービスに固有の「出力のぶれ・モデル更新後の劣化」です。一つ目は開発でもドキュメントでもなく、提供範囲を書いた文章——営業資料や受入条件——の問題です。二つ目を需要の記録に混ぜると、分布が歪みます。

A&Aの考え方

表は、分類の名前、見分けるための材料、行き先の三列で足ります。重要なのは三列目です。行き先が先に決まっていない分類は、結局バックログに落ちます。行き先は「開発の候補として原因を特定する」「ドキュメントと画面内の案内を直す」「需要として件数と業務の種類だけ記録する」「提供範囲を書いた文章を直す」「個別の見積もりを出すか、断る」「再現セットに入れて不具合か仕様かを先に判定する」の六つで、どれも一つの分類に対して一つだけ対応します。最後の一つが要るのは、同じ入力でも出力が揺れる製品では「動かない」という一文が不具合とも仕様とも読めてしまい、判定を飛ばすと開発とドキュメントの両方へ間違って配られるからです。

A&Aの考え方

この表は判断を自動化するものではありません。Gumloopの記事も、月次のエージェントが作るべきチケットを「提案する」ところまでしか書いておらず、誰がどのように採否を決めるかは書かれていません。提案の先に人が決める工程を置くべきだというのは、A&Aの読みです。表の役目は、月に一度まとめを読むときに、比べられる形のデータが残っていることです。分類が付いていない三十件の文章と、分類と材料が一行ずつ付いた三十件は、同じ時間で読んでも結論の確かさが違います。

A&Aの考え方

分類が費用に見合わない場面があります。週に数件しか届かない段階では、創業者の記憶がまだ文脈を保っているので、表は手間だけが残ります。表が効き始めるのは、問い合わせが記憶より長く残るようになってから、あるいは二人目が返信を書き始めてからです。よくある反論も書いておきます。受付で分類すると一次返信が遅れる、月に一度まとめて仕分けるほうが安上がりだ、という主張です。受付と開発の担当が分かれている会社ではそのとおりで、返信の速さを優先する判断は成り立ちます。本稿が逆の結論になるのは、一人か二人の会社では受付と開発が同じ人であり、あとで仕分けるという「あとで」に別の担当者がいないからです。分類にかかる十数秒は、文脈を失ったまま一か月後に推測し直す時間より短い、という比較になります。もう一つの限界は、分類と開発の優先順位が別の判断だということです。本稿は分類までしか主張しません。分布は、書き込んできた顧客の中での頻度であり、黙って離脱した人や、そもそも申し込まなかった人については何も語りません。声の大きい要望を市場全体の需要と同じものとして扱わない、というのがここでの制約です。

A&Aの考え方

この二つはいずれも、その会社自身またはその取引先が書いた記述であり、独立した監査ではありません。三倍という数字は定義が書かれていない以上、他社の見込みとしては使えない、というのがA&Aの判断です。Gumloopの規模も、サポート面そのものが自社製品であるプラットフォーム企業の話であり、その中の二人のサポートチームは、一人で全部を抱えている会社と同じ条件ではありません。規模の数字ではなく、種類を最初に決めてから先へ渡すという構造だけを取り出しています。

A&Aの考え方

A&Aとして測っていないことも明示します。この分け方によって問い合わせが減った、成約が増えた、継続率が上がったという実測値は当方にはありません。本稿は二つの公開された一次記述と、そこから小規模事業向けに組み直した設計案です。全体の流れの中でこの工程がどこに位置するかは「AIネイティブGTMとは？一人・少人数で顧客獲得から継続まで回す実践ガイド」で扱っています。返信側の負担を減らす話は「同じ問い合わせで手が止まる：Intercomに学ぶ対応余力の作り方」、AIに受けさせる前に人へ戻す条件を決める話は「問い合わせをAIで受ける前に、人に戻す条件を先に決める：回答率より誤った解決の負担を見る」が近い判断を扱っています。どの分類に開発を割り当てるかが自社で決まらない場合は、初回相談で分布の読み方から相談できます。