Zendesk で Slack に個人メンションをする方法
これは株式会社SUPER STUDIO Advent Calendar 2022の20日目の記事です。
というか、Advent Calendar に参加するために zenn.dev に登録しました。
自己紹介などはおいおい（気が向けば）
はじめに
弊社ではご契約クライアント様向けのサポート窓口として以下を設けています。
- 電話
- メール（直接メールで受けたり、FAQサイトのお問い合わせフォームからの登録もメールに含んでいます）
（その他例外もあります）
2022年12月現在[1]、電話・メールのお問い合わせについては管理をZendesk(Support) で一元化しています。製品のサポート（FAQ）サイトを4つ運用していることもあり、プランは Suite Enterprise を利用しています。
以降、本記事での「Zendesk」の記載については「Zendesk Support」を示します。
Zendesk の基本機能の通知
メール
Zendeskはあらゆる通知をトリガで設定する仕様で、メール送信に関しても例外ではありません。
- お問い合わせを受け付けました
- 返信の送信
- 返信がありました（のチケット担当者への通知）
設定方法は公式のドキュメントや、その他これまでに導入された方の記事（最初にこれだけはやれ的なもの）をご確認ください。
弊社の場合、社内のコミュニケーションチャネルが Slackであり、チケット担当者への通知がメールで届くのは「（私が）絶対に見落とす自信があった」ので、当時フロー設計をしていた私の個人的判断[2]で実施していません。
サイドカンバセーション
Professional 以上だとデフォルトでついてくる機能です。（昔は有償オプションでした）
チケットから派生してSlack・メール・子チケットを作成し、その中での会話は元チケットから参照できますという、使い方によっては便利な機能。
Slackの@メンションはサポートされていませんが、現在ログインしている全員に通知する@hereや、チャンネルの全メンバーに警告する@channelを使用することはできます。
と明記されていますが、<@SlackのUserID>で個人メンションを送ったり、<!subteam^UserGroupID> でグループメンションを送ることは事実上可能です。調べるのがめんどくさいですが。
Webhookへ通知
メールと同様にトリガで設定します。
詳細の設定方法を書くと長くなるのと、参考になる記事が多く私が書くまでもないので、いくつかの記事の紹介にとどめます。が、ここでも以下の制限がありますが、<@SlackのUserID>や<!subteam^UserGroupID>の利用は可能です。
Slackの@メンションはサポートされていませんが、現在ログインしている全員に通知する@hereや、チャンネルの全メンバーに警告する@channelを使用することはできます。
参考記事
メンション先を動的に変えるには
各種通知が「通知先チャネルの全体に届く」のをよしとするならば、上記で十分です。
が、弊社の場合、以下の理由もありメンション先を絞りたいと考えました。
- 週に起票されるチケットが多いため、それではサポート担当者の通知が溢れてしまい、結果「通知を見ない」もしくは「通知が多すぎて嫌になる」の不幸な結果になりかねないこと
- 常にZendeskにログインしてサポートをメイン業務としている担当者の他に、お問い合わせ内容に応じて回答する担当者がいること（人によっては常にZendeskにログインしているわけではない）
お客様をお待たせする時間をできるだけ短くするため、チケット担当者への通知が悩みの種でしたが、そもそもの問題としては「Zendeskを利用しているサポート担当者（エージェント）のアカウントと Slackアカウントを連携する機能がない」でした[3]
エージェントのSlack User IDを登録すればいいんじゃね？
思いつけば大したことのないことなのですが、弊社では「ユーザーフィールド」に Slack User ID のカスタムフィールドを追加することでやりたいことを実現できました。
管理センターの「メンバー > 設定 > ユーザーフィールド」にタイプ：テキストの Slack User ID 用を追加します。
kana はお名前の読みが難しいクライアントご担当者様用に準備しています。
slack_user_id のカスタムフィールドはこんな感じ
エージェントのみなさんにはちょっとご面倒なのですが、ご自身のSlack User IDの登録をお願いしてます。（自分の設定だったら、Zendesk管理画面内の右上のアイコン→プロフィールを表示 から変更可能です）
以下、実例です。
トリガ設定例：チケット再オープンの通知
AnswerBot を利用しているのですが、AnswerBotで解決済で一度クローズしたチケットが「やっぱ違う、と再オープンされることがあるので、その場合は通知しないようにしています
JSONボディの中身は以下です。ちょっとした分岐を書いていますが、Liquid Template language が採用されてます[4]。
{
"attachments": [
{
"fallback": "担当者:{{ticket.assignee.name}} #{{ticket.id}}",
"color": {% if ticket.priority == '高' or ticket.priority == '緊急' %}"warning"{% else %}"good"{% endif %},
"title": "#{{ticket.id}} - {{ticket.title}}",
"title_link": "{{ticket.link}}",
"fields": [
{
"title": "From",
"value": "{{ticket.organization.name}} {{ticket.requester.name}}様",
"short": true
},
{
"title": "To",
"value": "{{ticket.group.name}} {% if ticket.assignee.custom_fields.slack_user_id %}<@{{ticket.assignee.custom_fields.slack_user_id}}>{% else %}{{ ticket.assignee.name }}{% endif %}",
"short": true
},
{"value": "チケットに返信がきました。（現在の優先度: {{ticket.priority}})"}
],
"footer": "トリガ: チケット再オープン通知（Slackへ）"
}
],
"username": "Zendesk通知(チケット再オープン)",
}
サポート担当者さんに「Slack IDを登録してね」とお願いしている関係で、最初は登録漏れをすることがあります。ということで、一応Slack IDが入っていない場合は、担当者のお名前をそのまま書く（メンションしない）ということで、トラブル回避しています。
{% if ticket.assignee.custom_fields.slack_user_id %}
<@{{ticket.assignee.custom_fields.slack_user_id}}>
{% else %}
{{ ticket.assignee.name }}
{% endif %}
また、優先度で通知された際の見た目が変わるようにしています。
優先度：通常以下
優先度：高以上
サイドカンバセーション設定例（ほぼ動的ではない）
弊社はお問い合わせへ回答を送信する前に、基本的に上位スタッフの確認・承認を得る運用を実施しています（この運用方法については別記事にまとめる予定）
担当者ごとによく通知する個人については <@SlackUserID> の値を辞書登録していたりするようですが、サイドカンバセーション起動用のマクロを組むことにより、定型文内にメンション先候補を出しておく（不要な人は削る）という運用をしているグループもあります。
※この辺の運用はチーム規模によって若干の差異があります。
<@SlackのUserIDをそのまま書く> ○○さん
<@SlackのUserIDをそのまま書く> ××さん
<\!subteam^SlackのGroupIDをそのまま> <- グループメンション用 < の後の \ を消してください
---- ここまで要編集。メンション飛ばす人だけ残す。<>内のみでOK ----
お疲れさまです。承認をお願いします。
承認の希望期限：
リクエスタ：{{ticket.organization.name}} {{ticket.requester.name}} 様
件名: {{ticket.title}}
承認依頼者: <@{{current_user.custom_fields.slack_user_id}}>
本来、マクロに記載するグループメンションは <!subteam^GroupID> なのですが、この形式で定型文登録するとマクロ起動時にグループメンション用の定型文が消えてしまうので（これ、いろいろ試したけど回避できませんでした）、苦肉の策で <\!subteam^GroupID> を定型文登録し、グループメンションしたい人は \ を削除するという大変泥臭い運用で回避しています。
おわりに
Zendesk で運用してきた3年弱の期間で、弊社内での体制も変わり、運用に関しては（若干泥臭いながらも）工夫をしてきました。
もし同様の悩みを持っていらっしゃる方の参考になれば幸いです。
これがあったらいいな
Zendesk はチケットに連携できる「ユーザ」は
- リクエスタ（問い合わせ者）
- 担当者（回答の担当者）
- （弊社はほぼ使っていないですが）Cc
ですが、チケットのカスタムフィールドで別のユーザ属性（弊社の場合だと承認担当者）が設定できればもっと便利になるのに……と思いながら、上記運用で乗り切ってきました。
カスタムフィールドで assignee とは別のエージェントを追加できるようになったら、この悩みからは解放されそうです。（Slack ともっと密に連携してほしいなーとも思いますが）
Discussion