メインコンテンツまでスキップ

3. 利用開始時のトラブル

利用開始時に問題が発生した場合は、原則としてすぐに返金を行うのではなく、まずユーザーが予定どおりサービスを利用できる状態に復旧できるかを確認します。

対応の優先順位は以下を基本とします。

トラブル発生
  ↓
その場で復旧できるか
  ├─ Yes → 利用継続
  └─ No
       ↓
     代替車両を提供できるか
       ├─ Yes → 車両振替
       └─ No → キャンセル・返金を検討

3.1 車両がない・前利用者が未返却の場合​

対象となるケース​

予約開始時に、ユーザーが予約した車両を利用できないケースを対象とします。

たとえば以下のようなケースがあります。

  • 予約車両が所定の場所にない
  • 前利用者が車両を返却していない
  • 車両が別の場所へ移動されている
  • その他、予約車両をユーザーへ提供できない

対応フロー​

  1. ユーザーからプラットフォームへ連絡が入る
  2. プラットフォーム側で対象予約および対象車両を確認する
  3. プラットフォームからサプライヤーへ車両状況の確認を依頼する
  4. サプライヤー側で実際の車両状況を確認する
  5. 利用可能な代替車両があるか確認する
  6. 代替車両がある場合は、車両振替を案内する
  7. 代替手段がない場合は、対象予約をキャンセルまたは返金対象とする

費用負担​

車両未返却や車両配置等、車両運用上の事情によって予約車両を提供できなかった場合の返金については、原則としてサプライヤー負担となります。

3.2 Bluetooth等の接続不良​

基本方針​

Bluetooth等のシステム接続不良が発生した場合は、接続できないことだけを理由に直ちに返金するのではなく、まずプラットフォーム側で原因を確認し、復旧を試みます。

対応フロー​

  1. ユーザーからプラットフォームへ問い合わせが入る
  2. プラットフォーム側で対象予約を確認する
  3. ログやシステムの状態を確認する
  4. プラットフォーム側で解決可能な場合は、その場で復旧対応を行う
  5. 復旧できない場合は、利用可能な代替車両があるか確認する
  6. 代替車両がある場合は、車両振替を案内する
  7. 代替車両もなく、最終的にサービスを利用できない場合は、キャンセル・返金を検討する

費用負担​

返金が必要になった場合は、最終的な原因に応じて費用負担を判断します。

  • プラットフォームのシステム障害に起因する場合 → プラットフォーム負担

  • 車両側の機器不備等に起因する場合 → サプライヤー負担

  • 原因を明確に判断できない場合 → システムログ、車載機器の状態、車両の管理履歴を双方で確認して決定