English
Tiếng Việt月曜にエアコンの故障を連絡したのに、木曜になっても誰からも返事がない。メッセージが数百件の中に埋もれてしまったからです。入居者やテナントが、Repair Ticketが処理されたかどうか分からず何度も問い合わせてくるなら、原因はたいてい、依頼に追跡番号がなく、責任者もはっきりしていないことです。
Repair Ticketとは、簡単に言えば、依頼をSalesforce Service CloudのCaseとして記録し、番号、担当者、ステータス、優先度、対応期限を持たせたものです。これにより、ビル管理側も連絡した本人も、依頼が今どこにあるかが分かります。
【ご注意】記事中のビル管理会社と優先度は説明用の仮定であり、業界標準でも実在のお客様の事例でもありません。具体的な対応期限は、各運営会社が決めるものです。Zalo（ベトナムのメッセージアプリ）は、通常の設定では標準で使えるチャネルではなく、別途の連携が必要です。機能はエディションやライセンスにも依存します。
すべての修理依頼を、番号と対応期限のあるチケットにする前と後。修理依頼が埋もれてしまう理由
ビル内の修理依頼は、複数の方向から同時に届きます。受付へのZaloのメッセージ、管理側へのメール、代表電話への連絡、警備員への口頭の伝言などです。チャネルごとに保管場所が別々で、後から検索できる番号を持つものはほとんどありません。
その結果、よくある3つの問題が起きます。連絡した人は受け付けられたか分からず、何度も問い合わせます。管理側は、どの依頼が期限を過ぎているか分かりません。報告が必要になっても、種類別や処理時間別に依頼を集計できる人がいません。
仮の例：オフィスビルの運営会社が、Zalo、メール、電話で依頼を受け付けているとします。週末、技術部門の責任者は、まだ終わっていない作業を1人ずつ確認して回らなければならず、そのリストは毎回違うものになります。
Repair Ticket：すべての依頼を1つのCaseにする
Service Cloudでは、すべての依頼がCaseとして記録されます。Caseは、顧客のために解決すべき1つの問題を追跡するレコードで、関連するメール、メモ、タスクも紐づきます。
Case番号
- 依頼ごとに固有のCase番号が付き、連絡した本人と担当者の双方が検索できる
- 問い合わせの際は、番号を伝えるだけでよい
担当者とステータス
- 各Caseには Owner がいる（個人または Queue）
- New、In Progress、Waiting for Reply、Closedなどの Status で進捗が分かる
優先度
- 各Caseに Priority を付け、担当者が何から対応すべきか分かるようにする
- Priority は、対応期限を決める基準になる
対応期限
- 優先度ごとに、運営会社が決めた期限を紐づける
- Caseの期限が近い、または過ぎているときに、システムが警告を出せる
複数のチャネルから依頼を受け、適切な担当に振り分ける
チケットが「誰かが入力し忘れないこと」に依存しないよう、Service Cloudは複数の入口からCaseを自動作成できます。
メール、Webフォーム、ポータル
- Email-to-Caseは、サポート用アドレスに届いたメールをCaseにする
- Web-to-Caseは、Webサイトのフォームに入力があったときにCaseを作成する
- ポータル（Experience Cloud）では、入居者やテナントが依頼を送信し、進捗を確認できる
Zalo：別途の連携が必要
- Zaloは、通常の設定では標準で使えるチャネルではない
- ZaloからCaseを作成するには別途の連携が必要なため、導入パートナーと現時点の選択肢を相談する
- 連携ができるまでは、Webフォームやメールでチケットを作成するよう案内できる
Omni-Channelで振り分ける
- Omni-Channelは、ルーティング設定、稼働状況、作業量に基づいて、適切な担当者にCaseを割り当てる
- 仮の例：電気系の不具合は電気担当チーム、水まわりは給排水チームへ
4段階の優先度と対応期限：参考例
以下は、ビル運営会社向けの4段階の優先度のサンプルです。ビルごとに特性やサービス上の約束が異なるため、段階の数、名称、期限は自由に変えてください。
| Priority（優先度） | 事例 | 対応の目安 |
|---|---|---|
| Urgent | エレベーターへの閉じ込め、漏電 | 当番担当者にすぐ連絡し、直ちに対応。期限は最も短く設定 |
| High | 一区画の断水 | シフト内に担当を割り当て、進捗をこまめに更新 |
| Medium | エアコンが効かない | 受付順に日程を調整し、日程が決まったら連絡 |
| Low | ご意見・ご提案 | 記録し、あらかじめ決めた周期で返信 |
この表では、あえて具体的な時間や日数を示していません。各段階の期限は、運営会社が人員、テナントとの契約、リスクの大きさに基づいて決めるものです。
期限と警告。システムに期限を追跡させるには、Service CloudのEntitlementsとMilestonesを使います。Entitlementは、顧客が受けられるサポートのレベルを表し、Milestonesは、初回の返信や対応完了など、守るべき時間の目標です。Milestoneの期限が近い、または過ぎているときは、システムがアラートを出したり、escalation ruleでCaseを上位に引き上げたりできます。
緊急のトラブルについて：チケットは安全手順の代わりにはなりません。人の閉じ込めや漏電は、チケットとは別に、すぐに当番チームや緊急連絡先へ電話する必要があります。チケットは記録と追跡のためのものです。
自社の運営に取り入れる際の注意点
優先度は少ない段階から始める。段階が多すぎると、担当者が選びにくくなり、優先度の意味も薄れます。各段階の期限をまず運営チームと決めてから、設定しましょう。
EntitlementはすべてのCaseに自動では付かない。ガイド資料によると、Entitlementはweb-to-caseで作成されたCaseには自動で適用されません。最初から、各Caseにサポートレベルをどう付けるかを設計しておきましょう。
Caseをはっきり分類する。Record Typeを使って、修理依頼とご意見を分けると、それぞれ専用の画面とプロセスを持てます。方法はSalesforce Record Types: Start With 2 for a Cleaner Screen（英語）で説明しています。
運用が安定したら。Caseコメントを書くAIツールについては、エディションとライセンスによりますが、Salesforce Winter 27: 5 Easy-to-Grasp Changes That Matter（英語）をご覧ください。SalesforceのAIにできることの全体像は、Einstein AI in Salesforce: What Can AI Actually Do for Your Sales & Marketing Team?（英語）が参考になります。
測定する。数週間後に、種類別、処理時間別のCase数のレポートを見て、ボトルネックがどこにあるかを確認しましょう。
チケットの仕組みを作る前のチェックリスト
設定を始める前に、次の短いリストで、チケットが自社の運営の実態に合っているか確認しましょう。
☐ 現在の依頼チャネル（Zalo、メール、電話、対面）を洗い出した
☐ Caseを自動作成するチャネル（メール、Webフォーム、ポータル）を選んだ
☐ Zaloから依頼を受けたい場合の連携方法を相談した
☐ 優先度の段階数と、各段階の事例を決めた
☐ 各段階の期限を運営チームと決めた
☐ 振り分けと、期限が近いCaseへの警告を設定した
☐ 緊急トラブルには、チケットと並行して直接電話する手順を用意した
依頼は、番号で追跡していますか？それとも記憶ですか？下のコメント欄でぜひ教えてください。Sonixチームがお待ちしています。
Salesforce Service Cloud
カスタマーエクスペリエンス
デジタルトランスフォーメーション
中小企業
ハウツー
Smart Building
ビル管理
Sonixにご相談ください。依頼の受け付け方法を一緒に見直し、貴社の運営に合ったチケットと優先度を設計します。
Sonix: Your success is our happiness.
コメントを残す