返信テンプレートとチケットテンプレート

テンプレートは「Settings → Templates」にあります。見出しの下の行が、何をして何をしないかを述べます。「Reply templates fill the comment editor and suggest field actions. Nothing is sent automatically.」テンプレートは用意された一手であって、機械ではありません。送信は、常に自分で行います。

種類は2つで、作るときに選びます。開いているチケットへの返信には「Add reply template」、新しいチケットのフォームには「Add ticket template」です。種類はあとから変えられません。フォームにどの項目が出るかを決めるためです。テンプレートの上のバッジで、どちらを見ているかが分かります。青が「Reply template」、緑が「Ticket template」です。

返信テンプレートは、返信の本文（「Reply text」）、「Internal note」のチェックボックス、そして任意の数の操作からできています。操作は6つあります。「Set the status」「Set the priority」「Assign to a user」「Remove the assignee」「Hand over to another team」「Set a follow-up」です。

「Assign to a user」の一覧は、「The agent who applies it」から始まります。テンプレートを複数人で共有する場合は、これを選んでください。チケットは、一覧の中の決まった一人ではなく、適用した人のものになります。「Set a follow-up」は、数量と単位（分、時間、日、営業分、営業時間、営業日）に加えて、あとでチケットが戻ってきた理由を伝えるメモを求めます。

どのテンプレートにも、末尾の青い枠に、それが何をするかが1文で書かれます。たとえば「Inserts the text as a public comment, sets status to Waiting for Service Provider Response, assigns to the applying agent, sets a follow-up in 3 days.」のように出ます。この文は、編集している間ずっと書き変わります。これが自分への確認になります。意図と違うことが書かれていれば、どこかの設定が間違っています。

本文は必須ではありません。「一言も書かずにネットワークチームへ引き渡す」も、正しいテンプレートです。その場合、文は「Suggests actions without a reply text」となります。「Set the status」の操作は、手でステータスを変えるときと同じ規則に従います。複数のチケットにまとめて適用すると、テンプレートは施錠されたチケットを飛ばし、その理由を示します。

「Close ticket」の画面でも、「Template」の欄で返信テンプレートを選べます。一覧に出るのは、有効になっている「Set the status」の操作で、解決済みか終了として数えるステータスを設定するテンプレートだけです。内部用のテンプレートは、そこには出ません。1つ選ぶと、画面はその本文をコメントとして取り込みます。テンプレートがメールを送るもので、画面にメール送信の欄がある場合、宛先を取り込むのは、それが「Requester」か固定のアドレスのときだけです。テンプレートのほかの操作と添付ファイルは、そこでは実行されません。チケットは、通常どおり閉じられます。

開いているチケットでは、コメント欄の上に「Template」のボタンがあります。クリックすると、入力しながら探せる検索（「Search templates…」）が開き、選ぶとコメント欄が埋まります。ほかには何も起きません。下の行にも、そう書かれています。「Nothing happens until you add the comment.」

テンプレートの操作はそれぞれ、ボタンの横にバッジとして並びます。専門用語ではなく、平易な言葉で表示されます。「sets status to Waiting for Service Provider Response」「assigns to the applying agent」「sets a follow-up in 3 days」といった具合です。バッジをクリックすると取り消し線が付き、選択が外れて実行されなくなります。もう一度クリックすると、元に戻ります。

外した操作は、消えるのではなく取り消し線が付きます。テンプレートが何を提案していたかが見えたままになり、送信するまでは判断をやり直せます。

どのバッジが最初から有効かは、テンプレートが決めます。設定では、操作ごとに「Suggested」のスイッチがあります。このスイッチはすべての案件への提案で、チケット上のバッジは、この案件での判断です。

バッジの後ろの「×」で、テンプレートを外せます。本文は入力欄に残ります。すでに書き直しているかもしれないためです。消えるのは効果だけで、操作、メール、添付ファイルが対象です。

送信は、いつものコメントのボタンで行います。そのときに初めてコメントが作られ、そのあとで、まだ有効な操作が実行されます。

返信の本文では、5つのプレースホルダーを使えます。一覧は欄の下にあります。「{requesterName}, {ticketId}, {ticketTitle}, {ticketRef}, {agentName}」。そこに書かれているとおり、波かっこを付けて書いてください。

「{ticketRef}」は「[TICKET-8-…]」の形のチケットの参照番号です。顧客の返事がメールで戻ってきたとき、システムがそれを見分けるのに使います。一方の「{ticketId}」は、番号だけです。

置き換わるのは、テンプレートを保存したときではなく、適用したときです。設定のページには「{requesterName}」のまま表示され、チケットのコメント欄には実際の名前が入ります。理由は実務的なものです。保存のときに置き換えれば、1件のチケットの値がテンプレートに焼き付いてしまいます。

そのため、何かが社外に出る前に、完成した文面を読めます。呼びかけが合わなければ、ほかの文と同じように入力欄で直します。

誰を「依頼者」と見なすかは、アカウントではなくチケットが決めます。チケットに記録された依頼者が、提出したアカウントより優先されます。エージェントが電話のあとに同僚の代わりにチケットを作った場合でも、返信はエージェントではなく同僚に呼びかけます。

プレースホルダーの綴りを間違えると、保存のときに拒否され、どれが違うかも示されます。「Reply text: unknown placeholders {requesterNam}. Available here: {requesterName}, {ticketId}, {ticketTitle}, {ticketRef}, {agentName}.」テンプレートを書いている段階で気づけるので、顧客に見つけてもらう必要はありません。

メールの件名には、専用の短い一覧があります（「{originalSubject}, {ticketTag}, {ticketId}」）。だからこそ、そこにもう一度書かれています。「{ticketRef}」もそこで使え、「{ticketTag}」と同じ意味です。「{requesterName}」「{ticketTitle}」「{agentName}」は件名では働かず、同じように拒否されます。

「Send the comment as e-mail」のスイッチで、コメントをそのままメールにもします。専用の本文欄を用意していないのは、意図した設計です。チケットに書かれたものが、そのまま顧客の読むものになります。本文を2つ持てば、いずれ食い違うためです。

「Recipient」で、「Requester」「Assignee」「Observers」「Fixed address」から選びます。誰が依頼者かは、テンプレートを適用したときにサーバーが判断します。テンプレート自体は、まだチケットを知らないためです。受信用のメールボックス自体に書き送ることはありません。自分宛のメッセージになってしまうからです。「User」の欄にアドレスのない名前が入っている場合、依頼者にはメールが送られません。代わりにチケットを記録した人へ送られることもありません。

件名には「{originalSubject}」「{ticketTag}」「{ticketId}」を使えます。「{ticketTag}」は残しておいてください。顧客の返事を見分けて同じチケットに追加するのは、この参照番号です。これがなければ、返信のたびに新しいチケットができます。

メールは書式なしの文として送られます。太字、箇条書き、リンクは送信の前に取り除かれます。そうしなければ、顧客は書式の記号をそのまま読むことになります。チケットの中では、コメントは書式を保ったままです。

チケットでは、メールも操作と並ぶバッジの一つです（「E-mail to Requester」）。ほかと同じように外せます。そのため、テンプレートが目に触れないまま何かを送ることはありません。このバッジは、チームのメールボックスがチケットの操作に伴うメールを送る設定になっているときにだけ表示されます。

テンプレートの添付ファイル（「Attachments」）は、そのファイルの独自の複製です。テンプレートを適用すると、それがチケットに追加され、履歴にも専用の行が残ります。メールには含まれません。テンプレートに添付ファイルを持たせることに、Professional のライセンスは要りません。必要なのは、送信の部分だけです。「Internal note」にチェックが入ったテンプレートは、ファイルを追加しません。

多くのテンプレートは、机の上で考え出されるのではなく、同じ返事を2度目に書く瞬間に生まれます。そのため、チケットのどのコメントにも、右側に小さな用紙の記号があり、「Make template」と表示されます。押すと、そのコメントがそのまま出発点の本文になります。同僚のコメントでも構いません。この記号が見えるのは、テンプレートを管理できる人だけです。

チケットに添付ファイルがある場合は、どれを一緒に持っていくかを、先にダイアログが尋ねます。「Tick only the attachments the template should carry — one of them may be a customer’s screenshot. Nothing is ticked by default.」最初は何もチェックが入っていません。これは意図した設計です。

そのあと、まだ保存されていない下書きの状態で、テンプレートのページに移ります。上部に琥珀色の帯が出ます。「Draft from ticket #… — name it and review the text (it may contain customer details), then save.」名前は空です。名前を付けないと保存できません。

引き継がれるのは、本文、「Internal note」のチェックボックス、チケットのチーム、そして提案としてのチケットの状態です。ステータスと優先度が、2つの操作としてすでに入っています。引き継がれないのは、依頼者、アドレス、件名です。これらは、その1件だけのものだからです。

保存の前に、本文を読んでください。実際の案件から来ているため、人の名前、注文番号、部屋の名前が入っていることがあります。匿名化はされません。帯にもそう書かれていますが、実際に行うのは自分の仕事です。

テンプレートができるのは「Save」を押したときだけです。そのときに、チェックした添付ファイルが複製され、メッセージで確認されます。

「Applies to」で、誰にテンプレートが提示されるかを決めます。特定の1チームか、「All teams」かです。新しいテンプレートは、まず具体的なチームから始まります。「All teams」は誰かが選ぶものであって、黙って決まるものではありません。

チケットでは、担当チームのテンプレートと、全体のテンプレートが提示されます。引き渡しでチケットが別のチームに移ると、一覧も一緒に移ります。選べるのは、新しいチームのテンプレートです。

「Draft」のスイッチは、テンプレートを自分の作業場にします。「Only you can see this template until you publish it.」他人の下書きはどの一覧にも現れず、アドレスから開くこともできません。管理者でも同じです。新しいテンプレートは下書きから始まり、このスイッチを外して保存したときに初めて、ほかの人に見えます。

同じ場所に並ぶ可能性のある2つのテンプレートは、同じ名前を持てません。全体のテンプレートは、どのチームの同名のテンプレートとも衝突します。ただし、返信テンプレートとチケットテンプレートは、同じ名前を持てます。同じ一覧に並ぶことがないためです。

「Duplicate」で複製を作れます。複製は必ず下書きです。「Duplicated. The copy is a draft only you can see.」半分できたものが誰にも提示されないまま、別の型を作れる便利な方法です。

チケットテンプレートは「Create new ticket」のフォームを埋めます。返信の本文も、操作も、メールもありません。この時点では、働きかける相手のチケットがまだないためです。そのためフォームには、返信テンプレートとは違う項目が並び、緑の枠が、今見ているのがチケットテンプレートであることを示します。

あらかじめ埋められるのは、「Ticket title」「Owning team of the new ticket」「Main category」「Subcategory」「Priority」、そして「Ticket description」です。どの欄も「Not prefilled」のままにできます。空のままの欄は、フォームを使う人があとで埋めます。

2つのチームの欄の違いに注意してください。上の「Applies to」は、誰にテンプレートが見えるかを表します。「Owning team of the new ticket」は、新しいチケットがどこへ行くかを表します。この2つは別の問いで、答えが違うこともあります。

カテゴリはチームごとにまとめられています。カテゴリはチームに属するためです。別のチームのカテゴリを選ぶと、フォームがその旨を伝え、保存は拒否されます。渡し先のチームの新しいチケットのフォームでは、そのカテゴリがそもそも選べず、あらかじめ埋めても意味がないためです。

ここにプレースホルダーはありません。本文の下の説明にも、そう書かれています。「No placeholders here: the template only prefills the form, nothing is resolved or sent.」「{requesterName}」は、そのままの文字として新しいチケットに入ってしまいます。だからこそ、保存のときに拒否されます。

青い枠が、ここでもテンプレートの働きをまとめます。「Prefills the new ticket with title ‘New notebook for a colleague’ · category Notebook / New request · priority Medium · team Helpdesk · the description.」

フォームでは、「Template」のボタンでテンプレートを選びます。その横に「Prefills the form - nothing is created until you submit.」と書かれています。あらかじめ埋まったものはすべて変更でき、送信するまで何も作られません。

例のテンプレートが1つ同梱されています。「Example: create accounts for a new colleague」です。形を示すだけで、それ自体は何もしません。作り直すか、削除してください。

「Offer this template to customers」のスイッチは、初期状態ではオフです。横の説明に、知っておくべきことが2つとも書かれています。「Customers can pick this template when they create a ticket. A draft stays hidden either way.」

初期状態でオフである理由です。テンプレートには社内の言葉が付いていることが多く、同僚に向けて書かれています。顧客に見せることは、外に向けた表明です。うっかりではなく、意識して行うべきです。

顧客にも、新しいチケットのフォームの上に同じ「Template」のボタンが見えますが、並ぶのは公開されたテンプレートだけです。下書きは、スイッチをオンにしても隠れたままです。2つの規則は並列ではなく、前後に重なっています。

目的は便利さではなく、最初のやり取りです。必要な情報がそろって届く依頼は、そうでなければ2日かかるやり取りを省いてくれます。その質問を、テンプレートの説明に書いてください。顧客は、チケットを作りながら答えてくれます。

「Fields to ask for」で、さらに踏み込めます。テンプレートが、フォームでどのカスタムフィールドを、どの順番で尋ねるか、そのうちどれを必須にするかを決めます。この選択は、チームのふだんの項目に追加されるのではなく、置き換えます。まさにそれが目的です。カスタムフィールド自体は Professional に含まれ、そのカードの名前は「カスタムフィールド」です。テンプレートを顧客に公開することは、どのエディションでもできます。

顧客から隠されている項目は、テンプレートが挙げても隠れたままです。項目の選択は、順序と絞り込みのための道具であって、項目の設定を回り込む方法ではありません。

本文の挿入だけで終わらない使い方をするたびに、履歴に1件の記録が残ります。項目名は「Template」です。テンプレートの名前が書かれます。実行された操作は、それぞれ自分の行を残します。これがなければ、なぜチケットが急に「In Progress」になったのかを、あとから説明できません。個々の操作もそれぞれ行を残しますが、そのどれもテンプレートの名前を挙げないためです。

図にはこう書かれています。「Template ‘First reply: we have your ticket’ applied」。テンプレートが何をしたかは、その操作ごとの行に書かれます。たとえばステータスの変更です。

外した操作は入りません。実行されていないためです。失敗は入り、「failed」の語とともに、失敗として記されます。操作もメールも添付ファイルもない、本文だけのテンプレートは、1件のチケットでは「Template」の記録を残しません。本文を挿入しただけだからです。複数のチケットにまとめて適用した場合は、内部用の「Bulk」の行とともに、記録が必ず残ります。

この記録は内部向けで、依頼者には見えません。テンプレートの名前は社内の言葉です（「標準の却下」など）。履歴は、チケットを作った人にも開かれています。項目の変更そのものはその人にも見えますが、それがテンプレートから来たことは見えません。

実行者はエージェントであり、「system」でもテンプレートでもありません。これは意図した設計です。適用したのは、その人の判断だからです。自動化のルールと違い、ここでチケットに残るのは人の名前です。