在庫を、ひとつに合わせる。

在庫連動そのものは、お客様を連れてきません。増える余地があるのは、売れる車があるのに閉じていた枠の分です。返却日・紐づいていない商品・送信していないサイト・クラス商品を順に見ます。

リードタイムの中央値は26日。3か月より前に受け付けた予約は、半分近くが取り消されていました。予約データの集計から、在庫を何日先まで出すかを考えます。

作る前には見えなかった6つの落とし穴を、実装した側から書きます。難しいのは送信ではなく、その手前にあります。自作したほうがよい場合も書きました。

レンタカーの在庫は2つの層に分かれます。クラスで予約が入っても、どの車の在庫も減りません。販売してよい数がどう決まるのかを、計算の順序から整理しました。

車両数・延貸渡回数・延貸渡日車数・延走行キロ・総貸渡料金。5つとも数え方が違います。年度をまたぐ貸渡しの分け方と、走行キロが分からないときの扱いまで。

開くのは、返す予定の日が過ぎたときです。なぜ実際の返却を待たない設計なのか、返却の遅れと延長がどこで在庫に効くのかを、仕組みの側から整理しました。

比較記事でよく見る言葉が「一元管理」です。ただ、予約を1画面に集めることと、在庫を各販売サイトへ書き戻すことは別の機能です。9製品の公開情報を、確認日つきで並べました。

「サイトコントローラー」で検索すると、出てくるのは宿の製品ばかりです。同じ仕組みで車も扱えるのか。答えは「目的は同じだが、在庫の数え方が違う」です。返却日の扱いと車種グループという2つの違いを解説します。

複数の販売サイトの在庫をひとつの台帳にまとめ、予約が入った分だけ他サイトの在庫を閉じる仕組みです。なぜサイト同士を直接つながないのか、扱うサイトが増えると何が起きるのかを、組み合わせの数から説明します。

連携を入れる一番の不安は「初日に在庫を書き換えられること」です。観測モードで差分だけを見て、台帳の取り込みと在庫の照合を済ませてからサイトごとに送信を有効にする5つの手順を解説します。

多すぎれば売り逃し、少なすぎれば二重予約。同期の合間に入る予約をどう見積もるかという話です。決め方の4つの材料と、残す台数を送信の直前ではなく台帳の基準で表す理由を解説します。

予約1件につき、直す先はサイト数から1を引いた数だけ発生します。手が回らなくなるのは集中力ではなく件数の問題です。ズレる5つの原因と、構造で防ぐ考え方を解説します。

つくっている私たち自身も沖縄でレンタカーを運営しています。販売チャネルは2つだけ。その台帳を開いたら、同じ車種が別の表記で二重に並んでいました。

改善の出発点は機能要望ではなく、表の数字への違和感でした。沖縄のレンタカー事業者 White one からの指摘で、在庫の数え方と保存の仕組みがどう変わったかの記録です。