メールチケットシステムの仕組みと壊れる場所

メールチケットシステムが実際にやっていること

マーケティングを剥ぎ取ると、結局は3つの仕事に集約されます。受信メッセージをレコードに変換すること、それ以降のメッセージをすべて同じレコードに紐づけ続けること、そしてチームが互いの邪魔をせずに作業できるだけの構造を与えることです。

どのベンダーも、何も設定しないうちから動作する受信箱を用意してくれます。これが最初の10分をだまされたように簡単に感じさせる部分です。Freshdeskはsupport@yourcompany.freshdesk.comという形のアドレスを渡してくれ、そのsupport email docsによれば、"any emails you receive on this address are automatically converted to tickets with the customer as the requester."とあります。Jira Service Managementも自分のAtlassianサイト上でほぼ同じことをします。プレフィックスを選ぶとsupport@companyname.atlassian.netが得られ、これはAtlassianの説明によれば、事前設定済みで、すぐに顧客へ送信できる状態だとされています。

しかし、あなたの本当のアドレスはそれらとは何も接続されていません。転送設定するか、IMAPで接続する必要があり、実際の作業はそこから始まります。

その見返りに得られる構造こそが、すべての目的です。担当者、ステータス、期限のカウントダウン。この語彙を一箇所にまとめて知りたいなら、help desk systemガイドで扱っており、ticketing system examplesでは実際に埋まったキューがどんなふうに見えるかを紹介しています。

誰もデモしない部分: 返信がどうやってチケットを見つけるか

これはおそらく、メールチケット処理に関するサポート運用側の最も一般的な不満で、実際にそれを体験している人によって描写されています。

"Customer A emails in with a service request, including helpdesk, coworker B, and contact C. Ticket email is sent to Customer A. Contact C replies all to initial email and after a few replies I've got half a dozen tickets."

CarnivorousDecapod, r/ConnectWise, Reddit

これはメールがメールとして当然すること、というわけではありません。設計上の選択であり、同じスレッドがそれを正確に言い当てています。

"CW Manage's email connector creates duplicate tickets because it cannot track by Message-ID and Related-To email headers that the emails are part of the same conversation. This is something Autotask and others have solved many years ago"

msprm, r/ConnectWise, Reddit

つまり、ツールを評価する際の本当の問いは「スレッド処理をするか」ではありません。何を基準にスレッド処理をするのかです。Freshdeskは受信メールごとに3つのメールマーカーを確認し、いずれかが一致すれば返信またはノートを追加します。だからこそ、転送されたメールが新規チケットではなく古いチケットへのノートとして終わることがあります。Atlassianは重複症状の自社バージョンを、パース処理ではなく権限のせいだとしています。返信が新しい作業項目を開き続ける場合、"it usually means that the person who sent the email message couldn't be added as a request participant"とされています。

件名のトークンについては、ここで独自の注意が必要です。チームはそれを支柱となる部分のように扱いがちですが、実際には最も脆い部分だからです。

"Usually the issue is someone modifying the subject line and removing any of the tokens CW looks for to attach to the proper ticket, or replying to the initial email starting the ticket, where absolutely no token would be present in the subject line."

Fitzzz, r/ConnectWise, Reddit

ここで明確に言っておく価値があります。主要ベンダーのどれも、スレッド処理が機能するためにその番号を要求してはいません。それは人間側の慣習で、主にエージェントを助けるものであり、返信からそれを隠しても何も壊れません。スレッド処理がしっかりしていれば、残りのキュー衛生はおなじみのもの、ticket tagsとmacros、そしてpersonal macro should be sharedのタイミングを知ることです。

各システムがハードリミットとして公開しているもの

ベンダーは実際の制約をヘルプドキュメントの奥深くに埋め込みがちなので、数字を一箇所にまとめました。システムを選んで、最初に自分を苦しめそうな行を読んでください。

正直なところ、契約書に判を押す前にホワイトボードに書いておきたい行が2つあります。Jiraの必須フィールドのルールがより厳しい方です。Atlassianは、メール用のリクエストタイプは"must have both Summary and Description fields visible, and any other visible fields must be optional"と述べており、追加の必須フィールドがその上に加えられると、"work items won't be created in your space from customer emails."となります。ある平凡な火曜日にフォームを整理していた管理者が、誰にも見えるエラーなしで、メールチャネル全体を停止させてしまうことがあり得ます。

もう一つはFreshdeskの受信箱数です。ドキュメントによれば: "You can add multiple support emails from the Growth plan. However, if you are on the Freshdesk Free program, you can add only one email." つまり、support@、billing@、returns@をグループごとに分けたいチームは、その定義上、有料プランに乗ることになります。無料プランを予算に組み込む前に知っておく価値があります。Freshdesk ticketing systemガイドには、こうしたルートの設定方法についてさらに詳しく書いています。

メールチケット処理はDNSプロジェクトである

これはサポートマネージャーが不意打ちを食らう部分で、彼らはただソフトウェアを買っているだけだと思っていたはずです。自社から来たように見える返信が1件送られる前に、DNSアクセス権を持つ誰かがまず作業をしなければなりません。

Zendeskは1つのSPFレコード、v=spf1 include:mail.zendesk.com -allを求め、"the SPF specification requires that you only have one SPF record on your domain"と警告しています。そのため、Google Workspaceを使っているところは単に追加するのではなく既存のものと統合する必要があります。DKIMはZendesk自身のドメインキーを指す2つのCNAMEで、これは実はよくできた設計です。Zendeskはこれらのキーを四半期ごとにローテーションしており、その後はDNSを二度と触る必要がありません。ただし、その代償としてカスタムキーには対応していないため、Zendesk側のレコードに問題が起きた場合は、Zendeskが修正するのを待つしかありません。

ここでの順序ルールこそが本当の落とし穴です。Zendeskはかなりはっきりとこう述べています。"Enabling digital signatures must be the final step in the configuration process. Enabling this feature before adding the CNAME records for your domain will cause delivery failures." 3回クリックすれば、自ら招いた障害の完成です。

DNS作業を完全にスキップしても、何かが大きな音を立てて壊れるわけではありませんが、見た目がどんどんおかしくなっていきます。Zendeskは実際に誰がこれを必要とするかについて、爽快なほど率直で、その短い答えはほとんど誰も必要としないというものです。"Only if you really don't want your customers to see the Zendesk name on their messages." チームには、プロダクト内でも対応する警告が表示されます。

SPF側には、ほとんど誰も想定していない罠があり、それはHacker Newsで最もよく説明されています。

"That limit of ten is extremely easy to meet when someone casually says "Hey we've started using Freshdesk for ticket tracking, setup DNS please". Ok so you include:email.freshdesk.com. That record itself includes four other freshemail.io DNS lookups, and sendgrid.net, which includes another one. So you're seven DNS lookups in just for that."

technion, Hacker News

SPFは合計で10回のDNSルックアップに制限をかけます。すでにGoogle Workspaceを載せているドメインにヘルプデスクを追加すると、簡単にその制限を超えてしまう可能性があり、その時点でヘルプデスク部分だけでなくドメイン全体の認証が壊れます。追加する前に確認してください。後ではなく。

メールが静かに死ぬ場所

どのシステムも、受信メッセージが何にもならずに消えてしまう理由のリストを保持しています。それらのリストを読むことは、購入前にできる最も近いストレステストと言えます。

Atlassianのメールプロセッサはヘッダーでフィルタリングし、auto-generated、auto-replied、auto-notifiedのいずれかが付いたものを破棄し、加えてメールサーバーが一括送信や配信状況通知としてフラグ付けしたもの、そしてJira自身のメールも破棄します。25MBを超える場合、結果はチャネルによって分岐します。そうしたメールは"remain unread in the mailbox or bounce back to the sender"となり、どちらが起きるかはそのアドレスが自分のものかAtlassianのものかによって決まります。自分の受信箱では、それはチケットなし、バウンスなし、誰にも一切の通知なしを意味します。

Freshdeskにも独自のリストがあります。送信者がブロック済み連絡先である場合、転送設定後にそのアドレスが削除された場合、宛先数が50を超えた場合、あるいはワイルドカード作成が無効でメールがプラスアドレスに届いた場合は、チケットは作成されません。そしてカウントされるのはプライマリフォルダに入っているメールだけです。"Only the emails received in primary folder of your support mailbox will be converted as tickets." つまり、ベンダーからのメールをラベルに振り分けるだけの整理されたGmailフィルターが、それだけでヘルプデスクから見えなくしてしまうということです。

Zendeskのバージョンは実際、最も静かなものです。受信側のサーバーがあなたをブロックした場合、"You may not receive a bounce-back notification in your Suspended tickets view." 何も表面化しません。だからこそ、私たちはAIを本番のキューに載せるとき、キューが完全だと信じるのではなく、まず過去のチケットをシミュレーションで再生することから始めます。実際に見えるticket backlogは、めったに全体像ではありません。

監視の習慣がSLA clockを見張ることであって、取り込みログではない場合、これらの失敗はどれもあなたに知らせてくることは決してありません、本当に。

自動応答戦争は実在する、そして愚かである

2つのチケットシステムが互いに会話している、それはサポート運用における最も高価なコメディの一つです。

"Customer emails us and they get our auto response, which triggers an auto response from their system, which triggers the pre-First Time Response response from ours, which triggers a new ticket from them since the pre-First Time Response response doesn't pull the ticket number from their system's subject line, which in turn triggers another response from this, all the while we're getting spammed with update emails and the case log is bogged down with non-sense."

csydas, Hacker News

これが終わらない理由は、まさにその文の真ん中にあります。それぞれの側の自動返信が、もう一方の側のトークンを落としてしまうのです。そして通常の防御策はここでは機能しません。チケット作成完了の通知は技術的には自動返信ではないからです。あるシステム管理者が最終的に行った修正は、件名そのものでマッチングし、すでにそれを持っている未対応のチケットにコメントとして追加するというものでした。こちらで説明されています。

少なくとも、ベンダー側も今ではこれに対する防御を用意しています。Freshdeskは送信元と宛先のアドレスが一致する場合、単純にチケット作成を拒否します。これがドキュメント化されたループ防止機構です。Jiraは別のJiraチャネルから来たように見えるメールを拒否し、"a never-ending loop of emails"を防ぎ、同じアドレスが流入を続けるとPotential mail loopステータスを表示し、独自に設定可能なループ検出のしきい値も持っています。有用ですが、部分的にすぎません。実際に人々が遭遇するループは2つの異なるベンダー間で発生し、どちらも相手側を見ることができないからです。

それが発生したときに実際にかかるコストについて、あるMSPの声です。

"This would happen every once and a while, but after 20 tickets, we'd have to manually filter those out in office 365 to break the chain, then remove the rule"

CCing the "support@" email address, r/msp, Reddit

自動受信確認は、一般的にもう一度考えてみる価値があります。それは、人が対応しているように読めるキューと、機械が対応しているように読めるキューとの間の目に見える違いであり、それがFreshdesk autoresponderの設定の裏にあるトーンの議論であり、チームが代わりにthread-native toolsを検討する理由の半分でもあります。

共有受信箱かチケットシステムか

この判断の誠実な答えは、実は機能の話ではありません。今この瞬間、誰が何に対応しているかを誰かが本当に教えられるかどうかの話です。

両方のやり方を20年近く経験して、行き着く場所は同じです。

"I've worked in IT for more close to two decades and always had a ticketing system, but recently started a job with a shared mailbox. Go with a ticketing system. So much easier to keeps this organized and know who is working on what."

throw0101a, r/ITManagers, Reddit

普段そこから逃げ出したいと思っている状態は、実際にはシンプルな受信箱よりもさらに悪いものです。あるシステム管理者はその「以前」の状態をこう描写しています。"each department had about 5 shared mailboxes and forwarding rules. Lots of forwarding loops as this got out of hand fast."

逆のケースもまた実在します。ただしそれは配線の話よりも見せ方の話です。

"We have a support@ address which customers email their problems into. It's still "ticketed" but it never appears that way to client. I've yet to have a client complain about using email unless emergency."

FusionZ06, r/sysadmin, Reddit

正直なところ、それが私の見方でもあります。チケットは内部で運用し、外部にはメールとして見せる。参照番号は自社のレポートのためのものであり、顧客の受信箱のためのものではありません。そこから先の選択は、主に誰をサポートしているかに帰着します。ITチームはIT ticketing systemとservice deskの枠に、MSPはMSP ticketingに、エンジニアリング主導のチームはJiraに、SalesforceショップはSalesforceに落ち着きます。小規模なチームはよくSpiceworksやZohoから始め、すでにチャットで暮らしているチームはSlack-firstに向かう傾向があります。カテゴリよりも短いリストが欲しいなら、top helpdesk softwareとcloud-based ticketingの2つを読むのがおすすめです。

かかる費用、そして実際に計測されるもの

メールそのものが実際に支払う対象であることはめったにありません。座席こそが本題です。

一番下のJiraの行は小さく見えますが、鋭い落とし穴があります。DMARC送信者検証は、送信者が認証されていない場合に参加プロバイダからのメールがプロジェクトに届くのを防ぎ、唯一のドキュメント化された回避策は有料プランへのアップグレードです。Freeプランでは、ドメイン設定を誤った顧客は静かにメールを失うだけで、そのチェックをオフにすることはできません、それだけです。

このカテゴリでお金がかかるそのほかのものは、たいてい受信箱そのものではなくAIの計測メーターです。それは別の話ですが、キューだけでなくフルスタックの予算を立てているなら、Zendesk pricingとFreshdesk pricingで数字を計算してあります。

メールキューを壊さずにAIを導入する

配線が実際にしっかりしていれば、メールは自動化に最も適した場所です。ほとんどのチームが運用する中で、最も量が多く最も繰り返しの多いチャネルだからです。社内ではメールを世界最大のヘルプデスクと呼んでいて、まさにそれがデフレクションの計算がまずそこで成立する理由です。理にかなった作業順序は、自社のナレッジベースと過去のチケットで学習させ、次に何かに返信させる前にタグ付けと分類を行い、そして最初の悪い回答の後ではなく稼働前に引き渡しルールを設定することです。

実際に本番のキューでこれをやってみた上での2つの注意点があります。まず、受信箱はチケットキューではありません。ニュースレター、ベンダーからの通知、配送確認もすべてそこに入っていて、フィルタリングのないAIは喜んでニュースレターに返信してしまいます。次に、デフレクションは希望ではなく実際の履歴に対して測ってください。まさにそのためにticket deflection guideがあります。

すでに運用しているメールキューでeeselを試す

ヘルプデスク自体は問題なく、メール量そのものが実際の問題であるなら、何も移行する必要はありません。eeselは、Zendesk、Freshdesk、Jira Service Managementのいずれであれ、すでにあるキューの上にそのまま乗り、チームがすでに対応したチケットから学習し、確信度のしきい値を保持することで、対応すべきところで対応し、残りはそのままにしておきます。

上記すべてを踏まえて、個人的に最も気にかけたい部分はこれです。何かが本番稼働する前にチケット履歴に対してシミュレーションできるので、あなたのAIに最初に出会う顧客が、そのAIにとっての最初の本当のテストにもならなくて済みます。ある顧客、Gridwiseは、最初の月でティア1リクエストの73%を解決するのを目の当たりにし、その結果を長期契約への署名の後ではなく7日間のトライアル中に得ました。課金は対応したチケット単位で、座席課金ではないため、すでに支払っているメーターの上に別のメーターを重ねることはありません。eeselを試す 無料で、カード不要です。