チケットコンソール · サポートの司令塔

チケットコンソールは、チームがサポート案件を処理するための司令塔です。保存済みビュー付きのキュー、中央に顧客とのやり取り、右側にSLAタイマーとAIによるコンテキストが並びます。受信メール、マクロ、ルーティング、自動化、インシデント、ナレッジベース、チームの指標もすべてここにまとまっています。

チケットコンソールは、SellioCRMのサポート用コンソールです。顧客からの最初のメールから満足度アンケートまで、キューに並んだ案件を処理するための専用の場所です。CRMと同じチケットオブジェクトを使うため、すでに記録している内容(件名、会社、取引先担当者、カテゴリ、チャネル)はそのまま有効で、顧客の360度ビューにも表示されます。

サイドメニューのサービスグループから、チケットコンソールを開きます。フォームでの登録、ステータス別のボード、リストビューを使いたい場合のために、チケットオブジェクトも同じグループに残っています。

3ペイン構成のレイアウト

コンソールは、一日中対応する担当者のために3つのペインで開きます。左側にビューとキュー(件数付き)、中央に顧客とのやり取り、右側に案件のコンテキストが並びます。スマートフォンでは、場所を取らないようにビューのペインがリスト上部のセレクターに変わります。

キューと保存済みビュー

• 左側の列には、それぞれの件数が付いた既定のビューが並びます。対応中、未割り当て、自分の担当、保留中(顧客または第三者の返答待ち)、本日解決済みです。
• 保存済みビュー: ステータス、優先度、割り当て、グループで絞り込んだフィルターに名前を付けて保存できます。たとえば「サポートチームの緊急案件」などです。専用のカウンター付きでリストに表示されます。
• キューの上部には、検索(件名または依頼者)、優先度フィルター、並び替え(新しい順、古い順、優先度順、SLA期限順)があります。
• 各行には件名、依頼者、ステータス、優先度、担当者、SLAの状態が表示され、色付きのバッジですばやく読み取れます。
• 一括操作: 上部のチェックボックスをオンにして複数の案件を選択し、ステータスや担当者をまとめて適用できます。

エージェントコンソール

案件を開くと、中央にやり取りが時系列で表示され、右側にプロパティが並びます。依頼者、受信チャネル、タグ、ステータス、優先度、カテゴリ、担当者、グループです。プロパティを変更すると、その場で保存されます。

1. 作成欄で、顧客に見える内容を書く場合は顧客への返信を、チーム内だけに見える内容を残す場合は内部メモを選びます。
2. 内部メモは顧客に伝えた内容と混同しないよう、別の色で強調表示されます。
3. 添付をクリックすると、メッセージと一緒にファイルを送れます(1件あたり最大25MB)。公開返信では、顧客に送信されるメールの本文にも添付ファイルのリンクが入ります。
4. 入力したら送信(またはメモを追加)をクリックします。

• 受付番号: すべての案件に組織ごとの連番が付与されます。形式は#000123です。この番号は変更できず、キュー、案件の上部、返信メールに表示されます。
• タイムライン: タイムラインタブでは、公開メッセージと内部メッセージ、変更イベント(作成、ステータス、優先度、担当者、その他のプロパティ)が時系列で1つにまとめて表示されます。
• メンションとフォロワー: 内部メモでメンションを使うと同僚を呼び出せます。相手に通知が届き、その案件をフォローするようになります。誰でもプロパティのパネルからフォローや解除ができ、更新のたびに通知を受け取ります。

マクロと変数

1. マクロを管理をクリックし、タイトルと本文を持つ定型返信を作成します。
2. 必要に応じて、そのマクロを使ったときに適用するステータスと優先度をマクロ側で指定できます。
3. 作成欄でマクロを適用からマクロを選ぶと、本文が返信欄に入り、設定されていればステータスと優先度も適用されます。

マクロと返信では、二重波かっこで囲んだ変数を使えます。送信時に値が埋め込まれます。{{protocol}}、{{ticket_subject}}、{{requester_name}}、{{agent_name}}、{{org_name}}などです。チャネルとルーティングでは、公開返信に付加されるサポート署名を設定できます。エージェント個人の署名がある場合は、そちらが優先されます。

SLA: 期限、一時停止、営業時間、祝日

SLAの状態はキューと案件に表示されます。対応中は期限内またはSLA違反、解決後は期限内に解決または期限超過で解決と表示されます。右側では、初回返信、次回返信、解決のタイマーがカウントダウンし、色が変わります。緑、期限が近づくと黄色、超過すると赤です。ステータスを解決済みまたはクローズに変更すると、解決日時が自動で記録されます。

• 自動一時停止: 案件を顧客の返答待ちまたは第三者の返答待ちに移すと、解決タイマーが一時停止し、SLA一時停止のバッジが表示されます。対応中のステータスに戻すと、タイマーが再開します。待機していた時間は目標にも指標にもカウントされません。
• 次回返信: ポリシーごとに次回返信の目標を設定できます。タイマーは顧客が返信した時点で始まり、エージェントが公開返信をするたびにリセットされます。
• 営業時間: SLAと営業時間タブで、曜日、時間帯、タイムゾーンを設定します(サマータイムに対応するため、America/Sao_Pauloのような形式でタイムゾーンを指定してください)。この制限を無効にすると、24時間365日の実時間でカウントされます。
• 祝日: 日付を指定して祝日を登録します。その日は営業時間外として扱われ、期限は次の営業日に繰り越されます。
• ポリシー: 各ポリシーは優先度、グループ、カテゴリで一致条件を判定し(空欄はすべてに一致します)、営業時間の分単位で目標を定めます。リストの上から順に評価され、最初に一致した有効なポリシーが適用されます。一致するポリシーがない場合は、設定のサービスにある優先度別の時間数が使われます。
• 違反リスク: 推定バーが、期限超過のリスクが低、中、高のいずれかであるかを理由付きで示します。

受信メール: メールが案件になります

1. チケットコンソールを開き、チャネルとルーティングタブに移動します。
2. サポート用アドレスを生成をクリックします。CRMがsupport+あなたのコード@ドメインの形式のアドレスを表示します。
3. 利用中のメールプロバイダーで、サポート用メールボックスをそのアドレスに転送します。
4. これで完了です。新しいメールが案件を作成し、顧客からの返信は同じやり取りに追加されます。

送信者はメールアドレスで取引先担当者に紐づけられます。初回は取引先担当者が自動作成され、案件のチャネルはメールになります。顧客に送るすべての返信の件名には、[#XXXXXXXX]の形式で案件コードが入ります。顧客がこのコードを残したまま返信すると、新しい案件を作らずに同じやり取りへ追加されます。案件が解決済みまたはクローズだった場合は再オープンします。

自動の受付確認メール: チャネルとルーティングで受付確認を有効にし、変数を使って本文を書きます。メールから新しい案件が作成されると、依頼者にはすぐに受付番号入りの確認メールが届きます。初期状態では無効です。

案件のマージとサイドカンバセーション

同じ用件で案件が2つできてしまった場合は、残したい方の案件を開いてマージをクリックします。もう一方のメッセージが主となる案件に移り、そちらは移動先を示すメモとともにクローズされます。

顧客に見せずにサプライヤーや他のチームとやり取りしたい場合は、メインのやり取りのすぐ下にあるサイドカンバセーションを使います。件名と参加者のメールアドレスを入力してメッセージを書くと、CRMが送信します。内容はすべて案件に記録され、顧客とのやり取りとは分けて保管されます。

自動割り当てと自動化

チャネルとルーティングで、案件がグループに入ったときにチームごとにどう振り分けるかを設定します。ラウンドロビン(エージェント間で順番に割り当て)または負荷分散(対応中の案件が最も少ないエージェントを優先)を選べます。常に手動で割り当てる場合は無効のままにします。

自動化タブでは、何かが変わったらこう動く、という形式のルールを作成します。各ルールにはイベント(案件が作成された、またはプロパティが変わった)、ステータス、優先度、カテゴリ、グループ、担当者に関する任意の条件、そして1つ以上のアクションがあります。

• アクション: ステータス、優先度、カテゴリの設定、エージェントまたはグループへの割り当て、マクロの適用、担当者への通知、グループ全体への通知、満足度アンケートの送信です。
• ルールは作成や変更が起きたまさにその瞬間に実行されます。コンソール、レコードの編集、連携など、CRMのどこからの操作でも同じです。
• 名前の左にあるハンドルをドラッグすると並び替えられます。ルールは上から順に評価されます。
• 時間ベースの自動化: 一定の間隔で自動的に実行され、期限を基準に動きます。たとえば、営業時間でX時間初回返信がない案件をエスカレーションする、期限が近づいたら知らせる、解決からN日たったものをクローズする、といった動作です。1つの案件につき最大1回だけ実行されます。
• 送信Webhook: チャネルとルーティングで、案件のイベント(作成、更新、解決、新規メッセージ)ごとに外部システムへ通知できます。署名付きURL、または連携ハブですでに接続済みのメッセージチャネルへ送信します。

案件のAI

AIを有効にすると、右側のパネルが案件を分析して、カテゴリと緊急度、0から100までのスコア付きの顧客の感情、履歴の要約、類似案件、ナレッジベースの記事を提案します。作成欄の返信を提案(AI)ボタンを押すと、やり取りをもとに、あなたの画面の言語で返信の下書きが作られます。AIが単独で顧客に何かを送ることは決してありません。確認し、編集し、判断するのはあなたです。

ナレッジベースとヘルプセンター

あなたのナレッジベースは、タイトル、本文、タグで検索できるセルフサービス型の公開ポータルの元になります。ページの下部にある「まだ解決しない場合」のフォームは、入力中に関連記事を提案し(デフレクション)、それでも必要な場合はCRMに直接案件を作成します。

• マーケティングのナレッジベースでは、記事タブで執筆、編集、レビュー依頼ができます。レビュータブは承認待ちのキューです(承認して公開、または理由を付けて却下)。インポートタブはURLから下書きを作成します。フィードバックタブでは、読者の投票をもとに役立った記事と改善が必要な記事が分かります。
• 保存のたびに履歴が残り、以前のバージョンに戻せます。
• 記事ごとに言語を設定でき、公開検索は読者の言語で絞り込めます。
• SLAと営業時間タブでは、ポータルの起票フォームを組み立てます。氏名、メールアドレス、件名、本文に加えて、テキスト、リスト、メール形式の独自フィールドを条件付き表示で追加できます。1つを既定に設定すると、ヘルプセンターがそれを使います。

インシデントとステータスページ

1. コンソールのインシデントタブを開き、タイトルと重大度を入力してインシデントを作成します。
2. 同じ事象の影響を受けた案件を紐づけます。
3. インシデントのタイムラインに更新を投稿し、紐づいた案件の依頼者へのメールで、影響を受けた全員に一度に連絡します。
4. 解決時には根本原因とポストモーテムを記録します。
5. 公開に設定すると、顧客に開かれたステータスページとして公開されます。

満足度と指標

案件を解決またはクローズすると、CRMが依頼者に満足度アンケートのメールを自動送信します。1から5の評価とコメントを尋ねるもので、1件の案件につき1回だけ送られます。顧客が回答すると、評価がコンソールの満足度ブロックに表示され、その案件のフィールドにも保存されます。自動化の満足度アンケートで有効と無効を切り替えられ、もう一度依頼したいときはアンケートを再送信を使います。

指標タブでは、7日、30日、90日の期間を追えます。作成、解決、対応中の件数、初回返信の平均時間、平均解決時間、SLA遵守率、回答率付きの平均満足度、バックログ、初回接触解決、再オープン率、チーム別の負荷を、チャネル別とカテゴリ別のセグメントおよびエージェント別のテーブルとともに確認できます。各指標には前の期間との増減と日次のミニグラフが表示され、レポートはPDFまたはXLSXで書き出せます。

よくある質問

• アンケートの送信には、依頼者のメールアドレス(案件のフィールドまたは紐づいた取引先担当者から取得します)と、メール送信の設定が必要です。
• 設定のプライバシーでデータ主体の情報を書き出したり匿名化したりすると、その依頼者のメッセージ本文と評価も対象に含まれます。
• 外部ヘルプデスクとの連携は、CRMに案件を自動作成します。作成された後は、ほかの案件と同じようにここで処理できます。
• モバイルアプリでも、キューの確認、案件の作成、返信、ステータスの変更ができます。
• 顧客が自分で案件を確認し、返信や再オープンを行えるようにするには、カスタマーポータルの記事をご覧ください。

親子チケット、自動応答ルール、チャネルのマッピング

チケットを別のチケットにぶら下げられるようになりました。チケットに親を設定すると子が一覧で表示され、循環や深すぎる連なりは防御機構が拒否します。未解決の子が残っている親を閉じようとすると警告が出ます。自動応答は固定文から**ルール**になりました。ルールごとに条件（チャネル、カテゴリ、優先度、営業時間、最初のメッセージのみ、キーワード）とメッセージを持ち、最初に一致したものが使われます。ループ防止は意図的に無効化できません。自動応答の受信箱に返信することは、留守番電話どうしが永遠に話し続けるのと同じだからです。チケットのチャネルは、あなたが管理する**マッピング表**から決まるようになりました。ヘルプデスクに電話で入った案件が「ポータル」と記録されることはなくなり、チャネル別のレポートが嘘をつかなくなります。

場所: 親と子はチケット本体の「関連ケース」パネルに表示されます。ルールは「設定 → 自動返信」に、チャネルの対応付けは「設定 → チケットのチャネル」にあります。どちらもアカウント管理者向けです。

案件に3つ目のタブ「コンテキスト」が加わりました。ここでコンソールは、別の画面へ移動させるのをやめます。チケット自身の項目（作成したカスタム項目も含む）、関連レコード、活動とタスク、ファイル、親子案件、そして同じ顧客の他の未対応チケットが並びます。チケットオブジェクト用に Canvas を作成している場合は、そのレイアウトがこのタブにも適用されるため、同じものを二度作る必要はありません。

対応結果コードでチケットをクローズする

これまでチケットの解決は、解決欄に自由記述を書くことでした。それは何が起きたかを説明しますが、分類はしません。二人の担当者が同じ対応結果を十通りに書くため、先月のチケットのうち何件が製品の不具合で、何件が設定ミスだったのかを誰も答えられません。カテゴリ項目も助けになりません。あれはチケットを開いたときの内容を分類するもので、クローズしたときの結果を分類するものではないからです。

そこで対応結果は、**設定 → 対応結果コード** で自分が管理する短いリストになりました。各コードにはラベル、適用範囲、そして選んだときに説明を必須にするかどうかの切り替えがあります(説明がなければ何も伝わらない「その他」に使ってください)。同じリストがチケットにも通話にも使われるので、同じことを言う二つの語彙ではなく、一つの語彙だけを保てます。

1. 設定 → 対応結果コードを開き、既定のリストを作成をクリックするか、独自のリストを作成します。
2. ルールを適用したい場合は「解決時に対応結果を必須にする」をオンにします。
3. コンソールでは、チケットを解決する前に右側の対応結果ボックスで結果を選びます。

意図してそうしている動作が三つあります。覚えておいてください。

• **コードが一つもない状態で必須をオンにしても、何も止まりません。** そうでなければ、誰かがチェックを入れた日に、選ぶものが何もないまま社内のすべてのチケットが凍りついてしまいます。
• **必須を守らせるのは画面ではなくサーバーです。** 一覧からでも、マクロからでも、API からでも、ターミナルからでも、クローズは同じ検査を通ります。
• **すでに使われたコードは削除できず、無効にできるだけです。** 削除すると、そのコードでクローズしたすべてのチケットの意味が失われ、過去のレポートが黙って嘘をつき始めます。

定型文: 入力したショートカットで呼び出す決まり文句

これまでコンソールで使える決まった文章はマクロだけでした。マクロはステータスと優先度も適用するため、文章を差し込むだけで、誰も頼んでいないのにチケットが変わってしまいます。定型文は文章以外に何も書き込みません。だからこそ軽く、個人のものにでき、入力したショートカットで呼び出せます。

1. 入力欄で :: に続けてショートカットの先頭を打ちます。例: ::hi。
2. そのまま打ち続けると候補が絞られます。:: だけを打つとライブラリ全体が表示されます。
3. 一覧から文章を選ぶか、ショートカットを最後まで打って確定すると、完全に一致するものが挿入されます。
4. 送信前に本文を読んでください。{{protocol}}、{{ticket_subject}}、{{requester_name}}、{{agent_name}}、{{org_name}} などの二重波かっこの変数は、マクロと同じく返信を送信する時点で差し込まれます。

ライブラリは3種類あります。**個人**(自分だけが見えます)、**チーム**(そのチームの人)、**会社**(対応する全員)です。同じショートカットが複数に存在してもよく、自分に近いものが勝ちます。個人の文章はチームの文章に勝ち、チームの文章は会社の文章に勝ちます。会社の標準を変えてもらわなくても、自分の ::hi を持てるということです。

• **ショートカットに空白とコロンは使えません。**最大40文字です。空白を含むショートカットは :: の後に打てないため、表示されない文章になる前に、保存の時点で断ります。
• **ショートカットは同じライブラリの中で一意です。**同じ ::hi を個人の文章と会社の文章として持てますが、会社の文章として二つは持てません。
• **検索は大文字小文字とアクセントを無視し、**ショートカット、タイトル、フォルダの順に見ます。本文は検索しません。よくある単語がライブラリの半分に当たってしまい、ショートカットの意味がなくなるからです。
• **並び順はいつも同じです。**打った文字で始まるショートカット、次にそれを含むショートカット、次にタイトル、次にフォルダ。開くたびに順番が変わる一覧は、体が覚えた操作で違う文章を選ばせてしまいます。
• **フォルダは自由入力で、**画面上でライブラリをまとめるためだけに使います。別途カテゴリを管理する必要はありません。

個人の文章は自分のものです。誰にも断らずに作成、編集、削除ができます。チームと会社の文章は社内の標準で、明日みんなが顧客に送る内容を変えるものなので、設定を管理する人のものです。他人の個人の文章は誰も編集できません。管理者でも同じです。

チケットのメール: イベント、言語、カテゴリ、キューごとに自社の文面

チケットの5つの場面で自社の文面を使えます。**受付**、**更新**、**解決**、**アンケート**、**クローズ**です。各テンプレートは1つの言語で書き、必要ならカテゴリ、キュー、またはその両方に限定できます。

選び方の順序は決まっていて、二つに分けて読むと分かりやすくなります。システムはまず**何を言うか**を決め、その後で**どの言語で言うか**を決めます。組み合わせは具体的なものから一般的なものへ順に見ます。キューとカテゴリ、次にキュー、次にカテゴリ、最後に汎用です。キューがカテゴリより重いのは、キューが答えるチームであり、文面はその声だからです。カテゴリは話題にすぎません。

• **空の条件は「何でも可」、埋めた条件は一致が必須です。**カテゴリのないテンプレートはどのカテゴリにも使われます。カテゴリを指定したテンプレートはそのカテゴリ専用で、汎用の文面の代わりにはなりません。
• **言語は、選ばれた組み合わせの中で決まります。**まず完全一致(pt-BR)、次に同じ基語(pt-PT は pt-BR に使えます)、次に予備の言語で、指定がなければ英語です。
• **その3つの言語がどれもない組み合わせは飛ばし、**次のより一般的な組み合わせを試します。読む人の言語で汎用の文面を送るほうが、その人が読めない言語で最適な文面を送るよりましだからです。
• **言語より具体性が優先されます。**請求の組み合わせが英語だけにあり、汎用がポルトガル語にある場合、ポルトガル語で書いた相手には請求の文面が英語で届きます。直し方は、同じ組み合わせのポルトガル語の行を足すことで、それこそが表があなたに求めていることです。

判断に使う言語は、メールを読む**問い合わせ元の人**の言語であり、担当者の言語ではありません。件名と本文はマクロや定型文と同じ変数を使え、プレビューでは何も送信される前に、どのテンプレートが選ばれ、どの言語なのかを確認できます。

スウォーム: 難しい案件に人を呼び、その結論を残す

スウォームのセッションは、これまで社内メモに散らばっていた進め方を記録します。誰を、どの役割で、どの問いに答えるために呼んだのか、期限はいつか、そして何が結論になったのかです。**記録するのはセッションであり、Slack のチャンネルを開いたりビデオ会議を始めたりはしません。**会話はこれまでどおりの場所(社内メモ、メンション、フォロワー、社内チャット)で続きます。新しく生まれるのは、その記憶だけです。

1. チケットでスウォームを開き、理由を書きます。期限は任意で、過去の日時は指定できません。
2. セッションを開いた人が**報告者**になり、そのチケットをフォローし始めます。
3. 必要な人を**専門家**(人数制限なし)または**書記**(1名のみ)として呼びます。呼ばれた人には理由を含む通知が届き、チケットをフォローし始めます。
4. **結論**を書いてセッションを閉じます。結論は社内メモとしてチケットに戻るので、次に案件を引き継ぐ担当者は他を開かずに読めます。

• **1つのチケットに開いているセッションは1つだけです。**2つあると注意が二分され、結論の置き場所も一つでなくなります。
• **報告者と書記は埋まっている間は1名限りです。**専門家に上限はありません。人を呼ぶことこそスウォームの目的だからです。
• **報告者はセッションから抜けません。**抜ける道は、結論を書いて閉じることです。「結論は出なかった」でもかまいません。
• **閉じるには結論が必須で、**全員の参加も終了します。参加時間の合計が勝手に増え続けないためです。
• **抜けた人も記録に残り続けます。**誰が参加したかは、明日も本当でなければなりません。

予定したフォローアップと個人のリマインダー

似ていますが別物の2つの操作です。**フォローアップ**はチケットに関するタスクです。他の人に任せられ、他のタスクと同じようにその日の一覧に並びます。**リマインダー**はいつでも自分のもので、指定した時刻に通知が届きます。一日の終わりのまとめではありません。

1. チケットで「フォローアップを予定」または「リマインドする」を選びます。
2. いつかを自分の言葉で書きます。明日9時、2時間後、金曜日、来週、あるいは 2026-09-10 14:30 のような日時です。製品の10言語を理解します。
3. フォローアップでは種類(タスク、電話、メール、会議)を選び、必要なら担当する人も選びます。リマインダーは常にタスクで、常に自分のものです。

• **時刻のない日付は09:00になります。**組織のタイムゾーンで、製品の他の場所と同じ既定値です。
• **期間指定は現在の時刻を保ちます。**期間の指定にはすでに時刻が含まれているからです。分と時間は実時間で数え、日と週はカレンダー上を進むので、夏時間でずれません。
• **すでに過ぎた時刻は翌日になります。**どのリマインダーアプリでも同じです。一方、過去の日付は推測せずに断ります。どの日のつもりだったかを当てにいくのは、作り話になるからです。
• **365日より先は断ります。**指が滑ったときのための歯止めで、2026年に打ち込まれた2027年は、誰も見ないまま残ってしまいます。

09:00 が補われたときや翌日に送られたときには、画面はあなたが打った言葉ではなく、実際に**保存された**時刻をそのまま返します。「これはいつ期限か」に二つの答えがある状態こそ、この読み返しが防ぐための混乱です。

作業タブ: 複数の案件を同時に開く

コンソールは案件を一度に1件しか開けず、別の案件を選ぶと前のものが置き換わっていました。件数をこなす人は3件も4件も同時に進めます(顧客待ちが1件、開発待ちが1件、いま書いている1件)。そのたびに下書きとスクロール位置が失われていました。作業タブのバーは会話の上にあり、2つ目のものを開いた瞬間に現れます。

• **シングルクリックはプレビュータブを開きます。**斜体で表示され、次のプレビューがその場所を取ります。書き込むか固定すると、そのタブは残ります。これがないと、20件のキューを見て回るだけで20個のタブが開いてしまいます。
• **同じ案件が二度開くことはありません。**もう一度クリックしてもタブが選ばれるだけで、残した下書きとサブタブはそのままです。
• **青い点は、そのタブに書きかけで未送信の返信があることを知らせます。**閉じた後ではなく、閉じる前に見えている必要があるものです。
• **タブごとにサブタブ(会話、履歴、コンテキスト)を覚えます。**最初からではなく、いた場所に戻れます。
• **タブは最大8つです。**それを超えると、下書きのない最も古いタブが外れます。すべてに下書きがあるときは上限のほうが譲ります。書いたものを失うほうが、バーが長いことより悪いからです。
• **開いているタブを閉じると右隣が選ばれ、**右がなければ左が選ばれます。ブラウザと同じ挙動です。

**保存済みを閉じる**は、下書きのないタブをすべて閉じ、下書きのあるタブを残します。片づけが書いたものを持ち去ることはありません。タブはこの端末のブラウザの中にあるので、チームのものではなくあなたのものです。

顧客のコンテキスト: ヘルス、価値、プラン、サポート履歴

案件のコンテキストタブは、あなたが一行も書かないうちに、この顧客の調子はよいのか、どれだけの価値があるのか、どのプランなのか、これまで何度がっかりさせてしまったのかに答えるブロックから始まります。どれも誰かが入力したものではありません。すべて、製品がそのアカウントについてすでに持っている情報から組み立てられます。

• **ヘルス**はスコアと、それ以上に大切な**その内訳となる要因**を示します。数字だけでは打つ手が分かりません。要因を見れば、問題が利用状況なのか、サポートなのか、お金なのか、関係そのものなのかが分かります。
• **価値**は、獲得した売上、継続収益、そして直近の増減を出します。先月のアップグレードと先月のダウングレードが同じに見えてしまわないためです。
• **プラン**は、どのプランか、いつからか、いつ更新かを示し、更新がすでにリスクありと印を付けられていれば知らせます。
• **サポート履歴**は、過去の案件の件数、SLAを破った件数、この顧客自身の満足度、そしていま重大な案件が開いているかどうかを数えます。

ブロックの下には、この連絡先とのやり取りが、チャネルを問わず1本の流れで並びます。チャット、SMS、WhatsApp、メール、案件がすべて時系列で一緒になります。連絡先のレコードが見せるものと同じ履歴で、すでに話した内容を思い出すためだけに画面を移らずに済むよう、コンソールの中に持ち込んであります。

スーパーバイザー画面: 同じ現場を、まとめる人の視点で

コンソールは、対応する人に「次は何をするか」を答えます。スーパーバイザー画面が答えるのは別の問いで、相手も別の人です。いま現場は回っているか、という問いです。独立した画面で、壁のモニターに映しっぱなしにできるように作られており、自動で更新されます。

• **現場は回っているか。**キューごとの未処理件数、担当者のいない件数、こちらの返答を待っている件数、そして次の1時間で期限を破りそうな件数です。これから破りそうなものと、すでに破ったものは別物なので、パネルは両者を分けて示します。
• **誰が手いっぱいで、誰に余裕があるか。**人ごとの未処理件数をその人の上限と並べ、ローテーションを離れている人と、キューのリーダーを示します。
• **どこが詰まっているか。**待ち時間が最も長いキュー、最も多く流入しているチャネル、そして誰も取れないキューです。取れないのは、チームの誰も持っていないスキルを必要としているからです。
• **直近1時間に何があったか。**割り当ての記録はもともと追記のみなので、パネルはそれをそのまま表示します。

スーパーバイザー画面は管理する人のためのものです。これは意図したことです。各人の負荷と、ローテーションを離れている人が見えるからです。人を見張ることは、画面を開いた副作用ではなく、宣言されたマネジメントの行為です。パネルは読み取り専用なので、ここから再割り当ても優先度の変更もできません。指し示すだけで、作業はもともとの場所で行います。

サービスカタログ: 白紙の案件ではなく、並んだ品ぞろえを

社内で何かを頼みたい人は、いまのところ空の案件を開いて、覚えている内容を書きます。カタログはそれを品ぞろえの棚に置き換えます。頼めるものの一覧があり、各項目が自分の入力フォーム、キュー、優先度を持っています。申し込むと、記入済みの本物の案件が開きます。

1. 設定 → サービスカタログで、管理する人がカタログを組み立てます。カテゴリ、項目、そして各項目が尋ねる質問です。
2. 誰でも同じ画面を開き、サービスを選んでそのフォームに記入します。
3. システムは、その項目のキューに案件を作ります。項目の優先度が付き、回答は中に入ります。形式はポータルがすでに使っているものと同じです。
4. 項目に承認が必要な場合、チケットはすぐに作成され、未決の承認が解決をブロックします。誰かが判断するまで、誰もクローズできません。

• **項目を無効にしても、すでに申し込まれた分は取り消されません。**無効にするのは「これはもう頼まないでください」という意味で、「進行中のものを取り消す」ではありません。すでに開いている案件は、同じキューと同じ期限のまま続きます。
• **一度でも申し込まれた項目は削除できず、無効にするだけです。**削除すると、何が頼まれたのかについて履歴が嘘をつくことになります。
• **申し込みはフォームのスナップショットを固定します。**あとから質問を変えても、古い申し込みには、その人が実際に答えた質問が表示され続けます。
• **申し込みの状態はコピーではありません。**毎回、承認そのものから読み取るので、承認の仕組みが別の場所で下した判断とずれることはありません。

サービスカタログ: 申し込みへの対応

カタログの項目には対応計画を持たせられます。誰かがそのサービスを申し込んだあとに何をしなければならないか、そしてその順番です。各ステップは**本物のタスク**になります。担当者、期限、リマインダーが付き、それをやる人が毎日開くタスク一覧に並びます。ステップ同士の依存関係も、タスクがもともと持っているものと同じです。計画が申し込みに固定されるのは、対応が**始まった**ときであって、サービスが申し込まれたときではありません。あとから項目を編集しても、すでに動いている申し込みを書き換えることは決してなく、新しい版は次の開始から効きます。

仕事をまとめる人には対応キューがあります。何が残っていて、誰のところにあり、いつからそこにあるのかです。承認済みなのにまだ誰も開始していない申し込みは、経過時間を見せたまま**いちばん上**に来ます。承認は何も始めないからです。誰かが計画を動かさなければなりません。待つべき承認がない項目は、申し込まれたその場で始まります。

1. カタログの項目に計画を描きます。件名、タスクの種類、開始日から数えた期限の日数、誰が受け持つか、そして必要なら、そのステップが待つ前のステップです。
2. 誰かがサービスを申し込むと、案件はこれまでどおりに作成されます。項目に承認が必要なら、対応は判断を待ちます。待つべき承認がなければ、その場で始まります。
3. 対応を開始すると、計画が申し込みに固定され、依存関係の順にタスクが作られます。どれにも担当者と期限が付きます。
4. 案件の中の申し込みパネルには、各ステップ、いま誰のところにあるか、期限、そして完了済みの分が並びます。ステップは案件のタイムラインにも出ます。案件にひも付いた普通のタスクだからです。
5. サービスが本当に相手に届いたら「提供済み」を押します。必須のステップが開いたままなら、理由を見せたうえで止まります。必須ではないと印を付けたステップは、決して止めません。
6. 間違って押しましたか。メモを添えて提供を取り消します。これは新しい記録です。前の提供は履歴に残ったままで、何も消えません。

顧客の機器: 案件はこの一台のこと

案件は、売れた製品モデルだけでなく、顧客の**機器**、つまりシリアル番号を持つ設置済みの一台を指せるようになりました。案件では顧客の設置ベースから選び、シリアル番号で探します。電話口で顧客が名乗るのがその番号だからです。ひも付けられるのはその案件の顧客が持つ機器だけで、そこから先は機器そのものの履歴がサポートの経緯を語ります。ひも付けた案件、外した案件、解決した案件が、設置、移設、保守と同じタイムラインに並びます。

停止は**人**が記録します。案件から記録することもできます。ここにはテレメトリーも機械からの信号もありません。ですから稼働率、MTTR、MTBF は、記録する人の几帳面さのぶんだけの価値しかありません。画面は数字を飾らずに、そのことをはっきり言います。

• 保証と契約: 保証のバッジ（保証期間内、まもなく終了、期限切れ）と保守契約が、顧客に口を開く前から見えています。
• 設置場所: 機器を動かすと、どこへ行ったかが記録されます。ですから場所の履歴はその移動の読み取りであって、過去を忘れる単独の項目ではありません。
• 系譜つきの交換: 交換すると古い一台が引退し、新しい一台が取引先、契約、設置場所を引き継いで生まれます。両側にそれぞれ相手を指すイベントが残ります。
• ライフサイクル: 稼働中、保守中、RMA 中、引退、除却。除却したものは戻りません。除却は会計上の事実だからです。戻る道は、古い一台の系譜を持たせて新しい機器を登録することです。
• 停止: 計画停止でも突発停止でも、開始と終了を記録します。同じ機器が同時に二重に停止することはなく、重なった停止は合計する前にひとつにまとめられます。ですから稼働率が負になることはありません。
• 稼働率: 期間中の百分率を、計画分と計画外分に分けて示します。顧客と合意した保守枠は、破られた約束ではないからです。標本が足りなければ MTTR と MTBF は空のままです。
• リスクと次の一手: 重要度、経過年数、繰り返す故障、契約の有無、実測の稼働率を合わせて、説明できるスコアにします。データが足りずに置いた仮定は、そのまま書き出します。

ナレッジベース: 責任者、見直し、閲覧

ナレッジベースに、どの記事を誰が引き受けているのか、そしてまだ信用してよいのかに答える層が入りました。責任者、レビュー担当、日数で決める見直しの周期、そしてそこから出てくる**見直しが期限切れ**の記事です。ガバナンスの一覧は生きた計算で、開いたその場で求めます。ですから夜間処理が走ったかどうかに左右されることがありません。問われるのは公開済みの記事だけです。下書きはまだ書いている途中で、アーカイブ済みは流通から外れています。

公開しているかどうかだけが可視性ではなくなりました。記事ごとに読み手を決めます。**社外**はヘルプセンターとポータルがリンクを持つ人に見せるもので、**社内**は CRM の外へ出ません。すべての記事は社外として生まれます。以前とまったく同じふるまいなので、あなたが決めるまで何も変わりません。

• 責任者とレビュー担当はあなたのチームの人で、記事ごとに決めます。責任者がいない記事は一覧で印が付きます。その穴はそこで埋めます。
• 見直しの周期は日数です。次の見直しは、前回の見直しに周期を足した日です。周期のない記事は期限が来ることがなく、誰も催促されません。
• 見直し期限切れの通知は、記事の**責任者**に、期限ごとに一度だけ届きます。責任者のいない記事は誰にも通知しません。持ち主のいない半分を毎日管理者のベルに流し込むのは、ベルを無視する習慣を教えることだからです。
• アーカイブは、誰かが状態の項目をこっそり書き換えるのではなく、実行者と日時と監査証跡を残して記事を流通から外します。アーカイブから戻すと下書きに戻り、そのまま公開に戻ることはありません。
• 解決済みの案件から書く AI の下書き: クローズした案件を5件まで選び、必要なら埋めたい穴を指し示すと、アシスタントが使い回せる記事を1本書きます。それは**必ず下書きとして生まれ**、手で書いた記事とまったく同じ見直しの列に並びます。AI が提案し、人が承認します。使うのは解決済みの案件だけです。開いたままの案件には、まだ答えがないからです。
• 記事ごとの閲覧: どの記事を何回の訪問が開いたか、どの入り口から来たか、そして期間中に誰も読まなかった公開済みの記事はどれか。それが働いていないぶんのナレッジベースです。

セルフサービス: アシスタントとデフレクション率

公開しているナレッジベースにアシスタントが付きました。答えるときは、あなたが公開した記事**だけ**を根拠にし、使った出典も示します。生成された答えを読む人が、どこから出たのかを確かめられるようにするためです。何も見つからないときは見つからないと言い、案件の作成フォームへ案内します。そして答えの出なかった質問は、記事の穴として記録されます。作り話の手順で沈黙を埋めることはありません。AI が設定されていないときは、故障したふりをせずに、見つかった記事を並べます。

デフレクションが測れるようになるのはそのおかげで、定義はわざと厳しくしてあります。**避けられた案件とは明示的な表明**です。案件を作りに行く途中だった人が、答えか提案された記事を受け取り、これで解決したとクリックして、作成をやめた場合だけを指します。それ以外は数えません。

• 記事を読んだだけでは数えません。読んでいる人は、比べているのかもしれないし、調べているだけかもしれないし、どのみち案件を作りに行く途中で見当違いの記事を開いているのかもしれません。
• 結末のない検索は数えません。タブを閉じたことは成功ではありません。
• 案件は表明に勝ちます。解決したと言った人が同じ訪問の中で案件を作ったなら、その訪問は案件として数えます。少なめに測るほうを選びます。
• 何も決めなかった訪問は、分子にも分母にも入らず、率からまるごと外れます。未決として別に報告します。
• 率は、**何かを決めた**訪問のうち、案件を作らないと決めた割合です。その期間に決めた訪問が1件もなければ、率は空になり、決して0%にはなりません。分からないことと0パーセントは、別の答えだからです。
• ファネル（検索、質問、答えの出た質問）が測るのは届いた範囲であって、結果ではありません。そのどれも率には入りません。

サポート分析: すぐ使えるレポート、気づき、予測

チケットコンソールの「分析」タブは、これまでどの画面も答えなかったことに答えます。キューがどれだけ滞っているか、約束した節目をどれだけ守れたか、どれだけエスカレーションしたか、音声・ボット・メッセージングが何をしてきたか、インシデントが案件としてどれだけの負担になったか、件数がどこへ向かっているか、そして最後に、それに対して何をすべきかです。どの数字もサーバーで計算済みのまま届くので、同じ数について2つの画面が黙って食い違うことはありません。

似ていて別物の、2つの読み取りがあります。**経過時間は時計で進み**（案件が作成されてからのカレンダー上の時間）、**期限は営業時間で進みます**（SLA の約束で、一時停止は差し引きます）。名前をわざと分けてあります。混ぜてしまえば、同じ見出しの数字が2つできて、どちらが破られたのか分からなくなります。

• すぐ使えるレポート: ひとクリックで、ひな型があなた自身のレポートになります。名前もあなたの言語で付きます。そこから先は普通のレポートで、ほかと同じように編集、共有、書き出し、定期配信ができます。裏に別の仕組みはありません。
• 気づき: SLA が目標を下回る、入ってくる数が出ていく数を上回る、キューが古びる、再オープン、エスカレーション、ナレッジの穴。どれにも裏づけの数字、考えられる原因、打つ手が付き、重い順に並びます。
• 節目ごとの達成: 初回応答、次の応答、解決の3つで、解決だけではありません。次の応答とは、一度答えたあとに顧客がまた書いてくるたびのことです。数に入るのは、実際に目標が設定されていた案件だけです。
• 未対応キューの古さを帯で見ます（1日未満、1〜3日、3〜7日、1週間超）。全体、キュー別、担当者別で、いちばん古い案件が目に入ります。
• ボットの結末は2つではなく3つです。人を介さず完了、人へ引き継ぎ、そして**人を求めたのに誰も入らなかった**。これは放置されたキューで、以前は完了の数字の中に隠れていました。
• 音声、メッセージング、インシデントには、それぞれ別の読み取りがあります。WhatsApp の会話は案件ではありませんし、インシデントは案件としていくらかかったかと、繰り返し戻ってくる根本原因で測るものだからです。
• 件数の予測: 傾向に曜日ごとの指数を重ねます。土曜日を火曜日のように見積もらないためです。

方針のもとでチケットに働きかけるAI

AIはすでにすべてのチケットを読んでいました(カテゴリ、緊急度、感情、要約)。しかし誰もそれを使っていませんでした。いまではチケットにカテゴリと優先度を**書き込める**ようになりましたが、ワークスペースが定める方針のもとでのみ動き、**既定では無効**です。管理する人が**設定 → サポートAI**で有効にするまで、何も変わりません。項目ごとに、**何もしない**、**提案する(人が確認する)**、**確信があれば書き込む**から選びます。書き込みが起きるのは、あなたが決めた信頼度のしきい値(50%から100%、既定は80%)を上回ったときだけです。それを下回ると、同じ提案はワンクリックで適用できる提案に変わります。

コンソールの**AIの提案**ボックスには、待っているものが並びます。提案された値と、その信頼度、書き込まれなかった理由(方針が提案のみ、しきい値未満、人がすでに値を選んでいた、1日の上限に到達)で、**適用**と**却下**が付きます。方針が自分で書き込んだものは、ボックスの履歴に「方針による書き込み」として残るので、担当者はそのカテゴリを自分が付けたのではないと分かります。**今すぐAIで分類**は、同じ方針を手動で実行します。方針を有効にしておらず、提案も1件もないワークスペースでは、このボックスは表示されません。

• AIは**あなた自身の**カテゴリと優先度のリストに照らして分類します。あなたの選択肢にない値が書き込まれることはなく、選択肢が登録されていない項目では、勝手に作り出す代わりに黙っています。
• 人が選んだ値は上書きされません。既定では、自動モードが埋めるのは空欄か、フォームの初期値のままの項目だけです。人の選択を置き換えるには、**人が選んだ値をAIが置き換えることを許可する**という明示的なオプションが必要です。
• 返信の下書きは**決して送信されません**。下書きを受け入れると、**作成欄で使う**で作成欄に入ります。見直し、編集、送信はあなたの手に残ります。チケットの解決とクローズも決して自動ではありません。そのためのモードはどこにも存在しません。
• 自動の書き込みはすべて、エージェントと共有する1日の操作上限にカウントされます(**設定 → AI**、エージェントの自律性)。上限に達すると、AIは提案のみに戻り、ボックスと方針のページでそのことを伝えます。あわせて今日の数字も示します。書き込み済み、提案済み、上限で保留、人待ちの件数です。
• すべてが記録に残ります。自動の書き込みはエージェントの操作台帳に、AIの呼び出しはAI監査ログが有効なときにそのログに、そして方針の変更そのものは監査証跡に記録されます。
• **チケット作成時に実行**は、自動化を何も設定せずに方針を適用します。これを有効にすると、画面からチケットを作成したとき、チケットが表示される前に数秒間AIを待ちます。AIが利用できない場合(キーなし、支出上限、プロバイダー停止)でも、チケットは何も書き込まれないまま、そのまま作成されます。
• チケットの自動化と時間ルールに、2つのアクションが加わりました。**AIで分類(サポートAI方針に従う)**と**AIで返信を下書き(送信はしない)**です。先にカテゴリを設定してからAIに問い合わせるルールで、AIがそれを元に戻すことはありません。
• 同じテキストに対する同じ分析が2つの提案を生むことはなく、上限に二重にカウントされることもありません。実行を繰り返しても何も消費しません。

チケットから始めるフィールド作業

訪問が必要なチケットを、別の画面で打ち直す必要はもうありません。フィールドサービスの業種別機能を有効にすると、コンソールの**フィールド作業**ボックスからチケット直結でジョブを開き、訪問を予定し、顧客が電話で尋ねることを担当者に見せます。次の訪問、それが遅れているか、前回の訪問、技術者、機器です。すべてジョブ、その訪問、ステータス履歴からリアルタイムに読み取るので、配車ボードで加えた変更が、次にチケットを開いたときに表示される内容そのものです。ジョブにはチケットの件名と説明が問題として引き継がれ、チケットの優先度はジョブの優先度に対応づけられます(重大は緊急に、高は高のまま、中は通常に、低は低に)。

**ジョブを開く**では**物件**を尋ねます。チケットは訪問先の住所を知らないため、物件は必須です。顧客の物件が先頭に印つきで並び、物件が1件だけの顧客ではそれがあらかじめ選ばれ、取引先担当者も会社もないチケットでは、名前、住所、郵便番号で全件から検索します(先頭50件を表示し、絞り込みを促す注記つき)。チケットが指す資産のシリアル番号が、その物件の機器のちょうど1台と一致するときは、その機器がチェックボックスつきで**提案**されます。勝手に選ばれることはありません。ジョブの種類(既定は修理)、技術者、到着時間帯は任意です。時間帯を指定すると、最初の訪問がすぐに予定され、配車ボードに表示されます。指定しなければ、ジョブは訪問のない下書きのままです。

• **訪問を予定**は、コンソールから同じジョブに訪問を追加します。再訪は訪問2、訪問3と続き、2件目のジョブにはなりません。1つのチケットが持てるジョブは最大1件で、「開く」をもう一度クリックすると、すでに存在すると返ってきます。
• ジョブ自体の到着時間帯と技術者は、空だったときにだけ埋められます。2回目の訪問が、1回目で合意した内容を書き換えることはありません。
• **訪問が遅延**は、時間帯が始まったのに訪問がまだ予定のままのとき、つまり誰も出発していないときに表示されます。ステータス変更のセレクターに出るのは、業種別機能のステートマシンが現在のステータスから受け付ける遷移だけです。
• フィールド作業が**完了**、**完了できず**、または**キャンセル**になると、チケットの担当者に、その人の言語でコンソールへのリンクつきの通知が届きます。変更がコンソールから来ても、業種別機能の画面から来ても、アプリから来ても同じです。配車済み、移動中、部品待ちはボックスに表示されるだけで、誰にも通知は鳴りません。
• フィールド作業が終わっても、**チケットのステータスが勝手に変わることはありません**。顧客に確認してチケットを解決するのは、対応する人の判断です。
• **リンク解除**は、チケットとジョブの結びつきを外すだけで、それ以外は何もしません。ジョブは業種別機能の中で、独自の記録とともに生き続けます。ジョブのキャンセルは業種別機能側の遷移であり、そちらで行います。
• 訪問日のリマインダータスクは任意で、活動モジュールを使い回します。チケットのタイムラインと技術者のタスク一覧に表示され、技術者がいないときはチケットの担当者のタスク一覧に表示されます。
• 業種別機能が無効のとき、ボックスは失敗するだけのボタンを見せる代わりに、そのことを伝えて**設定 · Verticals**を案内します。あわせて、どのワークスペースにもある軽い道筋として**代わりに作業指示書を開く**を提示し、作業指示書が存在するときは、その指示書と予約を表示します。

設定する場所: 定型文は「設定 → 定型文」、送信メールの文面は「設定 → チケットのメールテンプレート」、誰が何をできるかと各キューの必要条件は「設定 → スキル」です。スウォーム、フォローアップ、作業タブは設定不要で、すでにコンソールにあります。

この記事をシステム内で開く →