「運転代行をアプリで呼ぶことができる」なんか便利な気がする！
これは本質ではない。
アプリ開発者がクリアした最も大きな壁は、受発注の交通整理を合理的な手法で実現したことではないだろうか。
一つ前の投稿で、局所的に需要に供給が追いつかない状況が生まれると話した。実際にそうなのだが、細かく見ていくことで見え方が少し変わる。
まずは現状の整理。
①利用客は、電話で知っている数社に問い合わせる。A社、B社、C社
②利用客からの依頼を受け飲食店が、電話で数社に問い合わせる。D社、E社、F社
福井の運転代行の利用者は、たいていはこの2パターンになる。このとき、利用者一人で電話できる数には限界があり、何十社も電話をかけるのは稀だろう。
このアナログな方法を全員が行うと、偶然A〜Fに含まれなかった業者や、一度受注を断ったものの、受注済みの顧客からの突然のキャンセルなどで新規受注が可能になった業者が発生する。
この状況を①②の方法で効率よくマッチングさせるのはほぼ不可能であり、逆にマッチさせる仕組みを作ったのが代行アプリである。
代行アプリでは、利用者サイドから見た場合、発注をかけると登録事業者全体に通知が行き、その瞬間に受注可能な事業者と効率よくマッチングできる。
運転代行業者から見ると、
受注した時点で利用者の決済が確定するため、自社のリソースさえ余裕があれば安心して受注できる。この「安心して受注できいる」という点をアプリではうまく解決している。
これまでも同様のサービスを作ろうとした方達がいたが、うまく機能しなかったのはこの点に不安を抱えていたからである。
ここで、その不安を具体的する事例を挙げたい。以下事例は運転代行事業者の目線である。
客から本部に入電、まずは仮発注が入る、それに対しA社は15分・B社は25分で現着できると回答する。
本部は、客に時間の伺いを立て、細かな情報を聞き、A社B社に返答する。この間短くても5分は要する。
その間、たまたまA社B社にはそれぞれ常連客から入電する。しかしそれを受けることはできない。なぜなら本部からの回答によってはそちらに行かなければならないから。
ここでA社B社に回答が来る。受注したのは5分で現着できるC社であった。
時間の切り売りを商売とする運転代行業社にとって、この時のA社B社の機会損失は大きな痛手となる。
ここで問題になるのは２点
・客と事業者の間に中継ぎ役の「人間」が介入すること
・客に「伺い」を立てること
これが仮受注から本受注までのタイムラグを作り、そのタイムラグが運転代行事業者にとっては死活問題なのである。
アプリでは上記２点を、顧客情報の先出し、システムによる事前決済と受注の先着順化という方法で綺麗にクリアしている。
この仕組みは運転代行のみならず、現在推進されているライドシェアや物流業界へそのまま転用され、今後大きく普及するのではないだろうか。
Comments