メールの経路は1本で、方向が2つあります。この2つは組です。受信したメールがチケットになり、返信はメールとして出ていき、依頼者の返事は同じチケットのコメントとして届きます。2つ目のチケットにはなりません。
ひも付けは勘に頼りません。返信が既存のチケットに届くのは、メールの件名に案件の参照番号がある場合か、メールソフトの返信用の情報が付いている場合だけです。そのどちらもないメールは、新しい案件になります。件名がたまたま似ていただけで無関係な2件が一つにされるより、チケットが1件多いほうがましだからです。
必要な設定はすべて「Settings → E-Mail Settings」にあります。上の「SMTP settings」のカードが出口です。ホスト、ポート、「Use SSL」、ユーザーとパスワード、そして差出人のアドレスと名前を設定します。「Send test e-mail」で、自分宛に見本を送れます。カードにも書かれているとおり、先に保存してから試してください。
「IMAP settings」のカードが入口です。ホスト、ポート、取得の間隔、2つのフォルダーを設定します。フォルダー名を推測する必要はありません。「Read from server」がメールボックスに実際にあるフォルダーを取得し、「Create on server」が新しく作ります。そのあと欄には、メールサーバーが使う形の経路が入ります。あるサーバーは「INBOX/Processed」と書き、別のサーバーは「INBOX.Processed」と書きますが、意味は同じです。
処理済みのメールは「Processed folder」に移ります。空欄のままなら、受信トレイに残ります。その下で、片づけを実行する時刻（「Hour」「Minute」）と、メッセージを何日残すか（「Retention (days)」）を設定します。そうしないと、メールボックスは静かに大きくなり続けます。
メールボックスはシステムではなく、チームのものです。「Team mailboxes」で、チームごとに自分のアドレスとパスワードを入力します。そのアドレスは、同時にそのチームの差出人にもなります。依頼者は、メールを取得しているのと同じ場所に返信することになります。
そして、これがなければ何も起きない、という部分です。ワークフローです。メールボックスを設定しただけでは、何も起こりません。チームに有効なワークフローがなければ、メールボックスは取得すらされません。チケットも受付の連絡もできず、メールはただそこに残ります。顧客への自動返信は、ここにしかなく、ご自身で設定します。これは意図した設計です。頼まれてもいないのに、あらゆる差出人アドレスへ書き送るシステムは、黙っているシステムより悪いからです。
「E-Mail workflows」では、上でチームを選び、「+ Add workflow」でワークフローを作ります。ワークフローには名前（自分のためのものです）、「Enabled」のスイッチ、そして、いつ適用されるかについての指定が2つ付きます。「Match」は、すべての条件が成り立つ必要があるか（「All conditions」）、1つで足りるかを決めます。「Stop after match」は、このワークフローが当てはまった時点で処理を終えます。その場合、下にあるワークフローには順番が回りません。並び順は、横の矢印で変更します。
「When?」に条件そのものがあります。「Every e-mail in this mailbox」はすべてのメールを対象にします。「Only when subject or text contains」は、件名か本文に語があることを求めます。「Advanced」で細かく指定できます。そこで、何を見るか（「Subject or body」「Subject」「Body」「Sender (From)」「Recipient (To/Cc)」）と、どう比べるか（「Contains」「Equals」「Regex」）を選びます。たとえば、共有アドレス宛の報告を、それ以外と切り分けられます。
その下に、5つの動作がスイッチとして並びます。これがワークフローの中身です。オンにしていないものは、起こりません。
「Create or append ticket」は、メールをチケットにします。件名に参照番号があれば、既存のチケットにコメントとして追加します。この動作がなければ、メールが案件になることはありません。
「Set fields」は、チケットの作成時に、優先度、ステータス、大分類と小分類、担当チーム、担当者を設定します。「— Keep default —」のままにしたものは、ワークフローがない場合と同じままです。
「Auto-reply」は、差出人への受付の連絡です。システムが自分で返事をするのは、ここだけです。このスイッチがオフなら、ほかをどれだけ整えても、顧客に自動の返事は届きません。
「Send mail」は、追加のメールを送ります。宛先は、受信メールの差出人か、選んだチームのメンバーと固定のアドレスです。専用の「Send conditions」があり、空のままにすると、このワークフローが動くたびに送られます。
「Move to folder」は、処理したメールをフォルダーに移します。欄を空にすると、上の IMAP 設定にある「Processed folder」が使われます。
「Auto-reply」の動作を詳しく見ます。件名は部品から組み立てます。「Original subject {originalSubject}」は受信メールの件名を引き継ぎ、「Ticket reference {ticketTag}」は案件の参照番号を挿入します。2つを合わせると、「Printer problem [TICKET-99]」のような件名になります。
参照番号は、自動では付きません。{ticketTag} か {ticketId} を置いた場所にだけ現れます。そして、あとで顧客の返信をシステムが見分けるのは、まさにこの番号です。件名にこれがなければ、続きの連絡はどれも古いチケットのコメントにならず、新しいチケットになってしまいます。
その下の本文が、受付の連絡の文面です。英語で書いてください。この文面は、ほかのテキストと同じ書き出しと取り込みを通ります。そうして初めて、ほかの言語に翻訳できます。空にすると、システムが用意した文面が送られます。ここでも、同じプレースホルダーが使えます。
「Reply language」は、件名と本文をどの言語で送るかを決めます。「Standard English」は英語、「Fixed language」は選んだ言語、「Assigned agent's language」は担当エージェントの言語、「Team default language」はチームの既定の言語です。翻訳そのものは、言語のページで管理します。
システムがカードの上にも表示している助言が一つあります。一つの案件に関わるものは、一つのワークフローにまとめてください。同じワークフローの中の動作だけが、今作られたチケットを知っています。だからこそ受付の連絡はその番号を書けますし、別のワークフローの動作には書けません。
メールの機能一式は、受信も送信も Professional エディションに含まれます。Basic では、システムはメールを送りも受けもしません。チケットは、ポータル、電話、エージェントの入力から作られます。
