あおい
サポートのフローチャートに「上長へ回す」とだけ書かれていても、判断条件、引き継ぐ情報、顧客への連絡担当は分かりません。使えるエスカレーション図には、分岐、次の担当者、渡す根拠、顧客への返信を含めます。
発動条件と引き継ぎ記録を定義します。 いつ別チームを巻き込むか、共有できる事実、次の更新を担当する人、顧客への伝え方をフローに書きます。認証情報や決済情報などの機密データは共有図に置かず、承認済みシステムを参照します。通常の担当者が不在の場合の分岐も示しましょう。
まず共有オンラインホワイトボードで経路を確認し、その後で実際のサポートシステムに設定します。Zendeskの解説でも、支援の階層や権限は組織によって異なるとされています。Boardmixは経路を設計する場であり、問い合わせを自動振り分けするわけではありません。
まず一種類の問い合わせに絞る
サブスクリプション更新後、顧客が請求を二件見つけたとします。一次対応者はアカウントと取引の参照情報を確認できますが、二件目が保留中の承認か確定した請求かは請求担当者の確認が必要です。開始点は顧客からの申告、終点は説明して終了するか、未解決の案件を請求担当者が引き受けるかです。
確認できる条件で分岐させる
- 相談内容、取引参照、確認済みのことを記録します。不要なカード情報はボードに貼らないでください。
- 状態を「承認待ち」「請求確定」「まだ不明」に分けます。
- 一次対応の権限内で説明できるなら、現状を顧客に伝えて記録します。
- 不明な場合は、調べた内容、顧客への影響、次の担当者、次回連絡の予定をまとめて請求担当者に渡します。
- 調査後は承認された経路で結果を伝え、最初の分類が違っていれば図も修正します。
返金条件や解決時間を推測で書き込んではいけません。実際の社内規程と顧客への約束に合わせます。Zendeskの別の案内も、記録された一次判断とサービス上の約束との整合を重視しています。
引き継ぐ情報を矢印のそばに置く
相談の要約、確認した取引、試した対応、影響、現在と次の担当者、次回連絡の時点を示します。分からない項目は推測せず「未確認」とします。請求担当者が分類の誤りに気づいた場合の戻り先も必要です。
引き継ぎの中で未解決の問い合わせがなぜ増えるのかを考えるには、新規受付・再オープン・解決を分けたサポートの未解決件数を表すストック・フロー図の例が役立ちます。
Boardmixで役割別に描く
「顧客」「一次対応」「請求担当」のレーンを作り、作業は四角、判断はひし形、条件は名前を付けた矢印で表します。引き継ぎ情報を担当者が変わる箇所に置きましょう。規程の責任者が確認した後、実際のサポートツールへ実装します。
フローチャートのテンプレートは図形を用意しますが、条件と権限はチームで決める必要があります。
