ライブイベントが復活しつつあるのは素晴らしいことですね。お客様から、再びチケットの予約が入り始めているというお声をいただき、大変嬉しく思っています。また、観客が戻り始めたことで、チケット販売が大変賑わうなど、抑えられていた需要が表れている様子を目の当たりにし、私たちも大いに喜んでいます。
そこで、ここで一度振り返ってみてはいかがかと思います。チケット販売を成功させるための、CrowdHandler活用の6つのヒントをご紹介します。
1: 事前にスケジュールを設定し、テストを行う
優先予約の有無や特典、割引の有無にかかわらず、シーズンチケットの販売は複雑なプロセスになり得ることがわかっています。そこで、まず最初にお勧めしたいのは、すべてを慎重にテストするための時間を十分に確保することです。これを行うには、販売開始のスケジュールを事前に設定しておくとよいでしょう。具体的には、販売開始の1時間前に「待機室」を有効にし、その直後にチケット販売システムを稼働させ、公式の販売開始時刻に列が自動的に開始されるように設定します。
「待合室」機能は、チケットを待つためにサイトにアクセスしているユーザーをすべて集め、期待感を高めるカウントダウン付きのプレキューに振り分けます。その間、すべてのチケットを販売開始し、IPバイパス機能を利用して、ユーザーが到着する前にサイトにアクセスすることができます。
嵐の前のこの静かな1時間を活用して、サイトを徹底的にテストしましょう。優先順位コードが正しく機能しているか、また、すべてのユーザーが適切な種類のチケットにアクセスできるかを確認してください。
2: URLパターンマッチングを使用する
サイト全体ではなく、特定のURLのみを制限できる機能は非常に便利です。例えば、単発のチケット販売を行っている場合、特定の公演や一連の公演の座席選択ページへのアクセスを制限しつつ、その他の取引関連機能（シーズンチケットの販売、会員サービス、寄付など）へのアクセスは完全に開放しておきたいといった場面が考えられます。
これを行うには、URLパターンマッチング（「保護するURL」フィールドの編集）を使用して、特定のチケット発行パスだけが制限されるように設定します。
3: VIP専用の優先レーンを設ける
先行販売を実施する場合は、会員や購読者に対して簡単に優先アクセス権を提供できる「優先コード」機能の利用をご検討ください。飛行機の優先搭乗と同様に、CrowdHandlerの優先アクセスシステムでは、コードをお持ちの方全員のために新たなレーンを設けることができます。お使いのシステムに優先予約を管理する機能が十分でない場合でも、この機能を利用すれば、販売にこの便利な機能を簡単に追加することができます。
4: ユーザーとコミュニケーションをとる
メッセージ機能を活用して、販売状況の進捗（どの日程や座席表のどのエリアが売り切れつつあるかなど）を、待合室にいるユーザーに随時お知らせしましょう。待ち行列にいるユーザーに空席状況を伝えることで、ユーザーの平均利用時間を短縮し、チケット販売システムへの負荷を軽減できるほか、ユーザーがサイト内を無駄にクリックし回ることを防ぐことができます。
5: ユーザーフローをオートチューンに制御させる
ユーザーフローという観点から見ると、チケットの販売は、まさに3幕からなる劇のようなものです。
第1段階では、最も積極的なユーザーが購入に成功します。多くのチケット販売サイトがこの段階で苦戦するのは、こうした初期の訪問者が、可能な限り早く、最高のチケットを手に入れようとするためです。
第2幕に入ると、空席は徐々に減り始め、良い席が売り切れていくにつれて、人々は満足のいく席を探すのに時間をかけるようになります。この第2幕の間は、取引のペースが緩むため、より多くのユーザーに対応できる可能性があります。
第3幕では、空席が極めて少なく、残りのわずかな席を巡って争奪戦が繰り広げられるため、観客は席の予約に苦労するようになります。運よく完売した場合、この最終幕では、多数のユーザーが同時に同じ数席をカートに入れようとするため、チケット販売システムに負荷がかかる可能性があります。 もし完売しなかった場合、この頃になると「購入を検討しているだけの人」の第3波が押し寄せますが、ほとんどのチケット購入フローでは、こうしたユーザーを相当数処理することができます。
では、この増減をどのように管理すればよいのでしょうか？手動で判断するのは難しいものです。一定ペースで人を投入していくと、おそらく最初や最後の方ではペースが高くなりすぎてしまうリスクがあり、一方で中盤では必要以上にペースが低くなってしまう可能性があります。
簡単な答え？ ページの反応状況に基づいて、オートチューンに任せてしまえばいいのです。
6：終わらないのは……
セールが終了したら、専用待合室を削除し、汎用待合室を「通常通り」の状態に戻すことができます。ただし、待合室機能を完全に削除することはお勧めしません。予期せぬ緊急事態に備えて、すべてのURLに汎用的な保護措置を講じておくことは、常に賢明な選択だからです。
「予期せぬ緊急事態、ですか？」はい――実は、実話を一つお話しして、この話を締めくくりたいと思います。
ある若手起業家――ここでは彼をジョンと呼ぶことにしよう――が、新しく開催されるフェスティバルのチケット販売業務を引き受けた。ロックダウン解除後のこのイベントが大きな話題になることを予期していた彼は、賢明な判断を下した。CrowdHandlerに登録し、チケットの販売開始と同時に殺到する需要に対応できるよう、待機ルームを設定したのである。
実際、フェスティバルのチケットの販売が開始されるやいなや、アクセス数が急増しました。しかし、ウェイティングルームがこれを処理したため、サイトはスムーズに動作しました。
最初の販売開始後、チケットの販売は落ち着きました。これで任務完了！ しかし――意図したわけではなく、むしろ偶然にも――ジョンは待合室をそのまま残しておいたのです。
彼がそうしておいて本当に良かった。というのも、3週間後、フェスティバルの主催者が予告なしに、大人気のDJがラインナップに加わると発表したからだ。このサプライズ発表がSNSで広まると、最初の発表時よりもはるかに大きな反響を呼び、さらに数千人がサイトに殺到してイベントのチケットを予約した。
ジョンが指一本動かす必要もなかったにもかかわらず（とはいえ、多少の身振りはあっただろうとは思うが）、一般待合室が機能し、すべてが円滑に進んだ。フェスティバル参加者はチケットを予約し、CrowdHandlerがトラフィックを処理し、サイトは正常に稼働し続けた。
ロックダウン解除後の需要を見込んでいるのでしょうか？
ロックダウン解除後の需要を見込んでいますか？チケット販売開始時の待合室の設営を検討していますか？