商品データを二重入力しない
商品の正は基幹に置き、Webへは取り込んで使います。二重登録をなくす設計から始めます。
旅行会社向けCMS
旅行商品は数が多く、入れ替わりが速い。半期で1万を超えるツアーを扱う事例もあります。商品には催行日と販売終了があり、売り場は自社サイトだけではない。この構造を前提に、writeWiredで旅行会社のサイトをどう設計してきたかを、実際の導入事例をもとに整理しました。
では、その情報の流れをどう設計すればいいのか。
旅行商品の情報は、基幹システムで生まれます。基本情報、価格、催行日。これをWeb掲載のためにもう一度入力するのは、商品の数を考えれば現実的ではありません。だから設計の起点は「基幹が正、Webは受けて見せる」に置きます。商品データは基幹から定期的に取り込み、Web側は検索と見せ方を受け持つ。PR文や紹介文など、基幹にない情報だけをCMSで登録します。
取り込んだ商品は、自社サイトだけでなく、複数の販売サイトやメールにも同じ情報源から出します。売り場が増えるたびに、同じ商品情報を入力し直す必要はありません。日々の更新は、本社のWeb担当一人に集めません。特集の入れ替えや支店の紹介は、支店の営業や窓口の担当者が、デザインを崩さずに直せる形にしておきます。
そして旅行商品には期限があります。催行日が過ぎた商品、販売を終えた商品が掲載に残れば、誤った申込やリンク切れになります。載せる速さと同じだけ、下げる仕組みを設計に含めます。この流れができると、商品が増えた分だけ、運用の手間まで増える構造を避けられます。
この流れは、それぞれ独立した用途として設計できます。下の6つは、旅行業のWeb運用で組み合わせられる設計です。いま自社で起きている課題から入ってください。
商品の正は基幹に置き、Webへは取り込んで使います。二重登録をなくす設計から始めます。
ツアーサイトと航空券サイト、Webとメール。一つの情報源から複数の出口へ出します。
触れる範囲を決めておけば、支店や窓口の担当者でもデザインを崩さず更新できます。
入力画面を部署や役割で分け、特集は本社、商品の入れ替えは支店、と持ち場を決めます。
季節ごとの特集、行き先ごとの紹介。増えることを前提にした器で受けます。
申込フォームからの受付を、担当の部署や支店へ確実に渡します。