要点
共有サポートキューの管理とは、サポートチームが1つのチケットプールを分け合い、すべてのチケットに素早く1人の担当者を付ける方法です。共有キューを壊すのは、ほとんどの場合、量ではありません。全員に見られているのに誰のものでもない状態、つまり担当者の空白です。まずそこを直します。割り当てモデル（プル、プッシュ、ハイブリッド）を意図して選び、すべての新規チケットに決めた時間内に担当者を付け、初回応答時間だけでなく、担当者のいない最古のチケットの経過時間を見てください。
ほとんどのヘルプデスクはチケットを自動でエージェントに振り分けられますが、その設定は多くの場合プランの制限の先にあります。ラウンドロビンは Freshdesk Pro（エージェントあたり $55）と Help Scout Plus（$45）、Front のロードバランシングは Professional（$65）、スキルベースのルーティングは Zendesk Suite Professional（$115）または Freshdesk Enterprise（$89）です。Gorgias は全ヘルプデスクプランに自動割り当てを含みます。
仕分けの段階は、いまや AI が得意とするところです。実際の Zendesk トラフィックを使った eesel のトライアルでは、トリアージの精度は 93% で、スパムは 100% 検出されました。eesel の AI ヘルプデスクチームメイトは、既存のキューの中で簡単なチケットにタグ付け、ルーティング、回答を行うので、人は人が必要なチケットだけを担当できます。
共有サポートキューの管理とは？
共有サポートキューとは、各エージェントが個別の受信箱を持つ代わりに、チーム全体が作業する受信チケットの1つのリストです。共有サポートキューの管理とは、誰がどのチケットを取るか、どれだけ早く担当者が付くか、誰かが不在のときどうするか、何かが漏れたときにどう気づくかを決めるルールの集まりです。
私は eesel で毎日サポートキューを扱っていますが、共有キューで難しいのは難しいチケットではないと学びました。難しいチケットは目立つので注目されます。漏れるのは、4人が開いて読んで閉じた普通のチケットで、それぞれが誰かが取るだろうと思っていたものです。
ヘルプデスクごとに共有キューの見え方は少しずつ違います。
- Zendesk はビューを使い、標準の未割り当てビューがあります（Zendesk ドキュメント）。
- Freshdesk はチケット一覧ビューを使い、ルーティングはグループごとに設定します（Freshdesk ドキュメント）。
- Help Scout は各受信箱に固定フォルダー（Unassigned、Mine、Assigned、Closed、Spam）があります（Help Scout ドキュメント）。
- Front は Unassigned、Assigned、Waiting のタブを持つ共有受信箱で作業します。
- Gorgias はビューを使い、誰にも割り当てられていない未完了チケットの標準ビュー「Unassigned」があります（Gorgias ドキュメント）。
ツールの名前は変わっても、失敗のパターンは変わりません。
共有キューが壊れる理由：担当者の空白
最もよく見るパターンはこうです。チケットが届く。3人のエージェントがキューで見る。それぞれ別の作業を開いているので、それぞれ先へ進む。誰の名前も付いていないので、誰もチケットが古くなっていくのを感じません。
ある学校の IT リーダーが何年も前に、山から勝手に取っていく方式の状況を書いていますが、今でも私が見てきた過負荷のサポートキューそのものに読めます。
"We currently have an unending bucket of tickets, the engineers and I pluck out calls with little oversight, however this results in some calls falling to the bottom of the pile and getting ignored. There's no ownership of unassigned calls."
漏れたチケットが緊急のものだと、代償は大きくなります。2026年2月、ある Zendesk 管理者が、午前9時に本番システムが止まったエンタープライズ顧客について投稿しました。チケットは夜間に届いた30件以上の後ろで午後2時まで放置され、顧客は誰かが緊急だと気づくまで5時間以上停止したままでした（r/Zendesk）。
また、2日間未割り当てのまま放置されて星1つのレビューを受けたチケットのスレッドでも、典型的な話でした。全員が誰かが取ったと思い込んでいたのです。ある返信は原因をはっきり述べています。
"That's not a system issue (crappy help desk software, bad ticketing system). It's a bad work ethic ("Meh, Bob can get that. Or Cindy. IDC, I'm busy on Reddit.")
Systems can help with setting SLAs and possibly even forcing ownership, but ultimately it's up to the team to take responsibility and do their jobs."
半分は同意します。仕事への姿勢は大事です。しかし、全員が次のチケットを取るのを覚えていることに頼るキューの設計は、全員がすでに3件抱えている最も忙しい日に失敗します。解決策は、担当を自動化するか、誰かの仕事にすることで、願うことではありません。
この記事の土台はこの発想の転換です。応答時間だけでなく、担当者のいない時間を測ることです。初回応答時間の平均は、1件のチケットが午後じゅう放置されていても良好に見えることがあります。平均は分布の裾を隠すからです。
共有キューで仕事を割り当てる3つの方法
チームが選んだかどうかにかかわらず、すべての共有キューは3つのモデルのどれかで動いています。
プルは、エージェントが共有ビューから自分のチケットを選ぶ方式です。ほとんどのヘルプデスクの初期設定で、腕のいいエージェントがより多く取れるので公平に感じられます。弱点は、いいとこ取りです。ある Zendesk チームは、手が回らないときにわざとそうしていると認めています。
"If we're underwater we do an easy out method where we cherry-pick the simple tickets (can be handled in less than 5 minutes) and have a portion of the team hit those while the rest does fifo."
これは賢く意図的なやり方です。意図せずに起きるのは、全員が黙って同じ面倒なチケットを飛ばすことです。
プッシュは、ヘルプデスクがルールに基づいてチケットルーティングでチケットを割り当てる方式です。ラウンドロビン（順番の次のエージェント）、負荷ベース（未完了が最も少ない人）、スキルベース（言語、製品、階層の一致）があります。担当者問題は解決しますが、たまたまオンラインの人に負荷が偏ることがあり、どのチケットが難しいかも分かりません。ある Zendesk チームは切り替えた後にそれを知りました。
"We recently moved from Round Robin to OCR and it's been a bit of a nightmare."
同じ投稿では、2〜3人のエージェントがメールチケットを15件受け取る一方で他は数件かゼロで、一部のチケットは未解決ビューからまったくルーティングされなかったと書かれていました。これは通常、キャパシティとステータス設定の問題で、プルに戻る理由ではありませんが、プッシュには調整が必要なことを示しています。
ハイブリッドは、通常の流れは自動で割り当て、VIP アカウント、エスカレーション、ルールで振り分けられないものなどを、リードが手作業で扱う小さなレーンを加える方式です。私がアドバイスするチームの多くはここに落ち着きます。
| モデル | 誰が決めるか | 向いている場面 | 主なリスク | 追加するもの |
|---|---|---|---|---|
| プル | エージェントが選ぶ | 小規模チーム、似たチケット | いいとこ取り、古くなるチケット | 古い順のビュー、日替わりのトリアージ担当 |
| プッシュ | ヘルプデスクのルール | 忙しいキュー、チャットとメッセージ | オンラインの人への過負荷 | キャパシティ上限、不在ステータス、再割り当て |
| ハイブリッド | ルールとリード | 階層が混在、VIP、複数言語 | 手動レーンに担当者がいない | シフトごとに名前の決まったレーン担当者 |
プルを続けるなら、このテーマの Reddit スレッドがどれも何らかの形でたどり着く1つのルールを加えてください。残りを担当する人です。ある MSP のリードは自分たちのやり方をこう説明しています。
"our helpdesk team functions as one big resource pool. Inbound phone calls and tickets are automatically queued, and the techs check it every so often to take tickets. Helpdesk manager gets an alert if a ticket's been sitting in the intake queue for 30 minutes, at which point he'll assign to a resource."
この30分のアラートがコツのすべてです。速さにはプル、担当の保証には安全網を。
あなたのキューに合う割り当てモデルは？
自分のチームに最も近い行を選んでください。それぞれ、私が最初に選ぶモデルと、それを機能させる設定を示します。
あなたのキューに合う割り当てモデルは？
自分のチームに最も近い説明をタップしてください。
最初の選択：プル＋トリアージ担当
エージェントには、古い順に並べた1つの共有ビューから引き続き選んでもらいます。日替わりのトリアージ担当を置き、上限を過ぎても担当者のいないチケットを割り当ててもらいます（メールなら30〜60分が妥当な出発点です）。
どのプランでも使えます。ヘルプデスクに衝突検知があればオンにしてください。
最初の選択：プッシュ、負荷ベース
未完了チケットが最も少ない人に新規チケットを自動で割り当て、誰も埋もれないようエージェントごとにキャパシティ上限を設けます。エスカレーション用に手動レーンを残します。
Freshdesk Pro（$55）、Balanced は Help Scout Pro（$75）、Front Professional（$65）、Zendesk のキャパシティベースのルーティングは Team プラン以上、Gorgias は全プランで利用できます。
最初の選択：ハイブリッド、スキルまたはグループのルーティング
まず言語、製品、階層でルーティングし、各グループ内で負荷を分散します。リードがシフトごとに VIP と例外のレーンを担当します。
スキルベースのルーティングは Zendesk Suite Professional（$115）と Freshdesk Enterprise（$89）です。Help Scout、Front、Gorgias では、チームや受信箱を分け、ルールでそこへルーティングします。
最初の選択：プッシュのみ
ライブチャットの顧客は、エージェントが選んでいる間は待ってくれません。会話を対応可能なエージェントに振り分け、短い承諾または再割り当てのタイマーを設定し、エージェントごとの同時チャット数に上限を設けます。
Zendesk は Professional プラン以上で、エージェントが時間内に承諾しなかったチケットを再割り当てできます。Gorgias はエージェントが対応不可になるとチャットの割り当てを解除できます。
各ヘルプデスクは共有キューをどう扱うか
ここでプランの制限が効いてきます。以下は、2026年10月時点の各ベンダーのドキュメントと料金ページに基づく、各ツールが単独でできることです。価格は各料金ページに記載のエージェントあたり月額で、ページが年払いを提供している場合は年払いです。
| ヘルプデスク | ラウンドロビン | 負荷またはキャパシティベース | スキルベース | 衝突検知 | SLA ポリシー |
|---|---|---|---|---|---|
| Zendesk | オムニチャネルルーティング、Team プラン以上（Suite Team $55） | キャパシティベースが初期設定、Team プラン以上 | Suite Professional $115、Support Enterprise | Team 以外の全プラン | Suite Growth 以上 |
| Freshdesk | Pro $55 | Pro $55 | Enterprise $89 | Growth $19 以上 | Growth から1ポリシー、Pro で複数とエスカレーション |
| Help Scout | Plus $45 | 「Balanced」、Pro $75 | ドキュメントに記載なし | 全プラン | Standard 1、Plus 2、Pro 無制限 |
| Front | ルールアクション、全プラン | ロードバランシング、Professional $65 | ドキュメントに記載なし | あり、プラン制限の記載なし | 時間目標、Professional $65 |
| Gorgias | 最少チケットへの自動割り当て、全ヘルプデスクプラン | キャパシティ上限は1つ、全プラン | ドキュメントに記載なし | 「Also viewing」バナー | 全ヘルプデスクプラン |
Zendesk
Zendesk のオムニチャネルルーティングは、エージェントのステータスと空きキャパシティに基づいて、メール、通話、メッセージを振り分けます。キャパシティベースの割り当てが初期設定で、そのチャネルに最も余裕のある対象エージェントに仕事が渡ります（Zendesk のキャパシティルール）。割り当て方法をラウンドロビンに切り替えることもでき、キャパシティが残っている限り、新しいチケットを最も長く受け取っていないエージェントが選ばれます。
設定の手順は私の Zendesk ラウンドロビンのガイドで解説しています。
共有キューで特に重要な設定は3つです。
- スキル。 スキルベースのルーティングは Suite Professional 以上です。必須スキルはタイムアウトしませんが、任意スキルは設定したタイムアウト後に外れます（Zendesk のスキルのドキュメント）。
- 再割り当て。 Zendesk は、エージェントのステータスが選んだものに変わったとき、最近更新された未完了のメールとメッセージのチケットを最大50件まで再割り当てできます。再オープンされたチケットの再割り当てと、エージェントが時間内に承諾しなかった場合の再割り当ては Professional 以上です（Zendesk のルーティング設定）。
- 衝突。 ビューの目のアイコンは他の人が見ているチケットを示しますが、エージェントの衝突検知は Team プランでは使えません（Zendesk の衝突のドキュメント）。
Zendesk のインテリジェントトリアージは、Zendesk の発表によると、Professional プラン以上で追加費用なしに意図、感情、言語を分類するようになりました。その分類をルーティングで使うには、まだ Copilot アドオンが必要で、Zendesk の料金ページではエージェントあたり月額 $50 と表示されています。
Freshdesk
Freshdesk はルーティングをグループごとに設定します。Admin、Groups、Group Properties で、手動か、ラウンドロビン、負荷ベース、スキルベースの割り当てを持つ Advanced Automatic Routing（Omniroute 搭載）を選びます。
ラウンドロビンと負荷ベースの割り当ては Pro と Enterprise で、ラウンドロビンはすでに上限に達しているエージェントを飛ばします（Freshdesk のラウンドロビンのドキュメント）。負荷ベースは、各エージェントが上限に達するまで、最も負荷の低い対応可能なエージェントにチケットを渡します。スキルベースのルーティングは Enterprise のみです。
Freshdesk の料金ページでは、エージェントあたり Growth $19、Pro $55、Enterprise $89 です。
チームがつまずきやすい点が2つあります。1つ目は、オフラインのエージェントは新しいチケットを受け取れず、誰も対応可能でない場合、チケットは未割り当てのままになることです。2つ目は、手動の割り当てでエージェントが上限を超えることがあり、その超過分がそのエージェントの自動割り当てを妨げることです（Freshdesk Omniroute のドキュメント）。オフラインのエージェントの未完了メールチケットをプールに戻す設定は見つからなかったので、シフトの切り替え時に手動で点検する計画を立ててください。衝突検知は Growth 以上です。
Help Scout
Help Scout はシンプルです。ルーティングには2つの方法があります。Plus では「one by one in alphabetical order」で割り当てる Round Robin、Pro ではアクティブな会話が最も少ないチームメイトに割り当てる Balanced です（Help Scout のルーティングのドキュメント）。
ルーティングは Away か上限（最大100）に達したチームメイトを飛ばし、最も長く待っているものから処理し、すでに Unassigned にあるものも拾います。手動とワークフローの割り当てはこれらのルールを無視します。衝突検知は全プランにあり、会話を開いてから他のチームメイトが返信したり顧客が書き込んだりした場合、Help Scout はあなたの返信を一時停止します（Help Scout の衝突のドキュメント）。Help Scout の料金では、ユーザーあたり月額 Standard $25、Plus $45、Pro $75 です。AI と組み合わせるなら、自動化できる内容を Help Scout のトリアージのガイドで解説しています。
Front
Front はルールでルーティングします。ラウンドロビンのルールは、オンラインのチームメイトに順番に割り当てますが、全員がオフラインだと何も割り当てられずキューもないため、後で戻ったチームメイトは見逃した会話を受け取れません（Front のルーティングのドキュメント）。共有キューにはロードバランシングのルールの方が賢明です。上限（最大100）まで、未完了の会話が最も少ない人に割り当て、全員が満杯なら待機させ、最も古い未返信の会話から再開します。Professional 以上で利用できます（Front のロードバランシングのドキュメント）。
Front の不在時の扱いは、共有キューにとって優れたものの1つです。不在のチームメイトに割り当てられた会話への返信は、割り当てが解除されて自動的に Unassigned に戻り、全プランで使えます（Front の不在のドキュメント）。Front の料金では、1席あたり Starter $25、Professional $65、Enterprise $105 です。AI 側については、私の Front のトリアージの記事をご覧ください。
Gorgias
Gorgias はエージェント単位では課金しません。チケット量で課金し、ヘルプデスクプランは、年払いで、50チケットの Starter が月額 $10 から、5,000チケットの Advanced が $750 までです（Gorgias の料金）。自動割り当ては全ヘルプデスクプランにあります。ルールでチケットをチームに送り、Gorgias が優先度と作成日でチケットを並べ、チケット数が最も少ない対応可能なエージェントに渡します（Gorgias の自動割り当てのドキュメント）。
キャパシティ上限はすべてのエージェントに共通の1つの数値なので、新人にシニアより軽い負荷を設定することはできません。Gorgias は、担当エージェントがオフラインのとき再オープンされたチケットの割り当てを解除でき、エージェントが対応不可になるとチャットの割り当ても解除できます。Gorgias の割り当てルールのガイドでさらに詳しく、Gorgias のビューの記事でキュー側を扱っています。
2人が同じチケットに答えるのを防ぐ
取りこぼしの逆の失敗は二重対応です。2人のエージェントが同じ顧客に少し違う回答を返してしまいます。取りこぼしより少ないものの、顧客はより気づきます。共有受信箱についてのスレッドで、ある CS リードが解決策を指摘していました。
"Zendesk or hubspot would be good for tracking, and assigned ownership so multiple people don't try to take ownership and end up causing issues."
保護の層は2つあります。1つ目は割り当てです。届いた瞬間に1人の担当者が付いたチケットは、二重に取られません。2つ目は衝突検知で、他に誰が見ているか、入力しているかを表示します。Front のものは、何を探すべきかの良い例です。
「replying」の表示は、会話を開く前の一覧自体に出ます。共有下書きには引き継ぎ用の Take over ボタンがあります（Front の衝突のドキュメント）。現在のプランに衝突検知がない場合（Zendesk Team、Freshdesk Free）は、唯一の防御策なので、プッシュの割り当てがさらに重要になります。
共有キューを誠実に保つルール
ツールは設定を提供します。その設定が機能するかどうかは、次の6つのルールで決まります。
- すべての新規チケットに決めた時間内に担当者を付ける。 チャネルごとに数値を決めます。たとえばメールは30分、チャットは数秒です。初回返信の SLA とは別の目標として追跡します。
- シフトごとに1人が残りを担当する。 2日間未割り当てだったスレッドのあるコメントが、最も単純な形を示しました。"Make one person responsible each day/week for triage; reading all calls as they come in, fixing the 5 minute ones and assigning out the remainder"（r/CustomerService）。
- 共有ビューは古い順に並べる。 新しい順のビューは、新鮮で簡単なチケットを取ることを促します。古い順なら、古くなっていくチケットが全員の最初に目に入ります。
- キャパシティ上限を設定し、守る。 上のどのヘルプデスクでも、エージェントは自分で上限を超えて割り当てられます。リードが最も速いエージェントにチケットを積み続けると、プッシュのルーティングは何もバランスしなくなります。
- 不在ステータスに意味を持たせる。 ルーティングが飛ばすのは、不在またはオフラインに設定されたエージェントだけです。昼休みにステータスを設定し忘れると、チケットはその人の名前の下に溜まります。いなくなった人に割り当てられたままのものを点検するシフト引き継ぎと組み合わせてください。
- 担当者のいないチケットを自動でエスカレーションする。 上限を過ぎて未割り当てのチケットがあればリードに知らせるトリガーや自動化は、安価な保険です。Zendesk のレシピは未割り当てチケットのエスカレーションのガイドに、返信側は SLA エスカレーションにあります。
リードが見落としがちな公平性の問題もあります。Reddit のあるシスアドミンは、チームの他の人の3倍の通話を処理しているのに未完了チケットが多すぎると叱責され、一方でキューにまったく触らない同僚は「健全な」数値を褒められたと書いています（r/sysadmin）。プール型でエージェントごとの未完了チケットを測ると、取りに行く人を罰することになります。代わりに、処理したチケットと担当者のいない経過時間を測ってください。
共有キューで見るべきもの
20個のタイルがあるダッシュボードは要りません。1日に数回確認する4つの数値があれば十分です。
| 数値 | 分かること | 落とし穴 |
|---|---|---|
| 担当者のいない最古のチケット | 実際の最悪の待ち時間 | 平均では完全に隠れる |
| 未割り当て件数 | ルーティングや人が追いついているか | 急増はステータスやキャパシティの設定ミスを意味する |
| 担当者ごとの未完了チケット | 負荷が均等か | 1人が他の3倍なら、プッシュが分散していないか、リードが上書きしている |
| 前回確認以降の再オープン | 速い回答が本当に解決しているか | 再オープンが多いなら、速さを品質で買っている |
これらは通常のカスタマーサービス KPIの代わりではなく、それと並べて見るものです。チケットの滞留がすでに大きい場合は、ルーティングを調整する前に、サポートの滞留を解消するガイドから始めてください。
ルーティングでは、単に人手が足りないキューは直せません。人員計算はサポートのカバレッジ計画の記事にあります。
共有キューにおける AI の役割
共有キューの仕事の大半は、回答することではありません。チケットを読み、それが何かを判断し、タグを付け、誰が持つべきかを決めることです。この仕分けの段階こそ AI が得意になった部分で、私ならここから始めます。
eesel は何年も前から実際のサポートキューに AI を導入しており、実際の導入で得られた数字はどんな宣伝文句よりも役に立ちます。月に約1,000件のチケットを扱うドイツのオンラインジュエリー小売業者での、実際の Zendesk トラフィックを使ったトライアルでは、eesel の AI はトリアージの精度 93%、スパム検出 100% を達成し、受信箱の22%を占めたスパムに誤検出はありませんでした。下書き返信は88%が方向性として正しく、12%はそのまま送信されました。エージェントは主にリサーチと自動トリアージのアシスタントとして使い、これはまさに共有キューが必要とする仕事です。
購入側から最もよく聞く要件は、速さではなくコントロールです。Gorgias を使う、月に約7,000件のチケットを扱うサプリメントブランドの CX リードは、通話でこう語りました。
"I need an AI who is only handling the tickets that it's confident to handle and all the other ones, leave them alone."
共有キューにとって正しい感覚です。AI は完全に処理できるチケットを引き受け、残りは仕分けてルーティングし、確信のないものは人に任せるべきです。eesel のヘルプデスクチームメイトでは、ルーティングはヘルプデスクの割り当てアクションを使って、あなた自身の指示（たとえば「怒っている顧客からのものはシニアチームに割り当てる」）に従います。段階的に展開できます。まず下書きを社内メモとして出し、その後、簡単なチケットを最初から最後まで回答させます。どれも本番に出る前に、Simulation が過去のチケットを再生し、チームが実際に送ったものと照らして AI の回答を採点するので、顧客より先にミスを確認できます。
Zendesk を使うドライバー向け分析アプリの Gridwise は、G2 のレビューにこう書きました。
"In the first month, eesel is resolving 73% of our tier 1 requests... The platform even includes automations for ticket tagging, assignment, and status updates!"
Kim Simpson, Gridwise
共有キューにとっての効果は、簡単なチケットがそもそも山に届かず、届くものはすでにタグ付けされルーティングされていることです。選択肢を比較するなら、チケットトリアージに最適な AIのまとめが全体像を、AI コパイロットのガイドが下書き側を扱っています。
共有キューのよくある失敗
- 割り当てなしの共有受信箱を1つだけ運用する。 1日10件なら問題ありませんが、40件では混乱します。ある CS 担当者は、専用プラットフォームに移った理由を "once it became unwieldy to manage the responses and mistakes were being made" と説明しています（r/CustomerSuccess）。切り替えの時期は共有受信箱とチケットシステムの比較の記事で扱っています。
- キューを個人の受信箱に分ける。 すっきりして見えますが、同僚の滞留は誰にも見えず、誰かが病気になるとチケットが死にます。キューは1つに保ち、その中でルーティングしてください。複数拠点のチームについても、分散型サポート運用のガイドが同じ主張をしています。
- キャパシティ上限なしでプッシュのルーティングをオンにする。 上の Zendesk のスレッドにあった「3人に15件、他にはゼロ」のパターンになります。
- エスカレーションを一般プールの一部として扱う。 エスカレーションされたチケットには、ラウンドロビンの枠ではなく、名前の決まった担当者が必要です。チケットのエスカレーションプロセスのガイドと、エンジニアリングへの引き継ぎについてはチーム間エスカレーションをご覧ください。
- タイムゾーンを無視する。 異なる地域の人がカバーするキューには、スケジュールによるルーティングが必要です。さもないと夜間の山は最初にログインした人に落ちます。その設定はフォロー・ザ・サン型サポートで扱っています。
共有サポートキューのための eesel
共有キューが定型チケットに溺れているなら、最も安い解決策は、それを山から取り除いてくれるチームメイトです。eesel の AI ヘルプデスクチームメイトは、Zendesk、Freshdesk、Gorgias、Front、Help Scout などのヘルプデスクに数分で接続し、過去のチケット、マクロ、ヘルプセンターから学び、すでに運用しているキューの中で簡単なチケットにタグ付け、ルーティング、回答を行います。エージェントはこれまでのビュー、ルーティング、ワークフローをそのまま使えます。目にするチケットが減り、目にするものはすでに仕分けされているだけです。
実際の顧客に触れる前に、Simulation で自分の過去のチケットを使って試せますし、始めるための無料プランもあります。共有キューで eesel を試して、先週どのチケットを片付けられたか確認してください。