チケット管理

新しいチケットは、左のバーの「New Ticket」で作ります。フォームの名前は「Create new ticket」です。エージェントは、これで他人の依頼も記録します。そのための欄が「User」です。誰のための案件かを表すもので、誰が入力しているかではありません。

星の付いた項目は必須です。「Title」「User」「Main category」「Description」です。もう一つ、見落としやすいものがあります。「Subcategory」に星は付いていませんが、小分類がないとフォームは保存できません。大分類と小分類は組であり、常に一緒に設定します。

どの項目が必須かは「Settings → Ticket Settings」で設定します。「Admin / Agent Field Settings」のカードには、そのための「Field is mandatory」のスイッチしかありません。「Customer Field Settings」のカードには、さらに「Is hidden for Customer」と「Is not editable」があります。だからこそ、フォームを二つ管理しなくても、顧客にはエージェントより短いフォームを表示できます。「Title」と「Description」は常に必須です。これはオフにできません。

そのあとは、ほとんどのものを変更できます。チケットの右側に「Details」のカードがあり、依頼者、電話番号、メールアドレス、拠点、カテゴリ、参照番号が並びます。欄を書き換えて、下の「Save」で確定します。ステータス、割り当て、優先度、入り口、ウォッチャーは、一つ上の「Actions」のカードにあります。ステータスと割り当ては、すぐに反映されます。優先度、入り口、ウォッチャーは、「Details」のカードの「Save」で初めて保存されます。

これを変更できるのは、エージェントと管理者だけです。依頼者は案件を読み、コメントし、ファイルを添えられますが、レポートの土台になる分類は変更できません。

一度知っておくとよい副作用があります。まだ誰のものでもないチケットを編集すると、そのあとは自分のものになります。システムが自分をエージェントとして記入し、ステータスを「Open」から「Assigned」に移します。どちらも履歴に残ります。そうしたくない場合は、あとで別の人に割り当ててください。

これらの変更はどれも、名前、時刻、変更前の値、変更後の値とともにチケットの履歴に残ります。そのために、何かをオンにする必要はありません。

残るのは、チケットをどうやって減らすかという問題です。「Settings → Archive」で期間を選び、「Preview」でそこに閉じたチケットが何件あるかを確認し、「Create archive」で ZIP ファイルを作ります。チケット、コメント、履歴、カスタムフィールド、添付ファイルが1つのファイルに入ります。作っただけでは、何も消えません。チケットが稼働中のデータベースから外れるのは、「Existing archives」の一覧にある「Delete from live DB」という別の操作を行ったときだけです。同じファイルから戻すこともできます。

説明とコメントは、ただの入力欄ではありません。それぞれの上にツールバーがあり、ボタンにマウスを載せると働きが表示されます。「Bold」「Italic」「Underline」「Strikethrough」「Text color」「Highlight color」「Bullet list」「Numbered list」「Quote」「Link」「Clear formatting」です。

リンクの作り方はこうです。文字を選び、「Link」をクリックし、小さな入力欄にアドレスを入れます。空のまま確定すると、リンクが外れます。使えるのは Web とメールのアドレス（http、https、mailto）だけです。それ以外は保存のときに捨てられます。コメントに何かを紛れ込ませられないようにするためです。

画像はクリップボードから入ります。画面を写して、Ctrl+V でそのままエディターに貼り付けます。最初は本文に「[inline-image:1]」のような目印だけが表示されます。保存すると、システムが画像をアップロードして、ちょうどその位置に表示します。同時に、案件のすべてのファイルが集まる「Attachments」タブにも入ります。画像の貼り付けは、既存のチケットの説明と新しいコメントで使えます。「Create new ticket」のフォームや、コメントを編集している間は使えません。

自分に見えているものが、相手にも見えます。書式、箇条書き、リンクは、チケットの中でも、依頼者へのメールでも保たれます。外から来た書式、たとえばコピーした Web ページや受信メールの書式は、この許された範囲まで削られます。その際に文章が失われることはありません。失われるのは、包み紙だけです。

コメントは「Internal note (not visible to the customer)」で内部用にできます。そのコメントには「Internal」のバッジが付き、依頼者には見えません。検索にも出てきません。

自分のコメントは、誰でも変更、削除できます。顧客が書いたものを変更、削除できるのは、その顧客本人か管理者だけです。これには顧客のメールも含まれます。同僚のコメントは、そのチケットを扱えるエージェントなら誰でも変更、削除できます。以前そのチケットを持っていたチームも含みます。

ファイルは、個々のコメントではなく案件に属します。チケットの「Attachments」タブに一覧があります。「Upload file」で追加でき、各行にファイル名、大きさ、日付が並びます。チケットに関わる人なら、誰でも添付できます。依頼者も同じです。画面の写真をメールで送ってもらう必要はありません。顧客が削除できるのは、自分でアップロードした添付ファイルだけです。子チケットが閉じられると、その添付ファイルは親チケットにコピーされ、そこで「Internal」のバッジが付きます。エージェントには見えますが、顧客は見ることもダウンロードすることもできません。

ファイル名をクリックすると、ダウンロードせずにプレビューが開きます。画像なら、そこで拡大、縮小、回転ができます。斜めから撮った画面の写真に役立ちます。PDF は同じ画面に表示され、ページの一覧、拡大、印刷が使えます。テキストファイルは文字として表示されます。「Open in new tab」を使うと、別の画面でファイルを開けます。

添付ファイルは案件に属し、案件と一緒に動きます。履歴に残り（「File uploaded: …」）、別のチームへ引き渡しても残り、チケットをアーカイブすれば、アーカイブのファイルの中に入ります。

チケットの「History」タブは、あとから追いかけるときに必ず出る問いに答えます。誰が、何を、いつ変えたのかという問いです。各行に、人、項目、取り消し線の付いた変更前の値、その後ろに変更後の値、そして秒までの時刻が並びます。新しい記録が上に来ます。

記録は自動で残ります。ステータス、優先度、割り当て、カテゴリ、拠点、ウォッチャー、タイトル、説明の変更に加えて、作成（「Ticket opened」）、すべてのコメント、すべてのアップロードで残ります。タブの数字を見れば、その案件がどれだけ動いたかが先に分かります。

履歴は編集できず、オフにもできません。だからこそ役に立ちます。チケットを1件ずつ削除できない理由もここにあり、チケットをアーカイブすると、履歴も一緒にアーカイブのファイルへ入ります。

コメントについて、履歴に記録されるのは追加、編集、削除されたことだけです。文面は「Comments」タブにあります。内部用のコメントも履歴に出ますが、エージェントと管理者にだけ表示されます。

ステータスは、チケットが今どこにあるかを表します。システムには12のステータスが同梱されています。Open、Assigned、In Progress、Waiting for User Response、Resolved、Closed などです。「Settings → General Settings」の「Drop-down lists」の中、「Status」タブにあります。「+ Add status」で自分のステータスを作り、「Edit status」で既存のものを開きます。

大事なのは、名前と意味の違いです。ステータスの編集画面の「Meaning of this status」に、スイッチが3つあります。「Counts as resolved」「Counts as closed」「Waiting for the requester」です。システムがステータスをどう扱うかは、このスイッチだけで決まります。

どのステータスも名前を変えられます。同梱のものも同じです。編集画面のいちばん下、「Translations」に言語ごとの「Name」の欄があります。そこに、自社の人が読む言葉を入れてください。その裏にある技術的な名前は、そのまま残ります。だからこそ、何も壊れません。自動化、レポート、上のスイッチは、表示名ではなくその名前にひも付いているためです。「Resolved」を「完了」にすることもできます。

ただし、削除はすべてにできるわけではありません。8つのステータスには、一覧で「Mandatory」のバッジが付きます。Open、Assigned、In Progress、Resolved、Closed、Reopened、Waiting for approval、Rejected です。名前の変更と並べ替えはできますが、削除はできません。試すと、はっきりしたメッセージが出ます。意地悪ではありません。これらにひも付いた処理があり、削除すると黙って止まってしまうからです。たとえば自動での終了は、「解決済み」のステータスを出発点にしています。

2つのステータスは、システム自身のものです。「Waiting for approval」と「Rejected」には「System only」のバッジが付きます。これらは承認の流れから生まれるもので、判断にかけられてもいないものを、手で「却下された」と言えてはいけません。

3つのスイッチの働きです。解決済みとして数えるステータスにすると、チケットは24時間後に自動で閉じます。閉じたものとして数えるステータスは、チケットが最後に移る状態です。そして「Waiting for the requester」は、文字どおり依頼者を待っている状態を指します。別のチームでも、外部の業者でもありません。設定しだいで、サービスレベル合意の時計が止まる印になります。

その下に「Allowed transitions to new status」があります。ここで、このステータスからどのステータスへ進めるかにチェックを入れます。すべて空のままなら、制限はありません。何かにチェックを入れると、それ以外の道は閉じます。これが、飛ばせない流れの作り方です。たとえば「Open」からは「In Progress」か「Assigned」にだけ進め、いきなり「Closed」にはできない、といった具合です。

編集画面に残るスイッチは、小さいわりに効き目のあるものです。一覧での色、並び順を決める「Sort order」、「Show status in new ticket form」（チケットの作成時に、このステータスを選べるようにするか）、「Requires comment in dialog」（理由の入力を必須にする）、そしてシステム自身だけが設定できるようにする「System only」です。

チケットには、最大4つのステータスが「Change Status to:」の下にボタンとして表示されます。どれを表示するかは、編集画面の「Set as primary status (max. 4)」のスイッチで選びます。初期設定では、In Progress、Waiting for User Response、Waiting for Service Provider Response、Resolved です。それ以外のステータスは、すべて「More statuses」の中にあります。

チケットの中で選択式になっているものは、すべてお客様のものです。「Settings → General Settings」に「Drop-down lists」のカードがあり、タブが6つあります。「Department」「Position」「Location」「Role」「Status」「Priority」です。扱い方は、リストごとに異なります。

1件ずつ追加する場合は、空の欄に英語の名前を入力し、その横のボタンをクリックします。ボタンの名前はリストに合わせて変わり、「+ Add location」「+ Add department」のようになります。下に並ぶ行が、既存の項目です。「Department」「Position」「Location」では、そこで名前を変え、横の「Save」で確定します。

一度に多くの項目を扱う場合、「Department」「Position」「Location」には「Export JSON」と「Import JSON」もあります。導入した直後のシステムでは、「Export JSON」で空の構造をダウンロードし、埋めて、もう一度取り込みます。名前を変えるための方法ではありません。カード自身にも、そう書かれています。

一部の項目には「Mandatory」のバッジが付きます。「Admin」「Agent」「Customer」の3つの役割、同梱のステータスのうち8つ、そして拠点、役職、部門のリストにある予備の項目（「None selected or available」）です。どれも削除はできません。権限や処理がこれらにひも付いており、削除すると黙って止まってしまいます。ステータスは、専用の編集画面で名前を変えられます。役割と予備の項目は、名前を変えられません。何ができるかは、リストによって異なります。「Role」は固定されており、役割の追加も名前の変更もできません。「Priority」では項目の追加と削除ができますが、ファイルも名前の変更もありません。「Status」には専用の編集画面があり、こちらにもファイルはありません。

ここでは、ほかの言語への翻訳はしません。翻訳のページでまとめて行います。ここでは英語の名前だけで十分です。あとで翻訳がひも付く軸になります。

ステータスだけが、専用の編集画面を持ちます。名前以上のものがひも付いているためです。ステータスには、下に専用のカードがあります。

カテゴリは、依頼者やエージェントがチケットを作るときに選ぶものであり、あとでレポートをまとめる軸にもなります。カテゴリはチームごとに別々です。ヘルプデスクとネットワークの部門では分け方が違いますし、互いのリストは見えません。

「Settings」の中に「<チーム名> Categories」という項目があります。例ではチーム名が「Helpdesk」なので、項目は「Helpdesk Categories」になります。

ページには3つのカードがあります。「Main categories」「Subcategories」「Links」です。手早く始めるなら、「EN (required)」の欄に英語の名前を入れて、「+ New main category」か「+ New subcategory」をクリックします。翻訳はあとで翻訳のページでまとめて行うので、ここで準備するものはありません。

作るカテゴリが多い場合は、ファイルを使う方法があります。「Export JSON」で構造をダウンロードします。導入した直後のシステムでは中身は空で、形だけが分かります。それを埋めて（手作業でも、AI の助けを借りても構いません）保存し、「Import JSON」でアップロードします。名前を変えるための方法ではありません。名前はそのカテゴリの欄で書き換え、横の「Save」で確定します。ページにも、そう書かれています。

3つ目の「Links」のカードが、実際の作業の場です。上で大分類を選び、下でそこに属する小分類にチェックを入れ、「Save links」で保存します。ここが便利なところで、1つの小分類を複数の大分類にぶら下げられます。そのため「Malfunction」は1つ作れば足り、プリンター、ネットワーク、会議室、ノートパソコンで使い回せます。

これ以降、カテゴリはチケットで選べるようになります。まだそのカテゴリを使っているチケットがあると、削除は失敗することがあります。これは意図した動きです。そうでなければ、古いチケットが分類を失ってしまいます。結び付きを外しても、その組み合わせを使っているチケットは引き続き保存できます。結び付きと照らし合わせるのは、新しく選んだカテゴリだけです。

チケットを別のチームに引き渡しても、分類は残ります。新しいチームがそのカテゴリを持っていない場合も同じです。その場合、欄には出どころと一緒に、たとえば「Meeting-Room · from Helpdesk」のように表示され、薄い文字になります。新しいチームは、その案件がこれまで何として扱われていたかを見られますが、その項目を自分で割り当てることはできません。分類し直すときは、自分のリストから選びます。そのとき、システムは大分類と小分類を組で求めます。

どのチケットにも入り口が記録されます。フォームの中と、あとで「Actions」のカードの「How the request came in」にあります。これは、レポートですぐ大事になる問いに答えます。仕事はポータルから来るのか、電話から来るのか、という問いです。

選べるのは、人が知っていてシステムが知らないものだけです。「Phone」と「Entered by an agent」です。残る2つは、システム自身が設定します。依頼者がポータルでチケットを作った場合は「Self-service」、受信メールから生まれた場合は「E-mail」です。エージェントがチケットを作るとき、フォームは「Entered by an agent」で始まります。

システムが設定した入り口は、あとから誰も変更できません。欄には「Recorded by the system. It cannot be changed.」と表示されます。変えられれば、この欄はまさに存在理由である情報を失います。逆に、電話で受け付けたチケットでは、ほかのすべてを変更できます。

入り口を設定できるのは、エージェントか管理者だけです。依頼者にとっては、自分の案件についての申告になってしまい、レポートは全員の正直さに頼ることになります。

「E-mail」には接続済みのメールボックスが必要で、これは Professional エディションに含まれます。ほかの3つの入り口は、どちらのエディションにもあります。

どのチケット一覧の上にも「Search tickets…」の欄があります。検索するのはタイトルだけではなく、案件全体です。タイトル、説明、依頼者の名前、メールアドレス、電話番号、拠点、参照チケット番号、すべてのコメント、そして自分で作ったカスタムフィールドの文字の値が対象です。

例のとおりです。「coffee」はどのタイトルにもなく、あるチケットの説明にだけあります。それでも見つかります。チケットにどんなタイトルを付けたかを覚えている必要はありません。案件の中の一語で足ります。

大文字と小文字は区別しません。検索は、今開いている一覧に対して働き、隣の「Filter」と組み合わせられます。「Reset」で、検索と絞り込みが消えます。一覧は、チームの一覧ごとに別々に、絞り込みを覚えています。チケットから戻ったとき、ページを再読み込みしたとき、別のコンピューターでサインインしたときも、絞り込みはそのまま残ります。検索の文字列は覚えません。顧客には、見えないけれど知っておくとよい制限があります。顧客は内部のコメントを検索しません。そうでなければ、結果の一覧から内部の話の内容を推測できてしまいます。顧客から隠されたカスタムフィールドも、検索の対象になりません。

チケット一覧は、一人ひとりが自分で組み立てます。そのために、「Filter」の隣に「Columns」ボタンがあります。このボタンで「Choose columns」のダイアログが開きます。

ダイアログで、表示したい列にすべてチェックを入れます。その横の矢印で順番を決めます。「#」と「Title」は常に含まれます。列の幅は、一覧そのもので、列の見出しの端をドラッグして変えます。

「Save」で、選んだ内容がユーザーアカウントに保存されます。そのため、どのパソコンでも適用され、サインアウトしたあとも残ります。「Default columns」で、一覧が初期設定に戻ります。

すべての列を表示する場所がないときは、いちばん右の列から先に外れます。「#」「Title」「Status」は常に残ります。ですから、自分にとっていちばん大切な列を前に移します。

Professional では、カスタムフィールドも選べます。ダイアログには、それぞれ自分の名前で表示されます。ここでは、たとえば「Asset tag」です。

顧客も同じ方法で一覧を設定できますが、選べる列は少なくなります。「Team」「Created by」「Last activity」「Status changed at」「Deadline」「Follow-up」「Time」は、顧客には使えません。顧客から隠した項目も、列としては表示されません。

スマートフォンでは、このボタンは表示されません。そこでは、一覧に収まる列が表示されます。

チケットには、そのためのボタンが2つ並んでいます。違いは、その下に小さな文字で書かれています。「Involve another team」は、自分が責任を持ったまま、別のチームにひも付いたチケットで並行して作業してもらう方法です。「Escalate to another team」は、別のチームが引き継ぐ方法です。

引き渡す場合、2つ目のチケットは作られず、責任だけが移ります。自分のチームは読む権限を保ち、コメントもできますが、変更はできなくなります。ダイアログが、確定の前にそのとおり伝えます。そこで渡し先のチームを選び、理由を添えられます。

並行して作業してもらう場合、自分のチケットは自分の手元に残り、相手のチームに子チケットができます。自分のチケットはステータス「Waiting for other team」に移り、相手のチームが自分たちのチケットを閉じると、「Back from other team」として戻ってきます。向こうで何か進んだかを、尋ねに行く必要はありません。子チケットの添付ファイルは「Internal」のバッジ付きで自分のチケットにコピーされ、顧客には見えません。

分類についてです。渡した側のチームのカテゴリは、チケットに残ります。新しいチームがそのカテゴリを持っていない場合も同じで、出どころと一緒に薄い文字で表示されます。これにより、新しいチームは案件がこれまで何として扱われていたかを見られ、必要なら自分のリストで分類し直せます。

チケットを次に渡せるのは、今の責任者だけです。前の段階の担当者は、案件を見ることはできますが、もう一度渡すことはできません。コメントはできますが、チケットを自分のところに取り戻すことはできません。

その後、自分のチームの一覧では、相手のチームが作業している間、チケットに「Waiting for other team」と表示されます。「Also show tickets this team handed over」のチェックは、初期設定で入っています。各ユーザーが選んだ設定は、そのまま保たれます。相手のチームでは、チケットは「Open」から始まります。

引き渡した人は、そのチケットのウォッチャーになります。ダイアログが、確定の前にそのことを伝えます。ウォッチャーには、ステータスが変わったとき、チケットが閉じられたとき、誰かがコメントしたときにメールが届きます。ほかのウォッチャーと同じく、「Stop observing」で自分を外せます。

チケットに足りない情報があるとき、たとえば資産番号、保証の期限、原価センターなどは、自分で追加します。「Settings → Ticket Settings」のいちばん下に「Custom fields」のカードがあり、ボタンの名前は「Add custom field」です。

ダイアログで、名前と項目の種類を指定します。種類は「Text」「Multiline text」「Integer」「Decimal」「Date」「Yes / No」です。種類によって、入力できるものが決まります。日付の欄は「来週」を受け付けません。だからこそ、あとでレポートに使えます。

「Scope」で、この項目がどこに適用されるかを決めます。「All teams (including new ones)」か「Selected teams only」です。前者は、まだ存在しないチームにも適用されます。半年後になって初めて気づくような違いです。

「Defaults」にある3つのスイッチは、「Mandatory by default」「Hidden for customer by default」「Not editable by customer by default」です。これらが項目に適用されるのは、同じページの項目の設定で、その項目について何も保存されていない間だけです。そこで設定すれば、項目の設定のほうが決め手になります。

チケットでは、カスタムフィールドが専用のカード「Additional information」に入り、説明とコメントの間に置かれます。テンプレートを使わない場合、フォームにはチームのすべてのカスタムフィールドが表示されます。チケットの作成時にテンプレートを選ぶと、そのテンプレートが挙げた項目だけが、その順番で表示されます。つまり「この案件に必要な項目だけ」になります。

テンプレートは、さらに項目を必須にできます。管理者が顧客から隠した項目は、テンプレートに載っていても隠れたままです。テンプレートに載っていない必須の項目は入力を求められないため、このテンプレートで作ったチケットには、その必須の決まりが適用されません。

1つのチームがカスタムフィールドをいくつ持てるかは、「Settings → General Settings」の「Custom fields limit」のカードで設定します。項目を使わなくするには「Deactivate」を押します。フォームから消えますが、古いチケットの値は残ります。「Show deactivated」のスイッチで、一覧に戻せます。

作業はしないけれど、案件を追いたい人もいます。慎重に扱う案件でのチームリーダー、来週引き継ぐ同僚などです。そのための仕組みがウォッチャーです。チケットでは「Observers」の欄が「Actions」のカードにあり、ボタンの名前は「Add observer」です。「Create new ticket」のフォームにも、同じ欄があります。チケットでは、そこでの変更は「Details」のカードの「Save」で保存されます。

選べるのは、チケットが属するチームのエージェントと管理者だけです。顧客をウォッチャーにはできません。そうでなければ、内部の作業についてのメールが顧客に届いてしまいます。

ウォッチャーには、チケットで何かが起きるとメールが届きます。新しいコメント、ステータスの変更、割り当ての変更、項目の変更などです。すぐには送られず、まとめて送られます。最後の変更から1分待ってから、その間に起きたことをまとめた1通が送られます。1つのチケットを一気に片づけても、7通のメールにはなりません。その間に複数のコメントが届いた場合は、すべてがメールに入ります。

誰が見ているかも、履歴の一部です。変更はほかと同じように、変更前と変更後の状態とともに記録されます。

ウォッチャーの登録は Basic に含まれます。ウォッチャーへのメールは、送信の設定が必要なため Professional に含まれます。設定がなければ、ウォッチャーを登録することはできても、何も送られません。ウォッチャーは、「Stop observing」のボタンで自分を外せます。それには、チケットを変更する権限は要りません。

ウォッチャーは自動でも追加されます。「Escalate to another team」でチケットを引き渡した人は、ウォッチャーになります。そうすれば、相手のチームがそのチケットをどう扱うかがわかります。

2人が同じチケットを同時に扱うと、あとからの保存が先の保存を上書きするおそれがあり、誰もそれに気づきません。そのため、チケットにはほかに誰が開いているかが表示されます。また、古い状態にもとづく保存は受け付けません。

この表示はチケットの上部に出ます。「Marco Rossi is viewing this ticket」は、Marco がチケットを開いていることを示します。「Marco Rossi is actively editing this ticket」は、Marco がそのチケットに未保存の入力を残していることを示します。書きかけの返信、変更中のコメント、編集モードの件名や説明、フォローアップ、カスタムフィールド、時間の記録などです。「Actions」と「Details」のカードで変更した欄も、「Save」で保存するまでは対象になります。チケットで開いているウィンドウも対象です。「Involve another team?」「Escalate to another team?」「Close ticket」「Resolve incident」「Start a workflow」の各ウィンドウと、ステータス変更のコメント用のウィンドウです。入力が2分間ないと、下書きが残っていても、表示はふたたび「viewing」になります。

複数の同僚がチケットを開いている場合は、まとめて表示されます。たとえば「Marco Rossi and 2 more are viewing this ticket」です。表示にマウスを合わせると、全員の名前が見えます。誰かが編集を始めると、その行は編集中の人だけを数えます。自分自身は表示されません。2つのタブでチケットを開いていても、1人として数えられます。チケットを見えていないタブでしか開いていない場合は、約1分後にほかの人の表示から消えます。

同僚が変更を保存すると、「Marco Rossi changed this ticket」と表示され、横に「Refresh」ボタンが出ます。ほかの人の新しいコメントでは「Marco Rossi added a comment」と表示されます。人ではなく、自動化のルールや届いたメールなどが変更した場合は、「This ticket was changed」と表示されます。この表示は、再読み込みするまで残ります。

「Refresh」は、ステータス、担当の割り当て、各欄、履歴など、チケットの現在の状態を読み込みます。ページ全体は読み込み直しません。未保存の入力はそのまま残ります。書きかけの返信は返信欄に残り、開いている件名や説明の文章も残ります。保存済みの文章がその間に変わっていた場合は、欄の下に「The saved text has changed in the meantime.」と表示されます。そのまま保存すると、あなたの文章が保存済みの文章に置き換わります。チケットの上部にある「Refresh」ボタンも同じ働きをします。

それでも古い状態のまま保存すると、保存は拒否されます。「Ticket changed in the meantime」のウィンドウが開きます。人が変更した場合は、その人の名前が示されます。あなたの変更は保存されていません。「Refresh」をクリックし、現在の状態と照らし合わせて変更を確認してから、もう一度保存してください。これは、ステータス、担当の割り当て、優先度、「Details」のカード、カスタムフィールドなど、チケットそのものへのすべての変更に当てはまります。

コメントが拒否されることはありません。2つの返信が互いを上書きすることはなく、どちらもチケットに残ります。添付ファイルと時間の記録も同じです。チケット一覧での一括操作と自動化のルールも、状態の照合を受けません。これらはチケットを直接変更します。チケットを開いている人には、そのあとで表示が出ます。

顧客にはこれらは一切見えません。顧客が表示に出ることはありません。誰が自分のチケットを扱っているかも、顧客には見えません。

誰がチケットを開いているかは、サーバーのメモリーにだけ保持されます。その人がチケットを離れてから約1分で、その記録は消えます。ログには何も書き込まれません。チケットには、最後に変更した人が保存されます。この記録は、その人のデータの書き出しに含まれます。その人を匿名化すると、この記録は削除されます。

メールの経路は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」には、システムが脇に置いたメールが入ります。止めた送信者からのメール、自動で作られたメール、そしてワークフローが「Move to 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 mail」は、追加のメールを送ります。宛先は、受信メールの差出人か、選んだチームのメンバーと固定のアドレスです。専用の「Send conditions」があり、空のままにすると、このワークフローが動くたびに送られます。

「Move to folder」は、処理したメールをフォルダーに移します。欄を空にすると、上の IMAP 設定にある「Processed folder」が使われます。

「Auto-reply」の動作を詳しく見ます。件名は部品から組み立てます。「Original subject {originalSubject}」は受信メールの件名を引き継ぎ、「Ticket reference {ticketTag}」は案件の参照番号を挿入します。2つを合わせると、「Printer problem [TICKET-99-a1b2c3]」のような件名になります。

参照番号は、自動では付きません。{ticketTag} を置いた場所にだけ現れます。{ticketId} が挿入するのは番号だけで、システムはそれでは返信を見分けません。件名に参照番号がなくても、受付の連絡への返信であることを示すヘッダーが付いていれば、返信は正しく結び付けられます。どちらもないメールだけが、新しいチケットになります。

その下の本文が、受付の連絡の文面です。英語で書いてください。この文面は、ほかのテキストと同じ書き出しと取り込みを通ります。そうして初めて、ほかの言語に翻訳できます。空にすると、システムが用意した文面が送られます。ここでも、同じプレースホルダーが使えます。

「Reply language」は、件名と本文をどの言語で送るかを決めます。「Standard English」は英語、「Fixed language」は選んだ言語、「Assigned agent's language」は担当エージェントの言語、「Team default language」はチームの既定の言語です。翻訳そのものは、言語のページで管理します。

システムがカードの上にも表示している助言が一つあります。一つの案件に関わるものは、一つのワークフローにまとめてください。同じワークフローの中の動作だけが、今作られたチケットを知っています。だからこそ受付の連絡はその番号を書けますし、別のワークフローの動作には書けません。

メールの機能一式は、受信も送信も Professional エディションに含まれます。Basic では、システムはメールを送りも受けもしません。チケットは、ポータル、電話、エージェントの入力から作られます。