旅行会社向けCMS

常時800件ほどのツアーを扱い、新商品や料金変更、販売終了が毎日のように発生しています。商品情報は社内の商品管理システムにあるのに、Web担当者が一件ずつ登録し直していては、変更を反映するだけで一日が終わってしまいます。

writeWiredでは、ツアー商品を項目ごとのコンテンツとして管理し、商品管理システムから出力したCSVをまとめて取り込めます。新商品は新規登録用、料金や日程の変更は更新用のCSVに分け、変更する項目だけを更新します。Web独自の紹介文など、CSVに含めない項目はそのまま残せます。

人手での取り込みをなくす場合は、商品管理システムから定期的にデータを取得し、変換・登録する連携処理を個別に開発します。何をどの頻度で取得できるかは相手の仕組みによるため、まずCSVで運用を確かめ、その後で自動化する方法も選べます。

販売が終わった商品をサイトから取り下げたいものの、提携先や過去の案内から、その商品のURLへアクセスする人がいます。ページを消さずに残した場合、申込できる商品だと誤解されないようにするには、どうすればよいのでしょうか。

writeWiredでは、商品に「販売状況」の項目を持たせ、販売終了になった場合に表示を切り替えるテンプレートを構築できます。商品ページには「販売終了」と表示して申込ボタンを出さず、同じ方面やテーマの販売中のツアーを案内する構成にできます。

この方法では商品ページ自体は公開を続けるため、URLを残せます。一方、商品一覧や特集、検索画面は販売中の商品だけを表示する条件で構築します。販売終了の表示切り替えは、標準の掲載終了日時だけで実現するものではなく、商品項目とテンプレートの設計が必要です。

旅行商品の料金や販売状況を変更したとき、自社サイトだけでなく、提携先の販売サイトやメールマガジンにも新しい情報を使いたいところです。同じ商品データから提供すれば、すべての掲載先が同時に更新されるのでしょうか。

writeWiredでは、自社サイトの商品ページや条件で構成した特集は、商品データの変更を次の表示から反映できます。提携先にはJSONのAPIで商品情報を提供する構成を用意でき、提携先が次に取得したときに更新後の情報を渡せます。ただし、提携先が取得したデータを保存している場合、その更新は提携先側の処理になります。

メールマガジンでは、商品名や料金などをCMSから取り出す部品をテンプレートに用意できます。ただし、メールは送信へ進んだ時点の内容で確定し、送信済みのメールは変わりません。また、提携先の予約・在庫・料金の連携は別の仕組みで扱う場合があるため、writeWiredが受け持つ範囲を導入時に確認する必要があります。

「温泉旅行」「紅葉の旅」「冬の旅行」などの特集ページを作りたい。しかし、新しいツアーが追加されたり、販売終了や料金変更が発生したりするたびに、特集に並べた商品を手作業で入れ替えるのは大変です。

writeWiredでは、商品に方面、テーマ、出発時期などの項目を持たせ、特集ページには商品そのものではなく検索条件を登録する仕組みを構築できます。例えば「九州の温泉」「12月出発の冬の旅行」といった条件で、その時点で販売中の商品を一覧にします。

新商品が条件に合えば特集に表示され、料金を変更すれば次の表示から反映されます。販売終了した商品は、販売中という条件から外れます。ただし、検索条件に使う属性はあらかじめ商品データに用意する必要があり、条件の組み合わせ方や表示順は構築時に設計します。

毎日の商品データの取り込みを自動化しても、途中でエラーになった商品があれば、古い料金や販売状況がWebに残るかもしれません。Web担当者が一人の場合、取り込みが失敗したことに気づけるかどうかも重要です。

writeWiredでは、CSV取込の実行結果をバッチ一覧で確認でき、状態、成功・失敗の件数、エラー内容を調べられます。詳細レポートを取得すれば、どの行がどんな理由で取り込めなかったかを確認できます。更新の取込では、エラーの行があっても正しい行は反映されるため、エラーのあった商品を直して取り込み直せます。

定期的な連携処理を構築する場合は、実行結果をバッチ一覧に残し、失敗時に担当者へ通知メールを送る仕組みも組み込めます。ただし、通知や取り込み直しは自動的に備わるものではありません。誰に知らせ、どのデータを再処理するかを、連携処理の要件として決める必要があります。

商品データの取り込み処理が正常に終わっていても、商品管理システムで販売終了となった商品がWebでは販売中のまま残ることがあります。更新データそのものが届かなかった場合、取込エラーを調べるだけでは見つけられません。

writeWiredでは、商品管理システムと共通の商品コードを商品情報に持たせ、Web側のデータをCSVで出力できます。商品管理システム側からも全商品の現在の状態を取り出し、商品コードごとに販売状況を突き合わせれば、反映漏れを確認できます。

ただし、毎日の変更分だけでは、届かなかった販売終了の情報を見つけられません。全商品の現在の状態を取得できることが前提になります。照合を自動化したい場合は、商品管理システムからの全件取得と比較処理を個別に構築する必要があります。

販売終了の更新データが届かなかった場合でも、販売してはいけないツアーへの申込は止めたい。一方で、商品ページを掲載終了にするとURLが使えなくなるため、販売終了の案内は残したいところです。

writeWiredでは、商品に「販売状況」とは別に「販売の最終日」を持たせ、表示時にその日付を確認するテンプレートを構築できます。最終日を過ぎた商品には「販売終了」と表示して申込ボタンを出さず、一覧や特集でも販売の最終日を条件に含めます。ページそのものは公開を続けるため、URLを残せます。

ただし、最終日によって止められるのは、あらかじめ終了日が決まっている販売です。予定より早い打ち切りには、商品管理システムとの照合が必要になります。また、販売の最終日が最終出発日なのか販売締切日なのか、商品管理システム側の定義と一致させなければなりません。