JP2021182293A - 配送マッチングシステム - Google Patents
配送マッチングシステム Download PDFInfo
- Publication number
- JP2021182293A JP2021182293A JP2020087804A JP2020087804A JP2021182293A JP 2021182293 A JP2021182293 A JP 2021182293A JP 2020087804 A JP2020087804 A JP 2020087804A JP 2020087804 A JP2020087804 A JP 2020087804A JP 2021182293 A JP2021182293 A JP 2021182293A
- Authority
- JP
- Japan
- Prior art keywords
- delivery
- shipper
- request
- package
- person
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000000034 method Methods 0.000 claims abstract description 101
- 238000012545 processing Methods 0.000 claims abstract description 58
- 238000007726 management method Methods 0.000 claims description 14
- 238000011156 evaluation Methods 0.000 claims description 12
- 238000004590 computer program Methods 0.000 claims description 11
- 230000004044 response Effects 0.000 abstract description 5
- 230000008569 process Effects 0.000 description 89
- 230000005540 biological transmission Effects 0.000 description 13
- 230000008901 benefit Effects 0.000 description 6
- 238000004364 calculation method Methods 0.000 description 6
- 238000012552 review Methods 0.000 description 6
- 230000000694 effects Effects 0.000 description 5
- 125000002066 L-histidyl group Chemical group [H]N1C([H])=NC(C([H])([H])[C@](C(=O)[*])([H])N([H])[H])=C1[H] 0.000 description 3
- 238000010586 diagram Methods 0.000 description 3
- 230000009467 reduction Effects 0.000 description 3
- 230000002040 relaxant effect Effects 0.000 description 2
- 239000002699 waste material Substances 0.000 description 2
- 239000008280 blood Substances 0.000 description 1
- 210000004369 blood Anatomy 0.000 description 1
- 230000003247 decreasing effect Effects 0.000 description 1
- 229940124447 delivery agent Drugs 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 230000002349 favourable effect Effects 0.000 description 1
- 230000006872 improvement Effects 0.000 description 1
- 238000005259 measurement Methods 0.000 description 1
- 230000001404 mediated effect Effects 0.000 description 1
- 238000005057 refrigeration Methods 0.000 description 1
- 238000012795 verification Methods 0.000 description 1
Images
Landscapes
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
Abstract
【課題】 荷主と配送者とをマッチングさせる方法を提供する。【解決手段】 荷物の配送を依頼する荷主と、該荷物を配送する配送者とをマッチングさせる配送マッチングシステムであって、同一料金で配送可能な範囲として設定された複数の拠点と、該拠点間の基準料金とを記憶する拠点データベースと、前記拠点のうち前記荷物を発送する引受拠点、前記拠点のうち前記荷物を届ける納品拠点を含み、荷物ごとの重量および寸法を含まない配送依頼を前記荷主から受け付ける配送依頼受付部と、前記配送依頼を、前記配送者に送信するとともに、前記配送者から該配送依頼を受諾する旨の応答を受けた場合には、両者をマッチングさせるマッチング処理部とを備えることを特徴とする。【選択図】 図1
Description
本発明は、配送サービスにおいて、荷主と配送者とをマッチングさせる方法に関する。
荷物の配送サービスにおいて、種々の求貨求車システム、すなわち配送マッチングシステムが知られ、現に利用されている。主なものとして、空車を探す荷物の荷物情報と荷物を探す配送会社の空車情報をインターネット上でマッチングさせるものがある。例えば、特許文献1は、車主が受け付け可能な荷物の条件を登録しておき、荷主が配送を希望する荷物について名称、積地、降地などの荷物情報を登録すると、この荷物を受け付け可能な車主に、荷物情報が配信されることで、両者のマッチングを行う技術を開示する。特許文献2は、タクシーの共同配車システムにおいて、顧客から配車要求を受け付けると、まず、これに合致する自社のタクシーを検索し、見つからなかった場合は、他社のタクシーを検索するという技術を開示する。
しかし、従来の配送マッチングシステムでは、荷主は、荷物の情報を詳細に入力しなければ配送依頼をすることができず、利便性に欠けていた。
本発明の課題は、上記従来の実情に鑑み、配送依頼を行う際の入力を軽減し、配送マッチングシステムの利便性を向上させることを目的とする。
本発明の課題は、上記従来の実情に鑑み、配送依頼を行う際の入力を軽減し、配送マッチングシステムの利便性を向上させることを目的とする。
本発明は、荷物の配送を依頼する荷主と、該荷物を配送する配送者とをマッチングさせる配送マッチングシステムであって、
同一料金で配送可能な範囲として設定された複数の拠点と、該拠点間の基準料金とを記憶する拠点データベースと、
前記拠点のうち前記荷物を発送する引受拠点、前記拠点のうち前記荷物を届ける納品拠点を含み、荷物ごとの重量および寸法を含まない配送依頼を前記荷主から受け付ける配送依頼受付部と、
前記配送依頼を、前記配送者に送信するとともに、前記配送者から該配送依頼を受諾する旨の応諾を受けた場合には、両者をマッチングさせるマッチング処理部と、
前記荷物の配送に関して、前記基準料金に基づいて前記荷主への課金処理と、前記配送者への支払い処理とを行う精算処理部とを備えることを特徴とする。
同一料金で配送可能な範囲として設定された複数の拠点と、該拠点間の基準料金とを記憶する拠点データベースと、
前記拠点のうち前記荷物を発送する引受拠点、前記拠点のうち前記荷物を届ける納品拠点を含み、荷物ごとの重量および寸法を含まない配送依頼を前記荷主から受け付ける配送依頼受付部と、
前記配送依頼を、前記配送者に送信するとともに、前記配送者から該配送依頼を受諾する旨の応諾を受けた場合には、両者をマッチングさせるマッチング処理部と、
前記荷物の配送に関して、前記基準料金に基づいて前記荷主への課金処理と、前記配送者への支払い処理とを行う精算処理部とを備えることを特徴とする。
本発明は、配送元、配送先が各拠点内にある限り、拠点間の配送については、荷物に依らず基準料金に基づいて課金がなされる。従って、本発明によれば、荷主は、荷物ごとの重量および寸法を入力するまでなく、配送元と配送先などの必要最小限の情報を登録して配送依頼を行うことができる。荷物ごとの重量および寸法は、重量、サイズなど、荷物の計測を伴う情報が求められることが多いため、荷物ごとの重量および寸法を省略できるということは、配送依頼を行う際の手間を軽減し、非常に簡便に配送者を探すことができる。
なお、本発明において、例えば、配送を依頼する荷物に、重量物、貴重品、特大サイズ物品が含まれるか否かといった情報を含めることは、差し支えない。かかる情報を含めたとしても、荷物ごとの計測をする必要はないため、配送依頼の負担を増やすものではないからである。
なお、本発明において、例えば、配送を依頼する荷物に、重量物、貴重品、特大サイズ物品が含まれるか否かといった情報を含めることは、差し支えない。かかる情報を含めたとしても、荷物ごとの計測をする必要はないため、配送依頼の負担を増やすものではないからである。
本発明において、拠点とは、ある特定の営業所などを意味するのではなく、一定の広さを有する範囲を意味する。例えば、東京都、名古屋市などのように行政界に基づいて設定してもよい。この場合は、東京都内から名古屋市内への配送であれば、配送元、配送先がどの住所であっても、基準料金が適用されることになる。拠点は、特定の地点から半径○kmの円内というように定めても良い。その他、任意の方法で決めることができる。また、複数の拠点の広さは、同一である必要はない。
拠点が3以上存在する場合、いずれの拠点間でも共通の基準料金としてもよいし、拠点に応じて異なる基準料金としてもよい。同じ拠点間に対して、往復で異なる基準料金を用いてもよい。
また、基準料金は固定料金とは異なる。基準料金に対して、後述する通り、所定の条件で割増、割引を適用してもよい。
拠点が3以上存在する場合、いずれの拠点間でも共通の基準料金としてもよいし、拠点に応じて異なる基準料金としてもよい。同じ拠点間に対して、往復で異なる基準料金を用いてもよい。
また、基準料金は固定料金とは異なる。基準料金に対して、後述する通り、所定の条件で割増、割引を適用してもよい。
引受拠点は荷物を発送する拠点内の住所地、納品拠点は荷物を届ける住所地を意味する。
配送依頼には、この他、集荷日時や配送日時などの情報を含めても良い。日常的に繰り返し荷物を発送するような場合には、集荷日時を指定することを省略可能としてもよい。
配送依頼には、この他、集荷日時や配送日時などの情報を含めても良い。日常的に繰り返し荷物を発送するような場合には、集荷日時を指定することを省略可能としてもよい。
また、本発明は、前記配送マッチングシステムにおいて、
前記マッチング処理部は、予め登録された車両情報または配送者の属性が配送依頼に応じた条件に合致する配送者にのみ前記配送依頼を送信するシステムとすることもできる。
前記マッチング処理部は、予め登録された車両情報または配送者の属性が配送依頼に応じた条件に合致する配送者にのみ前記配送依頼を送信するシステムとすることもできる。
そうすることにより、一部の配送者に絞って配送依頼を送信することができる。例えば、荷主に有利となる配送者に絞って配信すれば、荷主に有利にマッチングさせることができる。また、それぞれの配送者にとって有利な条件の配送依頼のみを配信すれば、応諾率を向上させることができ、結果として荷主の選択の余地を広げることができる。
また、本発明において、前記マッチング処理部は、時間の経過とともに段階に前記条件を緩和して前記配送依頼を送信するシステムとすることもできる。
そうすることにより、一部の配送者を優先してマッチングさせるとともに、優先して配送依頼を通知した配送者により受諾の応答がなかった場合においても、配送契約を成立させる可能性を高めるという効果を合わせもつことができる。
上記態様において、条件を緩和するタイミングは、種々の設定が可能である。例えば、予め定めた時間を経過してもマッチングが成立していないときに、条件を緩和してもよい。また、応諾件数が所定数に達してもマッチングが成立していないときに、条件を緩和してもよい。その他、種々のタイミングをとり得る。
上記態様において、条件を緩和するタイミングは、種々の設定が可能である。例えば、予め定めた時間を経過してもマッチングが成立していないときに、条件を緩和してもよい。また、応諾件数が所定数に達してもマッチングが成立していないときに、条件を緩和してもよい。その他、種々のタイミングをとり得る。
また、本発明は、前記配送者を絞り込む条件として、帰り便という条件を用いるシステムとすることもできる。
帰り便とは、ある拠点まで配送を終えた後、自身の拠点に帰ろうとする配送者を利用することを言う。帰り便は、配送者にとっては、復路においても荷物を積載して無駄なく配送することが可能となる利点がある。また、その分、配送料を安価にできれば、荷主にとっても利点がある。上記態様では、このように利点の高い帰り便を優先してマッチングさせることが可能となる。
また、本発明は、さらに、前記マッチング処理部は、前記配送依頼に応諾した配送者のいずれかを制限時間内に荷主が選定しない場合には、所定の条件に基づいて応諾した配送者のいずれかを選定して前記荷主とマッチングさせるシステムとすることもできる。
そうすることにより、荷主が任意の配送者を選定することができ、何らかの理由により選定しない場合においてもマッチングさせることが可能となり、マッチングの成立可能性を向上させることができる。
配送者を選定するための条件は、種々の設定が可能である。例えば、料金が安い配送者、応諾が早かった配送者などとしてもよい。また、過去の配送依頼に対する評価が高い配送者としてもよい。
上記態様は、逆に言えば、制限時間に至るまでは、荷主は、応諾してきた複数の配送者から任意に相手を選択可能であることになる。このように制限時間を設けることにより、荷主は、配送者が応諾してきた時点で速やかに依頼するか否かを判断する必要がなくなり、自身にとって、より有利な配送者が応諾するのを待つことが可能となる。
配送者を選定するための条件は、種々の設定が可能である。例えば、料金が安い配送者、応諾が早かった配送者などとしてもよい。また、過去の配送依頼に対する評価が高い配送者としてもよい。
上記態様は、逆に言えば、制限時間に至るまでは、荷主は、応諾してきた複数の配送者から任意に相手を選択可能であることになる。このように制限時間を設けることにより、荷主は、配送者が応諾してきた時点で速やかに依頼するか否かを判断する必要がなくなり、自身にとって、より有利な配送者が応諾するのを待つことが可能となる。
また、本発明は、前記精算処理部は、帰り便の条件によりマッチングさせた場合は、前記基準料金よりも割り引いた料金を適用するシステムとすることもできる。
上記態様において、割引率は、配送システムが設定してもよいし、配送者が任意に設定してもよい。
また、割引率は、拠点にかかわらず一定としてもよいし、配送元、配送先の拠点に応じて変化させてもよい。
また、割引率は、拠点にかかわらず一定としてもよいし、配送元、配送先の拠点に応じて変化させてもよい。
本発明は、さらに、前記精算処理部は、荷主が、配送に利用される車種を限定した場合は、限定に応じて基準料金よりも割り増した料金を適用するシステムとすることもできる。
上記態様において、割増率は、配送システムが設定してもよいし、配送者が任意に設定してもよい。
また、割増率は、車種にかかわらず一定としてもよいし、車種ごとに変化させてもよい。
また、割増率は、車種にかかわらず一定としてもよいし、車種ごとに変化させてもよい。
そして、本発明は、さらに、前記精算処理部は、荷主が配送者を選定した後に配送者がキャンセルした場合の再配送依頼に対しては、基準料金よりも割り引いた料金を適用するシステムとすることもできる。
配送者によって配送がキャンセルされることは、荷主に不利益を与えるとともに、配送サービスに対する信頼喪失にもつながるおそれがある。上記態様では、かかる事態に、荷主に割り引いた料金を提示することができるため、キャンセルによって荷主が受けた不利益を緩和することができる。
配送料を割り引くことによる損失は、新たな配送者が負うものとしてもよいが、配送をキャンセルした配送者に負わせても良い。本発明では、配送システムが、荷主に対する課金と、配送者に対する支払いとを実行するため、例えば、配送をキャンセルした時点で、配送者から制裁金を徴収し、これを割り引いた分の配送料に補填するようにすればよい。こうすれば、荷主には割引料金を適用しつつ、新たな配送者には、正規料金で支払いを行うことが可能となる。
配送料を割り引くことによる損失は、新たな配送者が負うものとしてもよいが、配送をキャンセルした配送者に負わせても良い。本発明では、配送システムが、荷主に対する課金と、配送者に対する支払いとを実行するため、例えば、配送をキャンセルした時点で、配送者から制裁金を徴収し、これを割り引いた分の配送料に補填するようにすればよい。こうすれば、荷主には割引料金を適用しつつ、新たな配送者には、正規料金で支払いを行うことが可能となる。
また、本発明は、前記マッチング処理部は、前記配送依頼に応諾した配送者の属性を前記荷主に提示するシステムとすることもできる。
こうすれば、荷主は、配送者の属性を確認して、配送を依頼する配送者を選択することができる。属性としては、配送者が使用している車種の情報、配送者の自己PR情報などを含めることができる。
本発明は、さらに、前記配送者の属性には、過去に配送依頼を行った荷主による該配送者に対する評価が含まれるシステムとすることもできる。
こうすれば、過去の実績に対する客観的な情報を踏まえて配送者を選定することが可能となる。
そして、本発明は、さらに、
前記配送者の属性の登録内容を前記配送者から受け付けて反映させるためのプロフィール登録部を有し、
前記精算処理部は、前記登録内容に応じて、該配送者への支払い条件を変動させるシステムとすることもできる。
前記配送者の属性の登録内容を前記配送者から受け付けて反映させるためのプロフィール登録部を有し、
前記精算処理部は、前記登録内容に応じて、該配送者への支払い条件を変動させるシステムとすることもできる。
そうすることにより、荷主側がよりよいサービス提供を求めて、依頼したい配送者を選定することが可能となる。配送者側は、よりよいサービスの提供を掲げることにより、全体として、本システムにより提供される配送サービスの向上が図られる。
また、本発明は、前記配送者の車両の位置情報に基づき、該車両が前記引受住所地に至った後、所定の距離以上ずれたことを検出した場合に、前記荷物の前記配送者による引受完了として、前記配送を管理する配送管理部を備えるシステムとすることもできる。
本発明においては、荷主と配送者とをマッチングさせた後、荷物の引渡から配送が完了するまでの配送管理を行うことが好ましい。このとき、荷主の配送者への引渡を適切に管理するためには、その旨の入力を、配送者ではなく荷主に行わせることが好ましいと言える。
しかし、この場合、今度は、荷主が、引渡完了の操作を失念した場合、配送管理に支障が生じることになる。上記態様では、配送者の位置情報に基づいて、荷物の引受場所に訪れた後、所定の距離離れたという事実を検出したときは、引渡が完了したものと扱うため、荷主が操作を失念した場合でも、配送管理に支障が生じることを回避できる。
しかし、この場合、今度は、荷主が、引渡完了の操作を失念した場合、配送管理に支障が生じることになる。上記態様では、配送者の位置情報に基づいて、荷物の引受場所に訪れた後、所定の距離離れたという事実を検出したときは、引渡が完了したものと扱うため、荷主が操作を失念した場合でも、配送管理に支障が生じることを回避できる。
本発明においては、以上で説明した種々の特徴を必ずしも全て備えている必要はなく、適宜、その一部を省略したり組み合わせたりすることができる。
また、本発明は、システムとしての態様に限らず、荷主と配送者とをマッチングさせる方法として構成することもできる。
その場合、
コンピュータにより、荷物の配送を依頼する荷主と、該荷物を配送する配送者とをマッチングさせるマッチング方法であって、
コンピュータが実行するステップとして、
同一料金で配達可能な範囲として設定された複数の拠点と、該拠点間の基準料金とを記憶するステップと、
前記拠点のうち前記荷物を発送する引受拠点、前記拠点のうち前記荷物を届ける納品拠点を含み、荷物ごとの重量および寸法を含まない配送依頼を前記荷主から受け付けるステップと、
前記配送依頼を、前記配送者に送信するとともに、前記配送者から該配送依頼を受諾する旨の応答を受けた場合には、両者をマッチングさせるステップとを備えるマッチング方法と構成することができる。
また、本発明は、システムとしての態様に限らず、荷主と配送者とをマッチングさせる方法として構成することもできる。
その場合、
コンピュータにより、荷物の配送を依頼する荷主と、該荷物を配送する配送者とをマッチングさせるマッチング方法であって、
コンピュータが実行するステップとして、
同一料金で配達可能な範囲として設定された複数の拠点と、該拠点間の基準料金とを記憶するステップと、
前記拠点のうち前記荷物を発送する引受拠点、前記拠点のうち前記荷物を届ける納品拠点を含み、荷物ごとの重量および寸法を含まない配送依頼を前記荷主から受け付けるステップと、
前記配送依頼を、前記配送者に送信するとともに、前記配送者から該配送依頼を受諾する旨の応答を受けた場合には、両者をマッチングさせるステップとを備えるマッチング方法と構成することができる。
さらに、本発明は、荷主側端末機あるいは配送者側端末機に用いられるコンピュータプログラムと構成することもできる。
この場合、
荷物の配送を依頼する荷主と、該荷物を配送する配送者とをマッチングさせる配送マッチングシステムにおいて、システムサーバに接続され、前記荷主が利用する荷主側端末機に用いられるコンピュータプログラムであって、
同一料金で配達可能な範囲として設定された複数の拠点と、該拠点間の基準料金とを参照する機能と、
前記拠点のうち前記荷物を発送する引受拠点、前記拠点のうち前記荷物を届ける納品拠点を含み、荷物ごとの重量および寸法を含まない配送依頼を送信する機能と、
前記配送依頼に対する前記配送者とのマッチングの結果を受信して表示する機能とを実現するコンピュータプログラム、
あるいは、
荷物の配送を依頼する荷主と、該荷物を配送する配送者とをマッチングさせる配送マッチングシステムにおいて、システムサーバに接続され、前記配送者が利用する配送者側端末機に用いられるコンピュータプログラムであって、
前記拠点のうち前記荷物を発送する引受拠点、前記拠点のうち前記荷物を届ける納品拠点を含み、荷物ごとの重量および寸法を含まない配送依頼を受信して表示する機能と、
前記配送依頼を受諾する旨の指示を送信する機能とを実現するコンピュータプログラムと構成することができる。
この場合、
荷物の配送を依頼する荷主と、該荷物を配送する配送者とをマッチングさせる配送マッチングシステムにおいて、システムサーバに接続され、前記荷主が利用する荷主側端末機に用いられるコンピュータプログラムであって、
同一料金で配達可能な範囲として設定された複数の拠点と、該拠点間の基準料金とを参照する機能と、
前記拠点のうち前記荷物を発送する引受拠点、前記拠点のうち前記荷物を届ける納品拠点を含み、荷物ごとの重量および寸法を含まない配送依頼を送信する機能と、
前記配送依頼に対する前記配送者とのマッチングの結果を受信して表示する機能とを実現するコンピュータプログラム、
あるいは、
荷物の配送を依頼する荷主と、該荷物を配送する配送者とをマッチングさせる配送マッチングシステムにおいて、システムサーバに接続され、前記配送者が利用する配送者側端末機に用いられるコンピュータプログラムであって、
前記拠点のうち前記荷物を発送する引受拠点、前記拠点のうち前記荷物を届ける納品拠点を含み、荷物ごとの重量および寸法を含まない配送依頼を受信して表示する機能と、
前記配送依頼を受諾する旨の指示を送信する機能とを実現するコンピュータプログラムと構成することができる。
さらに、本発明は、上述のコンピュータプログラムを記録したコンピュータで読み取り可能な記録媒体として構成してもよい。
以下、本発明の実施形態の一例としての配送マッチングシステムを添付の図面を参照して、以下の順序で説明する。
A.全体構成:
B.データベース構造:
C.配送サービスの全体処理:
C−1.プロフィール登録処理:
C−2.配送依頼処理:
C−3.マッチング処理:
C−4.応諾処理:
C−5.キャンセル処理:
C−6.荷物引受処理:
C−7.配送完了処理:
C−8.料金計算処理:
D.効果および変形例:
A.全体構成:
B.データベース構造:
C.配送サービスの全体処理:
C−1.プロフィール登録処理:
C−2.配送依頼処理:
C−3.マッチング処理:
C−4.応諾処理:
C−5.キャンセル処理:
C−6.荷物引受処理:
C−7.配送完了処理:
C−8.料金計算処理:
D.効果および変形例:
A.全体構成:
図1は、配送マッチングシステム全体の構成を示す説明図である。本システム全体は、システムサーバ100、荷主側端末200、配送者側端末300及びこれらを繋ぐインターネットなどのネットワークで構成される。
荷主側端末200、配送者側端末300は、インターネットを介した情報の授受が可能な携帯電話、スマートフォン、タブレットなどの携帯端末を利用できる。携帯性を重視しない場合は、コンピュータを用いても良い。
配送マッチングシステムは、荷主が、荷物の配送を希望するときに、荷主側端末200から配送依頼をシステムサーバ100に送信すると、システムサーバ100が、その配送依頼を配送者側端末300に送信し、荷主と配送者とをマッチングさせるシステムである。図の例では、荷主側端末200、配送者側端末300をそれぞれ1つだけ示しているが、これらは、荷主、配送者ともに利用者の数だけ存在する。
図1は、配送マッチングシステム全体の構成を示す説明図である。本システム全体は、システムサーバ100、荷主側端末200、配送者側端末300及びこれらを繋ぐインターネットなどのネットワークで構成される。
荷主側端末200、配送者側端末300は、インターネットを介した情報の授受が可能な携帯電話、スマートフォン、タブレットなどの携帯端末を利用できる。携帯性を重視しない場合は、コンピュータを用いても良い。
配送マッチングシステムは、荷主が、荷物の配送を希望するときに、荷主側端末200から配送依頼をシステムサーバ100に送信すると、システムサーバ100が、その配送依頼を配送者側端末300に送信し、荷主と配送者とをマッチングさせるシステムである。図の例では、荷主側端末200、配送者側端末300をそれぞれ1つだけ示しているが、これらは、荷主、配送者ともに利用者の数だけ存在する。
システムサーバ100、荷主側端末200、配送者側端末300には、それぞれ図示する機能部が構成されている。本実施例では、これらの機能部は、それぞれの機能を実現するためのコンピュータプログラムを、インストールすることによりソフトウェア的に構成した。機能部の一部または全部は、ハードウェア的に構成するものとしてもよい。
以下、各機能部の内容について説明する。
以下、各機能部の内容について説明する。
(1)システムサーバ100の機能部:
システムサーバ100には、図示する通り以下の4種類のデータベースが用意されている。
拠点データベース121は、配送マッチングシステムにおける拠点の情報、および拠点間の基準料金の情報などを記憶するデータベースである。拠点の意味については、後述する。
荷主データベース122は、荷物の配送を依頼する荷主の名称その他の情報を記憶するデータベースである。
配送者データベース123は、荷物を配送する配送者の名称その他の情報を記憶するデータベースである。
依頼データベース124は、荷主が登録した荷物の配送依頼を記憶するデータベースである。
荷主データベース122、配送者データベース123、依頼データベース124の構造は、後述する。
システムサーバ100には、図示する通り以下の4種類のデータベースが用意されている。
拠点データベース121は、配送マッチングシステムにおける拠点の情報、および拠点間の基準料金の情報などを記憶するデータベースである。拠点の意味については、後述する。
荷主データベース122は、荷物の配送を依頼する荷主の名称その他の情報を記憶するデータベースである。
配送者データベース123は、荷物を配送する配送者の名称その他の情報を記憶するデータベースである。
依頼データベース124は、荷主が登録した荷物の配送依頼を記憶するデータベースである。
荷主データベース122、配送者データベース123、依頼データベース124の構造は、後述する。
主制御部110は、配送マッチングシステムにおいて荷主と配送者とをマッチングするサービス(以下、「配送サービス」と呼ぶ)の全体の処理を制御する。
送受信部130は、インターネットを介して、荷主側端末200、配送者側端末300と配送依頼その他の情報を授受する機能を奏する。
配送依頼受付部131は、荷主側端末200から送信された配送依頼を受け付け、依頼データベース124に登録する。
マッチング処理部132は、依頼データベース124に登録されている配送依頼について、荷主と配送者とをマッチングする処理を実行する。
キャンセル処理部133は、配送依頼について、荷主または配送者からキャンセルがされたときの処理を実行する。
配送管理部134は、マッチングが成立した後の配送の実施状況を管理する。
プロフィール登録部135は、配送者側端末300からプロフィールを受け取り、これを配送者データベース123に登録する。
精算処理部136は、配送依頼について費用の精算を行う。
送受信部130は、インターネットを介して、荷主側端末200、配送者側端末300と配送依頼その他の情報を授受する機能を奏する。
配送依頼受付部131は、荷主側端末200から送信された配送依頼を受け付け、依頼データベース124に登録する。
マッチング処理部132は、依頼データベース124に登録されている配送依頼について、荷主と配送者とをマッチングする処理を実行する。
キャンセル処理部133は、配送依頼について、荷主または配送者からキャンセルがされたときの処理を実行する。
配送管理部134は、マッチングが成立した後の配送の実施状況を管理する。
プロフィール登録部135は、配送者側端末300からプロフィールを受け取り、これを配送者データベース123に登録する。
精算処理部136は、配送依頼について費用の精算を行う。
上述の機能部の構成は、一例に過ぎず、これらの一部を省略したり、一部の機能部を複数の細分化した機能部で構成したり、逆に複数の機能部を統合してもよい。図1に示した以外の機能部を設けることも差し支えない。また、本実施例では、上述の各機能部は、1台のシステムサーバ100によって提供される例を示したが、各機能部をネットワークで接続された複数のサーバによる分散システムとして構築することも可能である。
(2)荷主側端末200の機能部:
荷主側端末200の機能部について説明する。
送受信部201は、インターネットを介してシステムサーバ100との間で配送依頼その他の情報を授受する。
ブラウザ202は、配送サービスに関する種々の情報のインタフェース画面を提供する。本実施例では、インタフェース画面は、HTMLその他の形式でシステムサーバ100から提供され、これをブラウザ202で表示する方法をとった。こうすることにより、汎用的な携帯端末を荷主側端末200として利用することができる。ブラウザ202は、汎用のものでもよいし、配送サービス専用のアプリとして構成してもよい。
コマンド入力部203は、キーボード、タッチパネル等の操作を介して荷主の入力を受け付ける。
送受信部201、コマンド入力部203は、荷主側端末200にインストールされているOSの機能を用いることができる。
荷主側端末200の機能部について説明する。
送受信部201は、インターネットを介してシステムサーバ100との間で配送依頼その他の情報を授受する。
ブラウザ202は、配送サービスに関する種々の情報のインタフェース画面を提供する。本実施例では、インタフェース画面は、HTMLその他の形式でシステムサーバ100から提供され、これをブラウザ202で表示する方法をとった。こうすることにより、汎用的な携帯端末を荷主側端末200として利用することができる。ブラウザ202は、汎用のものでもよいし、配送サービス専用のアプリとして構成してもよい。
コマンド入力部203は、キーボード、タッチパネル等の操作を介して荷主の入力を受け付ける。
送受信部201、コマンド入力部203は、荷主側端末200にインストールされているOSの機能を用いることができる。
(3)配送者側端末300の機能部:
配送者側端末300の機能部について説明する。
送受信部301は、インターネットを介してシステムサーバ100との間で配送依頼その他の情報を授受する。
コマンド入力部302は、キーボード、タッチパネル等の操作を介して配送者の入力を受け付ける。
送受信部301、コマンド入力部302は、配送者側端末300にインストールされているOSの機能を用いることができる。
配送者側端末300の機能部について説明する。
送受信部301は、インターネットを介してシステムサーバ100との間で配送依頼その他の情報を授受する。
コマンド入力部302は、キーボード、タッチパネル等の操作を介して配送者の入力を受け付ける。
送受信部301、コマンド入力部302は、配送者側端末300にインストールされているOSの機能を用いることができる。
また、配送者側端末300には、配送者用アプリ310がインストールされている。配送者用アプリ310は、以下の機能部を構築する。これらの機能は、ブラウザを利用して提供してもよい。
位置情報送信部311は、配送者側端末300の位置情報をGPS等で検出し、これをシステムサーバ100に送信する。この位置情報は、例えば、配送状況の管理などに利用される。
プロフィール管理部312は、配送者が、システムサーバ100に登録するためのプロフィール情報の作成、管理、システムサーバ100への登録を行う。
配送依頼管理部313は、配送者が応諾した配送依頼を管理する。
位置情報送信部311は、配送者側端末300の位置情報をGPS等で検出し、これをシステムサーバ100に送信する。この位置情報は、例えば、配送状況の管理などに利用される。
プロフィール管理部312は、配送者が、システムサーバ100に登録するためのプロフィール情報の作成、管理、システムサーバ100への登録を行う。
配送依頼管理部313は、配送者が応諾した配送依頼を管理する。
図2は、拠点データベースの構造を示す説明図である。拠点とは、配送サービスにおいて、荷物の配送元、配送先として受け付け可能な領域を意味する。本実施例では、東京、名古屋、大阪の3つを拠点としたが、拠点数、拠点の場所は、任意に決めることができる。荷物の配送料金は、配送元、配送先の住所、荷物の内容にかかわらず、拠点間で統一の基準料金が適用される。拠点とは、このように統一料金を適用する範囲という意味も有している。拠点データベース121は、拠点についてのデータを図示する形式で記憶する。
拠点情報とは、拠点の範囲を特定する情報である。本実施例では、それぞれの拠点を円形の範囲としており、その中心の緯度経度および半径で特定している。この半径は、同一料金で配送する範囲を定めるものであるから、道路状況、配送に要する所要時間などを考慮して、設定すればよい。半径は、拠点ごとに異なっていても良い。図の例では、東京については半径50kmとし、名古屋については半径55kmとした。東京の混雑する道路状況を踏まえ、若干狭く設定してある。
配送基準データは、各拠点間の配送について、基準料金および基準の配送時間を記憶する。図の例では、東京から名古屋に配送する場合の基準料金は「○○○円」、基準の配送時間は7時間と設定されている。東京から大阪に配送する場合についても図示する通り設定されている。また、名古屋から東京に配送する場合の基準料金は「△△△円」、基準の配送時間は7.5時間と設定されている。このように、東京〜名古屋間であっても、どちらを配送元、配送先にするかで、基準料金、基準の配送時間を変えても良い。もちろん、両者共通の基準料金、配送時間としても差し支えない。
図3は、荷主データベース、依頼データベース及び配送者データベースの各構造とそれらの結びつきを示す説明図である。
荷主データベース122において、荷主IDは、新たに登録をしたときにシステムサーバ100によって与えられる荷主に固有の識別情報である。荷主データベース122には、荷主IDと紐付けて、名称、連絡先などの情報が登録される。支払情報は、費用の支払いに利用する金融機関、クレジットカードなどの情報である。依頼履歴は、配送サービスの利用履歴が記憶される。本実施例では、依頼データベース124において配送依頼ごとに付与される依頼IDを記憶するものとした。
課金情報は、配送依頼に対する課金処理の結果を記憶している。日時、依頼IDに紐付けて配送依頼で課金された金額、および支払いが完了したか否かの「支払」情報が記憶されている。
荷主データベース122において、荷主IDは、新たに登録をしたときにシステムサーバ100によって与えられる荷主に固有の識別情報である。荷主データベース122には、荷主IDと紐付けて、名称、連絡先などの情報が登録される。支払情報は、費用の支払いに利用する金融機関、クレジットカードなどの情報である。依頼履歴は、配送サービスの利用履歴が記憶される。本実施例では、依頼データベース124において配送依頼ごとに付与される依頼IDを記憶するものとした。
課金情報は、配送依頼に対する課金処理の結果を記憶している。日時、依頼IDに紐付けて配送依頼で課金された金額、および支払いが完了したか否かの「支払」情報が記憶されている。
依頼データベース124は、配送依頼を記憶するデータベースである。新たに配送依頼がなされるごとに、システムサーバ100によって、固有の識別情報としての依頼IDが付され、図示する一連のレコードが生成される。
レコードには、依頼IDに紐付けて配送依頼をした荷主を特定するための荷主IDが記憶される。また、依頼内容が登録される。本実施例では、「荷物引受」とは配送元の住所、「配送先」は配送先の住所である。また、「30kg以上の荷物」とは、重量物の有無の情報である。「車種」は、冷蔵など、荷物を配送する際の車種を指定する情報である。「マッチングタイム」とは、詳しくは後述するが、配送依頼を登録した後、配送者からの応諾を待つ許容時間を表している。
「配送者ID」は、配送者データベース123において配送者ごとに付される固有の識別情報である。依頼データベース124では、配送依頼に対してマッチングされた配送者の配送者IDが記憶されることになる。
ステータスは、配送依頼の処理状況を表す情報である。本実施例では、図示する通り、マッチング待ち、マッチング済などのステータスごとに定められたコードを記憶するものとした。
「評価」、「レビュー」は、配送者に対する荷主の評価および荷主の自由記載によるコメントである。
「課金結果」は、配送依頼に対する課金の金額を記憶する。
レコードには、依頼IDに紐付けて配送依頼をした荷主を特定するための荷主IDが記憶される。また、依頼内容が登録される。本実施例では、「荷物引受」とは配送元の住所、「配送先」は配送先の住所である。また、「30kg以上の荷物」とは、重量物の有無の情報である。「車種」は、冷蔵など、荷物を配送する際の車種を指定する情報である。「マッチングタイム」とは、詳しくは後述するが、配送依頼を登録した後、配送者からの応諾を待つ許容時間を表している。
「配送者ID」は、配送者データベース123において配送者ごとに付される固有の識別情報である。依頼データベース124では、配送依頼に対してマッチングされた配送者の配送者IDが記憶されることになる。
ステータスは、配送依頼の処理状況を表す情報である。本実施例では、図示する通り、マッチング待ち、マッチング済などのステータスごとに定められたコードを記憶するものとした。
「評価」、「レビュー」は、配送者に対する荷主の評価および荷主の自由記載によるコメントである。
「課金結果」は、配送依頼に対する課金の金額を記憶する。
配送者データベース123は、配送者に関する情報を記憶する。配送者IDは、新たに配送者が登録をしたときに、システムサーバ100によって付される配送者固有の識別情報である。配送者IDに紐付けて、配送者の名称、連絡先などが登録される。
車種は、配送者が配送に利用する車輌の分類を、図示する分類コードで記憶する。
口座情報は、配送者の金融機関の情報である。本実施例では、配送料金の精算は、荷主と配送者との間で直接に行うのではなく、荷主から配送サービスの運用者が受領し、これを配送者に仲介することで行っている。従って、配送者データベース123には、このための口座情報が記憶されているのである。
プロフィールは、配送者が自身に対して登録する種々の情報である。この情報を記入することにより、配送者は、自身を荷主にアピールでき、荷主から選択してもらう可能性を向上させることができる。
評価は、配送者に対する種々の荷主からの総合評価である。
依頼履歴は、配送者が担当した配送依頼の履歴を記憶する。本実施例では、依頼データベース124における依頼IDを記憶する方法をとっている。
ステータスは、配送者の現状を表す情報である。本実施例では、待機、配送、帰還、OFFなどのステータスを、それぞれのコードで記憶するものとした。この情報は、随時上書きで更新されるものとしてもよいし、履歴の形で記憶するものとしてもよい。また、ステータスとして、本実施例では、GPS、即ち配送者の位置情報も記憶している。GPSについても、随時更新してもよいし、履歴として記憶してもよい。
報酬情報は、配送者に対して支払われた金銭の情報である。日時、配送依頼の依頼ID、および支払われた金額、その支払い状況が記憶されている。
車種は、配送者が配送に利用する車輌の分類を、図示する分類コードで記憶する。
口座情報は、配送者の金融機関の情報である。本実施例では、配送料金の精算は、荷主と配送者との間で直接に行うのではなく、荷主から配送サービスの運用者が受領し、これを配送者に仲介することで行っている。従って、配送者データベース123には、このための口座情報が記憶されているのである。
プロフィールは、配送者が自身に対して登録する種々の情報である。この情報を記入することにより、配送者は、自身を荷主にアピールでき、荷主から選択してもらう可能性を向上させることができる。
評価は、配送者に対する種々の荷主からの総合評価である。
依頼履歴は、配送者が担当した配送依頼の履歴を記憶する。本実施例では、依頼データベース124における依頼IDを記憶する方法をとっている。
ステータスは、配送者の現状を表す情報である。本実施例では、待機、配送、帰還、OFFなどのステータスを、それぞれのコードで記憶するものとした。この情報は、随時上書きで更新されるものとしてもよいし、履歴の形で記憶するものとしてもよい。また、ステータスとして、本実施例では、GPS、即ち配送者の位置情報も記憶している。GPSについても、随時更新してもよいし、履歴として記憶してもよい。
報酬情報は、配送者に対して支払われた金銭の情報である。日時、配送依頼の依頼ID、および支払われた金額、その支払い状況が記憶されている。
荷主データベース122、配送者データベース123、および依頼データベース124には、それぞれ図示した以外の情報を記憶させてもよいし、図示した情報の一部を省略してもよい。
また、データベース全体の構造についても、図示した例に限らず、種々の構造をとり得る。
また、データベース全体の構造についても、図示した例に限らず、種々の構造をとり得る。
C.配送サービスの全体処理:
次に、配送サービスの全体処理の概要について説明する。それぞれの処理の詳細な内容は後述する。
図4は、本システムにおけるシステムサーバ100、荷主側端末200及び配送者側端末300での処理の流れを示すフローチャートである。
次に、配送サービスの全体処理の概要について説明する。それぞれの処理の詳細な内容は後述する。
図4は、本システムにおけるシステムサーバ100、荷主側端末200及び配送者側端末300での処理の流れを示すフローチャートである。
配送者は、配送者側端末300に組み込まれた配送者アプリ310を起動させて、コマンド入力部302の操作により、名称、連絡先、車種、口座情報、プロフィール等の配送者情報を入力し、プロフィール登録操作を行う(ステップc1)。配送者情報は送受信部301よりネットワークを介して、システムサーバ100内の配送者データベース123に送信され、システムサーバ100は、配送者のプロフィール登録処理を行う(ステップb1)。
荷主は、荷主側端末200のブラウザ202を通じてコマンド入力部203の操作により、名称、連絡先、支払情報等の荷主情報を入力した後、送受信部201よりネットワークを介して、システムサーバ100内の荷主データベース122にプロフィール登録を行うことにより、配送サービスを利用することができるようになる。
荷物の配送を依頼するときは、荷主は、荷主側端末200を用いて配送依頼処理を行う(ステップa1)。配送依頼処理により、配送依頼の情報は、ネットワークを介してシステムサーバ100内の配送依頼受付部131で受信される。
システムサーバ100は、配送依頼を依頼データベース124に登録し、以下に示す手順で、マッチング処理を行う(ステップb2)。まず、システムサーバ100は、配送依頼を配送者側端末300に送信する。配送者が、配送依頼を確認し、これに応じるために配送者側端末300で応諾処理を行うと、配送者側端末300は、応諾の通知をシステムサーバ100に送信する(ステップc2)。システムサーバ100は、応諾した配送者の情報を荷主側端末200に送信する。依頼者である荷主が、荷主側端末200において、該配送依頼に対して応諾した複数の配送者一覧を見て、任意の配送者を選定し、正式に依頼する操作を行うと、荷主側端末200は、正式依頼通知をシステムサーバ100に送信する(ステップa2)。これによって、荷主と配送者のマッチングが完了する。
マッチングが完了した後、荷主または配送者が、配送依頼をキャンセルする場合もある。荷主からのキャンセル指示(ステップa3)、または配送者からのキャンセル指示(ステップc3)がなされると、システムサーバ100は、それぞれの指示に応じたキャンセル処理を行う。
双方からキャンセルがなされない場合、配送者は配送依頼で指定された配送元に集荷し、荷物の引受を行う。集荷にあたっては、配送者側端末300は、配送者の操作に従って引受開始情報をシステムサーバ100に送信する(ステップc4)。また、荷物の引受が完了すると、荷主側端末200は引受完了情報をシステムサーバ100に送信する(ステップa4)。システムサーバ100は、これらの情報に基づいて、荷物引受処理を実行して(ステップb4)、配送依頼のステータスを更新する。
配送者が配送している間(ステップc5)、システムサーバ100は、GPSなどの情報によって、配送者の位置情報を検出する(ステップb5)。この間、荷主はシステムサーバ100に問い合わせることにより、配送状況を確認することができる(ステップa5)。
配送が完了し、配送者が、配送者側端末300によって、配送完了情報をシステムサーバ100に送信すると(ステップc6)、システムサーバ100は、配送完了情報を荷主側端末200に送信する。荷主が配送を完了したことを確認し、承諾すると(ステップa6)、システムサーバ100は、配送完了処理を実行し(ステップb6)、配送依頼のステータスを更新する。
配送が完了すると、システムサーバ100は、配送依頼について、課金、報酬処理を行い(ステップb7)、料金を計算する。
また、荷主は、配送についてレビューをシステムサーバ100に送信することができる(ステップa7)。このレビューは、配送者情報の一部として登録され、以後、新たな荷主が、配送者を選択するために参照される。
以上が配送サービスの概要であるが、以下、システムサーバ100内における各処理について説明する。
また、荷主は、配送についてレビューをシステムサーバ100に送信することができる(ステップa7)。このレビューは、配送者情報の一部として登録され、以後、新たな荷主が、配送者を選択するために参照される。
以上が配送サービスの概要であるが、以下、システムサーバ100内における各処理について説明する。
C−1.プロフィール登録処理:
図5は、プロフィール登録処理のフローチャートである。図4のステップb1の処理に相当する。主としてプロフィール登録部135(図1)が実行する処理であり、ハードウェア的にはシステムサーバ100が実行する処理である。
この処理は、配送者が、荷主にアピールするために、自身のプロフィールを登録するための処理である。配送者は、予めシステムサーバ100に登録されており、自身の識別情報としての配送者IDが付与されているものとする。
処理を開始すると、システムサーバ100は、配送者IDを配送者側端末300から読み込む(ステップS1)。
図5は、プロフィール登録処理のフローチャートである。図4のステップb1の処理に相当する。主としてプロフィール登録部135(図1)が実行する処理であり、ハードウェア的にはシステムサーバ100が実行する処理である。
この処理は、配送者が、荷主にアピールするために、自身のプロフィールを登録するための処理である。配送者は、予めシステムサーバ100に登録されており、自身の識別情報としての配送者IDが付与されているものとする。
処理を開始すると、システムサーバ100は、配送者IDを配送者側端末300から読み込む(ステップS1)。
そして、システムサーバ100は、配送者側端末300に、プロフィール入力画面を表示する(ステップS2)。配送者が既に登録済みのプロフィールがある場合、システムサーバ100は、その情報も読み込み、入力画面に表示する。
図中に入力画面の例を示した。配送者は、氏名、年齢、血液型、写真などを登録できる。また、趣味や自己PRなども登録できる。これらの情報は、配送依頼をした荷主が閲覧できるため、荷主の関心をひく内容を記載すれば、依頼を受けられる可能性を高めることができる。
また、配送者は、車種、車検証、荷室サイズなど、自身が使用する車輌の情報も入力する。車種は、軽バン、軽幌車、軽冷蔵車、その他のように予め定められた分類(図3参照)から選択する方法をとっている。車両の名称を入力するようにしても差し支えないが、このように分類を入力することにより、荷主は、自身の要求に応じた車両か否かを判断しやすくなる利点がある。
配送者は、「割引」を登録することもできる。先に図2で説明した通り、配送サービスでは、拠点に応じて設定された基準料金が適用されるが、配送者が「割引」を設定すると、配送料金は、設定に応じて割り引いた金額となる。
プロフィールは、この他にも、種々の情報を登録可能としてもよい。配送者のプロフィールは、既存の情報を更新することも可能である。
図中に入力画面の例を示した。配送者は、氏名、年齢、血液型、写真などを登録できる。また、趣味や自己PRなども登録できる。これらの情報は、配送依頼をした荷主が閲覧できるため、荷主の関心をひく内容を記載すれば、依頼を受けられる可能性を高めることができる。
また、配送者は、車種、車検証、荷室サイズなど、自身が使用する車輌の情報も入力する。車種は、軽バン、軽幌車、軽冷蔵車、その他のように予め定められた分類(図3参照)から選択する方法をとっている。車両の名称を入力するようにしても差し支えないが、このように分類を入力することにより、荷主は、自身の要求に応じた車両か否かを判断しやすくなる利点がある。
配送者は、「割引」を登録することもできる。先に図2で説明した通り、配送サービスでは、拠点に応じて設定された基準料金が適用されるが、配送者が「割引」を設定すると、配送料金は、設定に応じて割り引いた金額となる。
プロフィールは、この他にも、種々の情報を登録可能としてもよい。配送者のプロフィールは、既存の情報を更新することも可能である。
配送者がプロフィールを入力すると、システムサーバ100は、配送者側端末300から、プロフィールを受け付け(ステップS3)、入力された項目あるいは更新された項目に応じて配送者にポイントを付与する(ステップS4)。このポイントは、たとえば自動換金により配送者に対する報酬となる。本実施例では、ポイント付与することにより、配送者に、プロフィールを更新する動機付けを与えているのである。
システムサーバ100は、配送者データベース123に記憶された情報を更新し(ステップS5)、プロフィール登録処理を終了する。
システムサーバ100は、配送者データベース123に記憶された情報を更新し(ステップS5)、プロフィール登録処理を終了する。
C−2.配送依頼処理:
図6、図7は、配送依頼処理のフローチャートである。図4のステップa1の処理に相当する。主としてシステムサーバ100の配送依頼受付部131(図1)が提供する画面に従って、荷主側端末200が実行する処理である。この処理は、例えば、荷主が荷主側端末200によって配送サービスのWEBページにアクセスし、基本メニューから「配送依頼」を選択することによって開始する方法をとることができる。
図6、図7は、配送依頼処理のフローチャートである。図4のステップa1の処理に相当する。主としてシステムサーバ100の配送依頼受付部131(図1)が提供する画面に従って、荷主側端末200が実行する処理である。この処理は、例えば、荷主が荷主側端末200によって配送サービスのWEBページにアクセスし、基本メニューから「配送依頼」を選択することによって開始する方法をとることができる。
処理を開始すると、荷主側端末200は、過去の配送依頼の再利用か否かを判断する(ステップS10)。荷主側端末200に過去の配送依頼を利用するか否かの問合わせ画面を表示するようにしてもよい。また、配送依頼を開始するためのメニューを、通常の「配送依頼」および「配送依頼(再利用)」のように分けて用意しておいてもよい。
過去の配送依頼の再利用の場合、荷主側端末200は、システムサーバ100から、荷主からの過去の配送依頼を受信し、これをリスト表示し、その選択を受け付ける(ステップS11)。
図に、リストの例を示した。この例では、配送者がキャンセルした配送依頼、配送済みのものを含め、過去に依頼した配送依頼が表示されており、配送者がキャンセルした配送依頼が選択されている。リスト表示の内容を、拠点、依頼日などの条件で絞り込み可能としてもよい。このように、いまだ配送が完了していない荷物がある場合には、過去の依頼情報を利用して再送を依頼することができる。さらに、配送先など過去の配送依頼と共通する項目が多いときには、過去の配送依頼を利用することにより迅速かつ簡便に配送依頼を行うことが可能となる。
過去の配送依頼を利用しないと判断される場合(ステップS10)、荷主側端末200は、上述のリスト表示をスキップする。
図に、リストの例を示した。この例では、配送者がキャンセルした配送依頼、配送済みのものを含め、過去に依頼した配送依頼が表示されており、配送者がキャンセルした配送依頼が選択されている。リスト表示の内容を、拠点、依頼日などの条件で絞り込み可能としてもよい。このように、いまだ配送が完了していない荷物がある場合には、過去の依頼情報を利用して再送を依頼することができる。さらに、配送先など過去の配送依頼と共通する項目が多いときには、過去の配送依頼を利用することにより迅速かつ簡便に配送依頼を行うことが可能となる。
過去の配送依頼を利用しないと判断される場合(ステップS10)、荷主側端末200は、上述のリスト表示をスキップする。
次に、荷主側端末200は、荷物引受および配送先の情報を入力する(ステップS12)。図中に、この入力のための画面例を示した。荷物引受としては、住所、引渡日時、30kg以上の荷物の有無、車種の指定を入力する。
配送サービスでは、拠点間で基準料金を適用するため、荷物自体の重量、サイズ、数量は入力する必要がない。重量物を含むか否かの情報を入力するのは、重量物の配送には、配送者によって対応可否が分かれるからである。
また、荷主がマッチングタイムを任意に設定できるものとした。マッチングタイムとは、配送依頼に対する配送者からの応諾の受付時間である。仮に、マッチングタイムを設けず、応諾の早い順に配送者をマッチングさせるものとすると、荷主は、配送者を選択する余地がなくなってしまう。本実施例では、荷主が配送者を選択することができるよう、一定のマッチングタイム中は、配送者からの応諾を受付可能としたのである。荷主にとっては、マッチングタイムを長くすれば、それだけ配送者の選択肢が増えることになる。一方、マッチングタイムを長くすると、配送者としては、配送依頼を受注できるか否か不確定な時期が長くなることになってしまう。このことは、配送者に応諾を躊躇させる要因ともなる。マッチングタイムは、このような両面を考えて設定すればよい。マッチングタイムは、システムサーバ100が予め設定するものとしてもよいが、本実施例では、上述の通り、荷主が任意に設定できるようにした。
配送サービスでは、拠点間で基準料金を適用するため、荷物自体の重量、サイズ、数量は入力する必要がない。重量物を含むか否かの情報を入力するのは、重量物の配送には、配送者によって対応可否が分かれるからである。
また、荷主がマッチングタイムを任意に設定できるものとした。マッチングタイムとは、配送依頼に対する配送者からの応諾の受付時間である。仮に、マッチングタイムを設けず、応諾の早い順に配送者をマッチングさせるものとすると、荷主は、配送者を選択する余地がなくなってしまう。本実施例では、荷主が配送者を選択することができるよう、一定のマッチングタイム中は、配送者からの応諾を受付可能としたのである。荷主にとっては、マッチングタイムを長くすれば、それだけ配送者の選択肢が増えることになる。一方、マッチングタイムを長くすると、配送者としては、配送依頼を受注できるか否か不確定な時期が長くなることになってしまう。このことは、配送者に応諾を躊躇させる要因ともなる。マッチングタイムは、このような両面を考えて設定すればよい。マッチングタイムは、システムサーバ100が予め設定するものとしてもよいが、本実施例では、上述の通り、荷主が任意に設定できるようにした。
荷主側端末200は、配送依頼の入力が完了すると、拠点データベース121に記憶された各種情報との照合により配送条件を判定する(ステップS13)。本実施例では、次の3つの条件を判定するものとした。条件1は、荷物の引受地または配送先が拠点内か否かである。配送サービスは、拠点間で荷物を配送するサービスであり、拠点以外の引受地、配送先については受け付けられないからである。条件2は、荷物の引渡日時が現在時刻とマッチングタイムに荷物引受に要する時間として2時間を加えた時刻より後となっているかである。引渡日時の指定が早すぎる場合、集荷することができなくなるからである。引受の所要時間は、2時間に限られるものではない。また、配送依頼ごとに拠点の外縁から荷物の引受地までの移動に要する最大の所要時間を用いるようにしてもよい。条件3は、荷物の引渡日時と配達日時との間の時間が基準配送時間より大きいことである。基準配送時間よりも短い時間での配送を要求されても対応できない可能性があるからである。
条件1〜3の判断は、荷主側端末200で行うようにしてもよいし、配送依頼をシステムサーバ100に送信し、システムサーバ100で条件1〜3の判断を行った上、その結果を荷主側端末200に返信するようにしてもよい。
条件1〜3の判断は、荷主側端末200で行うようにしてもよいし、配送依頼をシステムサーバ100に送信し、システムサーバ100で条件1〜3の判断を行った上、その結果を荷主側端末200に返信するようにしてもよい。
条件1〜3のいずれか一つでも満たされない場合には(ステップS14)、荷主側端末200は、ステップ12の依頼情報入力手順に戻り、条件の修正を促す。
配送条件を満たす場合は(ステップS14)、荷主側端末200は、配送費用見積り結果の表示を行う(ステップS15)。配送費用も、荷主側端末200が見積もるようにしてもよいし、システムサーバ100で見積もった結果を荷主側端末200が表示するようにしてもよい。
荷主は、配送費用見積り結果を確認し、配送を依頼するか否かを決める。荷主側端末200は、配送を依頼する旨を入力したときは(ステップS16)、システムサーバ100に対して配送依頼の送信を行う(ステップS17)。既にステップS13、S15などで配送依頼をシステムサーバ100に送信済みの場合は、ステップS17では、配送依頼が確定した旨の情報を送信するようにしてもよい。
配送を依頼しない旨の入力があったときは(ステップS16)、配送依頼を送信することなく、配送依頼処理を終了する。
以上が、配送依頼処理の流れである。
配送条件を満たす場合は(ステップS14)、荷主側端末200は、配送費用見積り結果の表示を行う(ステップS15)。配送費用も、荷主側端末200が見積もるようにしてもよいし、システムサーバ100で見積もった結果を荷主側端末200が表示するようにしてもよい。
荷主は、配送費用見積り結果を確認し、配送を依頼するか否かを決める。荷主側端末200は、配送を依頼する旨を入力したときは(ステップS16)、システムサーバ100に対して配送依頼の送信を行う(ステップS17)。既にステップS13、S15などで配送依頼をシステムサーバ100に送信済みの場合は、ステップS17では、配送依頼が確定した旨の情報を送信するようにしてもよい。
配送を依頼しない旨の入力があったときは(ステップS16)、配送依頼を送信することなく、配送依頼処理を終了する。
以上が、配送依頼処理の流れである。
C−3.マッチング処理:
図8および図9は、マッチング処理のフローチャートである。図4のステップb2の処理に相当する。主としてマッチング処理部132(図1)が実行する処理であり、ハードウェア的にはシステムサーバ100が実行する処理である。この処理は、システムサーバ100が荷主側端末200から配送依頼を受け付けると開始される。
図8および図9は、マッチング処理のフローチャートである。図4のステップb2の処理に相当する。主としてマッチング処理部132(図1)が実行する処理であり、ハードウェア的にはシステムサーバ100が実行する処理である。この処理は、システムサーバ100が荷主側端末200から配送依頼を受け付けると開始される。
処理を開始すると、システムサーバ100は、配送依頼を依頼データベース124に保存する(ステップS20)。
システムサーバ100は、この配送依頼を応諾する可能性のある配送者を検索する処理を行う(ステップS21)。本実施例では、3種類の条件を設定し、検索範囲を段階的に広げられるようにした。
通常マッチング条件の条件(1)は、荷主が指定した車種の条件を満たすことである。条件(2)は、配送者のステータスが、待機または帰還であること、即ち配送依頼に応じることが可能なステータスにあることである。
システムサーバ100は、この配送依頼を応諾する可能性のある配送者を検索する処理を行う(ステップS21)。本実施例では、3種類の条件を設定し、検索範囲を段階的に広げられるようにした。
通常マッチング条件の条件(1)は、荷主が指定した車種の条件を満たすことである。条件(2)は、配送者のステータスが、待機または帰還であること、即ち配送依頼に応じることが可能なステータスにあることである。
非マッチング条件は、配送依頼を受注させるべきではないと判断され、検索の対象から除外される配送者を特定するための条件である。非マッチング条件の条件(1)は、配送者のステータスが、配送中またはOFFとなっていることである。条件(2)は、荷物の引受時刻が配送後12時間以内であることである。条件(2)は、一人の配送者が、立て続けに過剰に配送依頼を受任することを回避し、不慮の事故を予防する目的、および、多くの配送者に均等に機会を与える目的で設けられた条件である。条件(2)は、配送先から帰ろうとする配送者、いわゆる帰り便の場合には、適用除外としている。拠点Aから拠点Bに配送を完了した配送者が、拠点Aに帰ろうとしている場合には、この配送者に配達依頼を受注させた方が、車両を有効活用することができ、荷主にも安い料金で配送サービスを提供可能となる点で利点があるからである。条件(3)は、荷物の引受時刻が応諾済み配送依頼に要する時間の前後2時間以内(図中に非マッチング期間として示した期間)であること、である。新たな配送依頼の引受時刻が、既に応諾済みの他の配送依頼の直前である場合には、既に応諾済みの配送依頼の荷物の引受に支障が生じることがある。また、新たな配送依頼の配送時刻が、既に応諾済みの配送依頼の直後である場合も、2つの配送依頼のいずれかの配送に支障が生じることがある。かかる点を考慮し、非マッチング期間に引受時刻または配送時刻が入る配送依頼は受注できないようにしているのである。
帰り便マッチング条件とは、1回目の配送者検索処理においては、配送依頼が配送者にとって帰り便となる配送者を優先するための条件である。帰り便マッチング条件の条件(1)は、配送者が帰還ステータスであることである。帰り便は、以下の条件(2)〜(4)によって判断することもできる。条件(2)は、配送者の配送場所が、新たな配送依頼における荷物の引渡場所であること、である。この条件は、住所地ではなく、拠点単位で判断する。条件(3)は、配送者の拠点が、荷物の配送場所であること、である。この条件も、拠点単位で判断する。条件(4)は、荷物の引受時刻が、配送者の納品時刻より2〜8時間以内であること、である。この条件は、配送者が、配送をした後に荷物の引受ができるための条件である。帰り便マッチング条件では、条件(1)を満たす配送者、または条件(2)〜(4)を全て満たす配送者が、検索されることになる。
配送者検索処理(ステップS21)が、1回目に行われるときは、通常マッチング条件、非マッチング条件、および帰り便マッチング条件の全てを適用して配送者を検索する。この結果、帰り便に該当する配送者が検索されることになる。
システムサーバ100は、検索した配送者の配送者側端末300に配送依頼を配信し(ステップS22)、応諾申請および正式依頼の受付を行う(ステップS23)。
つまり、配送者は、配送者側端末300に配信された依頼情報を確認し、応諾したい配送依頼があれば、配送者側端末300を操作して、応諾申請を行う。この応諾申請は、システムサーバ100が荷主側端末200に送信する。このための処理は、後述する。
一方、荷主は、応諾申請を確認して、正式依頼を行う場合には、荷主側端末200を操作することにより、システムサーバ100に正式依頼を送信する。応諾申請および正式依頼のための時間が、マッチングタイムである。荷主は、応諾申請があった場合に、その配送者に対して、直ちに正式依頼をしてもよいし、マッチングタイムに至るまでは、他の配送者からの応諾を待ってもよい。
システムサーバ100は、検索した配送者の配送者側端末300に配送依頼を配信し(ステップS22)、応諾申請および正式依頼の受付を行う(ステップS23)。
つまり、配送者は、配送者側端末300に配信された依頼情報を確認し、応諾したい配送依頼があれば、配送者側端末300を操作して、応諾申請を行う。この応諾申請は、システムサーバ100が荷主側端末200に送信する。このための処理は、後述する。
一方、荷主は、応諾申請を確認して、正式依頼を行う場合には、荷主側端末200を操作することにより、システムサーバ100に正式依頼を送信する。応諾申請および正式依頼のための時間が、マッチングタイムである。荷主は、応諾申請があった場合に、その配送者に対して、直ちに正式依頼をしてもよいし、マッチングタイムに至るまでは、他の配送者からの応諾を待ってもよい。
応諾申請、正式依頼受付(ステップS23)において、正式依頼がなされた場合(ステップS24)、システムサーバ100は、マッチングされた配送者の情報を依頼データベース124に登録するとともに、成約を荷主および配送者に通知する(ステップS27)。
一方、荷主がマッチングタイム内に正式依頼を行わない場合(ステップS24)、システムサーバ100は、任意マッチングが完了したか否かを判断する(ステップS25)。本実施例では、先にステップS21で説明した通り、配送者の検索範囲を段階的に広げることができるように配送者の検索条件が設定されている。従って、1回目の検索結果に対して、マッチングが成立しなかったときは、検索範囲を広げて再度、配送者の検索を行うものとした。つまり、ステップS21〜S24の処理を2回繰り返すのである。従って、ステップS25では、2回のマッチング処理が完了したか否かを判断することになる。もちろん、3段階以上で検索範囲を広げられるようにし、マッチング処理を3回以上行うようにしても構わない。
配送者の検索が1回目しか行われておらず、任意マッチングが完了していないと判断される場合(ステップS25)、システムサーバ100は、再度、ステップS21〜S24の処理を繰り返し実行する。
この場合、ステップS21では、2回目の配送者の検索を行うことになるため、帰り便マッチング条件は用いず、通常マッチング条件および非マッチング条件を用いることになる。こうすることにより、1回目よりも検索範囲を広げることができ、帰り便以外の配送者にも配送依頼が配信されることになる。
2回目の処理で、正式依頼が成立すれば(ステップS24)、システムサーバ100は、マッチングされた配送者の情報を依頼データベース124に登録するとともに、成約を荷主および配送者に通知する(ステップS27)。
この場合、ステップS21では、2回目の配送者の検索を行うことになるため、帰り便マッチング条件は用いず、通常マッチング条件および非マッチング条件を用いることになる。こうすることにより、1回目よりも検索範囲を広げることができ、帰り便以外の配送者にも配送依頼が配信されることになる。
2回目の処理で、正式依頼が成立すれば(ステップS24)、システムサーバ100は、マッチングされた配送者の情報を依頼データベース124に登録するとともに、成約を荷主および配送者に通知する(ステップS27)。
2回目でも任意のマッチングが成立しなかったときは(ステップS25)、システムサーバ100は、自動マッチング処理を行って(ステップS26)、応諾されている配送者の中から受注する配送者を自動的に決定する。このマッチングは、複数の条件に対して優先度を設定し、優先度の高い条件が合致する配送者が一つ選定される。たとえば、提示価格の安さを第一に、評価の高さを第二に、応諾の早さを第三に、というように複数の条件に対して優先度を設定して配送者が選定される。なお、複数の条件に対して優先度が設定されるものの、応諾申請が1以上あることが前提となっていることから、必ず一つの配送者が選定される。この優先度は、システムサーバ100が決めてもよいし、荷主が、設定可能としてもよい。
自動マッチングによって、配送者が選定されると、システムサーバ100は、マッチングされた配送者の情報を依頼データベース124に登録するとともに、成約を荷主および配送者に通知する(ステップS27)。
自動マッチングによって、配送者が選定されると、システムサーバ100は、マッチングされた配送者の情報を依頼データベース124に登録するとともに、成約を荷主および配送者に通知する(ステップS27)。
C−4.応諾処理:
図10は、応諾処理のフローチャートである。図4のステップc2の処理、およびマッチング処理(図9)のステップS23における処理に相当する。主として配送者用アプリ310(図1)が実行する処理であり、ハードウェア的には配送者側端末300が実行する処理である。
この処理では、配送者側端末300がシステムサーバ100から配送依頼を受信する(ステップS30)。配送依頼は一つだけでなく複数を随時受信することもある。そして、配信者側端末300は、配送者受信した複数の配送依頼を一覧として表示する(ステップS31)。図中には、名古屋から東京への配送依頼、名古屋から大阪への配送依頼を例示した。
図10は、応諾処理のフローチャートである。図4のステップc2の処理、およびマッチング処理(図9)のステップS23における処理に相当する。主として配送者用アプリ310(図1)が実行する処理であり、ハードウェア的には配送者側端末300が実行する処理である。
この処理では、配送者側端末300がシステムサーバ100から配送依頼を受信する(ステップS30)。配送依頼は一つだけでなく複数を随時受信することもある。そして、配信者側端末300は、配送者受信した複数の配送依頼を一覧として表示する(ステップS31)。図中には、名古屋から東京への配送依頼、名古屋から大阪への配送依頼を例示した。
配送者側端末300は、このリスト画面で、詳細を確認したい配送依頼を表示するとともに、応諾するか否かの指示を受け付ける(ステップS32)。
応諾する場合には(ステップS33)、配送者応諾情報をシステムサーバ100に送信する(ステップS34)。
応諾しない場合には(ステップS33)、ステップS30に戻り、改めて受信した最新の配送依頼に基づいて配送依頼一覧を表示させて確認する。
こうすることにより、配送者は、自身の希望する内容に近い配送依頼を選択して、応諾することが可能となる。
応諾する場合には(ステップS33)、配送者応諾情報をシステムサーバ100に送信する(ステップS34)。
応諾しない場合には(ステップS33)、ステップS30に戻り、改めて受信した最新の配送依頼に基づいて配送依頼一覧を表示させて確認する。
こうすることにより、配送者は、自身の希望する内容に近い配送依頼を選択して、応諾することが可能となる。
C−5.キャンセル処理:
図11は、キャンセル処理のフローチャートである。図4のステップb3の処理に相当する。主としてキャンセル処理部133(図1)が実行する処理であり、ハードウェア的にはシステムサーバ100が実行する処理である。なお、当然のことであるが、一つの配送依頼に対してキャンセル処理がなされない場合もある。
図11は、キャンセル処理のフローチャートである。図4のステップb3の処理に相当する。主としてキャンセル処理部133(図1)が実行する処理であり、ハードウェア的にはシステムサーバ100が実行する処理である。なお、当然のことであるが、一つの配送依頼に対してキャンセル処理がなされない場合もある。
処理を開始すると、システムサーバ100は、荷主または配送者からのキャンセル指示を受け付ける(ステップS40)。次に、システムサーバ100は、指示に対応する配送依頼を検索し、キャンセルの対象となる配送依頼を特定する(ステップS41)。そして、荷主からのキャンセル指示か、配送者からのキャンセル指示かに応じて、以下のそれぞれの処理を実行する(ステップS42)。
荷主からのキャンセルの場合(ステップS42)、システムサーバ100は、キャンセルがなされた時刻から引受日時までの時間に応じて定まるキャンセル料率を配送料金に乗じることで、荷主に対して課金されるキャンセル料を計算する(ステップS43)。たとえば、引受日時までの時間が長い場合にはキャンセル料率を低く設定し、引受日時までの時間が短い場合にはキャンセル料率を高く設定してもよい。
次に、システムサーバ100は、該配送依頼がキャンセルされたことに応じて、荷主データベース122及び配送者データベース123のステータス等の情報を更新する(ステップS44)。荷主データベース122には、キャンセル料が記録されることになる。配送者データベース123のステータスの更新に併せて、ステータスが更新された旨、または配信依頼がキャンセルされた旨を配送者側端末300に送信してもよい。
続いて、システムサーバ100は、依頼データベースの情報も更新する(ステップS45)。このとき配送依頼のステータスとして荷主都合キャンセルとの情報が加わる。
一方、配送者からのキャンセルの場合(ステップS42)、たとえば、配送者の過去30日分の報酬に対して一定の制裁金料率を乗じることで、配送者に対して課金される制裁金を計算する(ステップS46)。また、配送者に制裁金を課すほかに、一定期間、本システムを利用できないペナルティを与えるものとすることもできる。
次に、システムサーバ100は、該配送依頼がキャンセルされたことに応じて、配送者データベース123のステータス等の情報を更新し(ステップS47)、依頼データベースの情報も更新する(ステップS48)。このときステータスとして配送者都合キャンセルとの情報が加わる。
次に、システムサーバ100は、該配送依頼がキャンセルされたことに応じて、配送者データベース123のステータス等の情報を更新し(ステップS47)、依頼データベースの情報も更新する(ステップS48)。このときステータスとして配送者都合キャンセルとの情報が加わる。
C−6.荷物引受処理:
図12は、荷物引受処理のフローチャートである。図4のステップb4の処理に相当する。主として配送管理部134(図1)が実行する処理であり、ハードウェア的にはシステムサーバ100が実行する処理である。この処理は、所定のタイミングで繰り返し実行される。
図12は、荷物引受処理のフローチャートである。図4のステップb4の処理に相当する。主として配送管理部134(図1)が実行する処理であり、ハードウェア的にはシステムサーバ100が実行する処理である。この処理は、所定のタイミングで繰り返し実行される。
処理を開始すると、システムサーバ100は、荷物引受が完了していない配送依頼を検索し(ステップS50)、配送者側端末300にリマインダーを送信して、配送者に荷物引受が完了していない配送依頼を知らせる(ステップS51)。
また、システムサーバ100は、配送者が配送者側端末300から荷物引受開始の指示を受け付けた場合は、依頼データベース124のステータスを更新する(ステップS52)。続いて、システムサーバ100は、GPSによって配送者の位置情報を検出する(ステップS53)。この位置情報は、配送者側端末300内の位置情報送信部311から送信される。そして、システムサーバ100は、GPSによって配送者が荷物の引受場所に到着したか否かを判定する(ステップS54)。
配送者が、荷物の引受場所に到着していない場合は(ステップS54)、何も処理をすることなく荷物引受処理を終了する。荷物引受処理は、繰り返し実行されるため、何度目かの処理では、予定通りであれば、引受場所に到着したものと判定されるはずである。
また、システムサーバ100は、配送者が配送者側端末300から荷物引受開始の指示を受け付けた場合は、依頼データベース124のステータスを更新する(ステップS52)。続いて、システムサーバ100は、GPSによって配送者の位置情報を検出する(ステップS53)。この位置情報は、配送者側端末300内の位置情報送信部311から送信される。そして、システムサーバ100は、GPSによって配送者が荷物の引受場所に到着したか否かを判定する(ステップS54)。
配送者が、荷物の引受場所に到着していない場合は(ステップS54)、何も処理をすることなく荷物引受処理を終了する。荷物引受処理は、繰り返し実行されるため、何度目かの処理では、予定通りであれば、引受場所に到着したものと判定されるはずである。
荷物の引受場所に到着したものと判定される場合(ステップS54)、システムサーバ100は、荷物の引受完了判定を行う(ステップS55)。すなわち、(1)荷主から荷主側端末200の操作により荷物の引受が完了した旨の情報を受け付けたとき、あるいは、(2)配送者が荷物の引受場所に到着後、引受場所から1キロメートル以上離れたことを位置情報によって検出したときは、荷物の引受が完了したものと判定する。
荷物の引受が完了したものと判定された場合は、引受完了日時の情報を反映するよう、また、ステータスを配送中にするよう依頼データベース124を更新する(ステップS56)。
また、引受完了日時が依頼時に指定していた引受日時よりも30分を超える超過時間が生じた場合には(ステップS57)、超過時間に応じて、課金、報酬を計算し、計算結果の情報を反映するよう荷主データベース122と配送者データベース123を更新する(ステップS58)。
荷物の引受が完了したものと判定された場合は、引受完了日時の情報を反映するよう、また、ステータスを配送中にするよう依頼データベース124を更新する(ステップS56)。
また、引受完了日時が依頼時に指定していた引受日時よりも30分を超える超過時間が生じた場合には(ステップS57)、超過時間に応じて、課金、報酬を計算し、計算結果の情報を反映するよう荷主データベース122と配送者データベース123を更新する(ステップS58)。
C−7.配送完了処理:
図13は、配送完了処理のフローチャートである。図4のステップb6の処理に相当する。主として配送管理部134(図1)が実行する処理であり、ハードウェア的にはシステムサーバ100が実行する処理である。
システムサーバ100は、配送者側端末300から配送完了の情報を受け付けると(ステップS60)、荷主側端末200に配送完了の情報を送信する(ステップS70)。
次に、荷主が荷主側端末200を操作して、配送完了の情報を確認したうえで承諾の可否を確認し(ステップS71)、配送者に配送完了の通知を送信する(ステップS72)。
続いて、システムサーバ100は、荷主側端末200に評価やレビューの入力画面を表示させ、荷主に評価やレビューの入力を促す(ステップS73)。荷主によって必ず評価やレビューの入力がなされるわけではないが、なされた場合には、入力された情報を反映するよう依頼データベース124を更新するとともに(ステップS74)、入力された情報に基づいて配送者データベース123も更新する(ステップS75)。ここで、荷主の評価に応じて配送者にポイントが付与されるものとすれば、サービス向上に寄与する。
図13は、配送完了処理のフローチャートである。図4のステップb6の処理に相当する。主として配送管理部134(図1)が実行する処理であり、ハードウェア的にはシステムサーバ100が実行する処理である。
システムサーバ100は、配送者側端末300から配送完了の情報を受け付けると(ステップS60)、荷主側端末200に配送完了の情報を送信する(ステップS70)。
次に、荷主が荷主側端末200を操作して、配送完了の情報を確認したうえで承諾の可否を確認し(ステップS71)、配送者に配送完了の通知を送信する(ステップS72)。
続いて、システムサーバ100は、荷主側端末200に評価やレビューの入力画面を表示させ、荷主に評価やレビューの入力を促す(ステップS73)。荷主によって必ず評価やレビューの入力がなされるわけではないが、なされた場合には、入力された情報を反映するよう依頼データベース124を更新するとともに(ステップS74)、入力された情報に基づいて配送者データベース123も更新する(ステップS75)。ここで、荷主の評価に応じて配送者にポイントが付与されるものとすれば、サービス向上に寄与する。
C−8.料金計算処理:
図14は、料金計算処理のフローチャートである。図4のステップb7の処理に相当する。主として精算処理部136(図1)が実行する処理であり、ハードウェア的にはシステムサーバ100が実行する処理である。
配送完了処理が終わると、システムサーバ100は、依頼データベース124から配送依頼の情報を読み込む(ステップS80)。同様に、システムサーバ100は、拠点データベース121から拠点間の基本料金などの情報を読み込む(ステップS81)。
次に、システムサーバ100は、配送依頼の情報と拠点間の基本料金などの情報に基づいて、減額分や割増分の計算処理を行う(ステップS82)。すなわち、たとえば、帰り便の場合や配送者キャンセルの場合には、基本料金に対して任意に定められた割引率R1、R2を乗ずることにより減額分を算出する。冷凍車などの車種指定がある場合には、基本料金に対して任意に定められた割増率R3を乗ずることにより増額分を算出する。また、配送者による任意の割引設定がある場合には、基本料金に対して配送者が設定した割引率R4を乗ずることにより減額分を算出する。さらに、荷物引受処理において、荷物引受の超過時間が生じた場合には、その分、配送者を待たせたことになるため、超過料金を増額分として算出する。
さいごに、システムサーバ100は、基本料金に対して、増額分や減額分を加減することにより配送料金を計算する(ステップS83)。このようにして計算された配送料金が荷主に課金される。
図14は、料金計算処理のフローチャートである。図4のステップb7の処理に相当する。主として精算処理部136(図1)が実行する処理であり、ハードウェア的にはシステムサーバ100が実行する処理である。
配送完了処理が終わると、システムサーバ100は、依頼データベース124から配送依頼の情報を読み込む(ステップS80)。同様に、システムサーバ100は、拠点データベース121から拠点間の基本料金などの情報を読み込む(ステップS81)。
次に、システムサーバ100は、配送依頼の情報と拠点間の基本料金などの情報に基づいて、減額分や割増分の計算処理を行う(ステップS82)。すなわち、たとえば、帰り便の場合や配送者キャンセルの場合には、基本料金に対して任意に定められた割引率R1、R2を乗ずることにより減額分を算出する。冷凍車などの車種指定がある場合には、基本料金に対して任意に定められた割増率R3を乗ずることにより増額分を算出する。また、配送者による任意の割引設定がある場合には、基本料金に対して配送者が設定した割引率R4を乗ずることにより減額分を算出する。さらに、荷物引受処理において、荷物引受の超過時間が生じた場合には、その分、配送者を待たせたことになるため、超過料金を増額分として算出する。
さいごに、システムサーバ100は、基本料金に対して、増額分や減額分を加減することにより配送料金を計算する(ステップS83)。このようにして計算された配送料金が荷主に課金される。
D.効果および変形例:
以上、本発明の実施形態の一つを説明した。本実施例の配送サービスによれば、荷主が、荷物の詳細な情報を入力することなく簡便に配送依頼をすることができる。また、拠点間で基準料金を適用することにより、予測可能な配送料金のもと、より簡便に配送を依頼することができる。さらに、空車状態の帰り便を有効に活用し、経済的な無駄を軽減することができる。さらに、配送者は、より安価に、またより高い配送サービスを提供しようとし、このことは荷主に対する本発明による配送サービス利用の動機付けとなる。
以上、本発明の実施形態の一つを説明した。本実施例の配送サービスによれば、荷主が、荷物の詳細な情報を入力することなく簡便に配送依頼をすることができる。また、拠点間で基準料金を適用することにより、予測可能な配送料金のもと、より簡便に配送を依頼することができる。さらに、空車状態の帰り便を有効に活用し、経済的な無駄を軽減することができる。さらに、配送者は、より安価に、またより高い配送サービスを提供しようとし、このことは荷主に対する本発明による配送サービス利用の動機付けとなる。
本発明は、実施形態に限らず、種々の構成とすることができる。必要に応じて、システムの機能を簡素化して、より単純なシステムとすることもできる。
本発明は、荷主と配送者とをマッチングさせる配送サービスにおいて利用することができる。
100 システムサーバ
110 主制御部
121 拠点データベース
122 荷主データベース
123 配送者データベース
124 依頼データベース
130 送受信部
131 配送依頼受付部
132 マッチング処理部
133 キャンセル処理部
134 配送管理部
135 プロフィール登録部
136 精算処理部
200 荷主側端末
201 送受信部
202 ブラウザ
203 コマンド入力部
300 配送者側端末
301 送受信部
302 コマンド入力部
310 配送者用アプリ
311 位置情報送信部
312 プロフィール管理部
313 配送依頼管理部
110 主制御部
121 拠点データベース
122 荷主データベース
123 配送者データベース
124 依頼データベース
130 送受信部
131 配送依頼受付部
132 マッチング処理部
133 キャンセル処理部
134 配送管理部
135 プロフィール登録部
136 精算処理部
200 荷主側端末
201 送受信部
202 ブラウザ
203 コマンド入力部
300 配送者側端末
301 送受信部
302 コマンド入力部
310 配送者用アプリ
311 位置情報送信部
312 プロフィール管理部
313 配送依頼管理部
Claims (15)
- 荷物の配送を依頼する荷主と、該荷物を配送する配送者とをマッチングさせる配送マッチングシステムであって、
同一料金で配送可能な範囲として設定された複数の拠点と、該拠点間の基準料金とを記憶する拠点データベースと、
前記拠点のうち前記荷物を発送する引受拠点、前記拠点のうち前記荷物を届ける納品拠点を含み、荷物ごとの重量および寸法を含まない配送依頼を前記荷主から受け付ける配送依頼受付部と、
前記配送依頼を、前記配送者に送信するとともに、前記配送者から該配送依頼を受諾する旨の応諾を受けた場合には、両者をマッチングさせるマッチング処理部と、
前記荷物の配送に関して、前記基準料金に基づいて前記荷主への課金処理と、前記配送者への支払い処理とを行う精算処理部とを備える配送マッチングシステム。 - 前記マッチング処理部は、予め登録された車両情報または配送者の属性が配送依頼に応じた条件に合致する配送者にのみ前記配送依頼を送信する請求項1記載の配送マッチングシステム。
- 前記マッチング処理部は、時間の経過とともに段階に前記条件を緩和して前記配送依頼を送信する請求項2記載の配送マッチングシステム。
- 前記配送者を絞り込む条件として、帰り便という条件を用いる請求項2または3記載の配送マッチングシステム。
- 前記マッチング処理部は、前記配送依頼に応諾した配送者のいずれかを制限時間内に荷主が選定しない場合には、所定の条件に基づいて応諾した配送者のいずれかを選定して前記荷主とマッチングさせる請求項2〜4いずれか記載の配送マッチングシステム。
- 前記精算処理部は、帰り便の条件によりマッチングさせた場合は、前記基準料金よりも割り引いた料金を適用する請求項1〜5いずれか記載の配送マッチングシステム。
- 前記精算処理部は、荷主が、配送に利用される車種を限定した場合は、限定に応じて基準料金よりも割り増した料金を適用する請求項1〜6いずれか記載の配送マッチングシステム。
- 前記精算処理部は、荷主が配送者を選定した後に配送者がキャンセルした場合の再配送依頼に対しては、基準料金よりも割り引いた料金を適用する請求項1〜7いずれか記載の配送マッチングシステム。
- 前記マッチング処理部は、前記配送依頼に応諾した配送者の属性を前記荷主に提示する請求項1〜8いずれか記載の配送マッチングシステム。
- 前記配送者の属性には、過去に配送依頼を行った荷主による該配送者に対する評価が含まれる請求項9記載の配送マッチングシステム。
- 前記配送者の属性の登録内容を前記配送者から受け付けて反映させるためのプロフィール登録部を有し、
前記精算処理部は、前記登録内容に応じて、該配送者への支払い条件を変動させる請求項9または10記載の配送マッチングシステム。 - 前記配送者の車両の位置情報に基づき、該車両が前記引受住所地に至った後、所定の距離以上ずれたことを検出した場合に、前記荷物の前記配送者による引受完了として、前記配送を管理する配送管理部を備える請求項1〜11いずれか記載の配送マッチングシステム。
- コンピュータにより、荷物の配送を依頼する荷主と、該荷物を配送する配送者とをマッチングさせるマッチング方法であって、
コンピュータが実行するステップとして、
同一料金で配達可能な範囲として設定された複数の拠点と、該拠点間の基準料金とを記憶するステップと、
前記拠点のうち前記荷物を発送する引受拠点、前記拠点のうち前記荷物を届ける納品拠点を含み、荷物ごとの重量および寸法を含まない配送依頼を前記荷主から受け付けるステップと、
前記配送依頼を、前記配送者に送信するとともに、前記配送者から該配送依頼を受諾する旨の応諾を受けた場合には、両者をマッチングさせるステップと、
前記荷物の配送に関して、前記基準料金に基づいて前記荷主への課金処理と、前記配送者への支払い処理とを行うステップとを備えるマッチング方法。 - 荷物の配送を依頼する荷主と、該荷物を配送する配送者とをマッチングさせる配送マッチングシステムにおいて、システムサーバに接続され、前記荷主が利用する荷主側端末機に用いられるコンピュータプログラムであって、
同一料金で配達可能な範囲として設定された複数の拠点と、該拠点間の基準料金とを参照する機能と、
前記拠点のうち前記荷物を発送する引受拠点、前記拠点のうち前記荷物を届ける納品拠点を含み、荷物ごとの重量および寸法を含まない配送依頼を送信する機能と、
前記配送依頼に対する前記配送者とのマッチングの結果を受信して表示する機能とを実現するコンピュータプログラム。 - 荷物の配送を依頼する荷主と、該荷物を配送する配送者とをマッチングさせる配送マッチングシステムにおいて、システムサーバに接続され、前記配送者が利用する配送者側端末機に用いられるコンピュータプログラムであって、
前記拠点のうち前記荷物を発送する引受拠点、前記拠点のうち前記荷物を届ける納品拠点を含み、荷物ごとの重量および寸法を含まない配送依頼を受信して表示する機能と、
前記配送依頼を受諾する旨の指示を送信する機能とを実現するコンピュータプログラム。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2020087804A JP2021182293A (ja) | 2020-05-20 | 2020-05-20 | 配送マッチングシステム |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2020087804A JP2021182293A (ja) | 2020-05-20 | 2020-05-20 | 配送マッチングシステム |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2021182293A true JP2021182293A (ja) | 2021-11-25 |
Family
ID=78606659
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2020087804A Pending JP2021182293A (ja) | 2020-05-20 | 2020-05-20 | 配送マッチングシステム |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP2021182293A (ja) |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP7390083B1 (ja) * | 2023-04-10 | 2023-12-01 | 株式会社イージー | 陸送業者マッチングシステム、陸送業者マッチング方法、及び、陸送業者マッチングプログラム |
WO2024147404A1 (ko) * | 2023-01-04 | 2024-07-11 | 쿠팡 주식회사 | 배달 업무의 할당을 설정하는 전자 장치의 동작 방법 및 이를 지원하는 전자 장치 |
-
2020
- 2020-05-20 JP JP2020087804A patent/JP2021182293A/ja active Pending
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2024147404A1 (ko) * | 2023-01-04 | 2024-07-11 | 쿠팡 주식회사 | 배달 업무의 할당을 설정하는 전자 장치의 동작 방법 및 이를 지원하는 전자 장치 |
JP7390083B1 (ja) * | 2023-04-10 | 2023-12-01 | 株式会社イージー | 陸送業者マッチングシステム、陸送業者マッチング方法、及び、陸送業者マッチングプログラム |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US20220351135A1 (en) | Predictive analytics for transport services | |
US11593786B2 (en) | Examples of delivery and/or referral service SMS ordering | |
US20210319380A1 (en) | System and method for facilitating a transport service for drivers and users of a geographic region | |
US9928540B1 (en) | System for integrating courier service with customer applications | |
US10268982B2 (en) | Carrier and shipper interfacing and shipment tracking framework for efficient scheduling and transportation of cargo, with security monitoring and efficient payment to carriers | |
US20170236088A1 (en) | Delivery method and system | |
JP7340652B2 (ja) | 共用車両管理装置、共用車両管理システムおよび共用車両管理方法 | |
US20150032485A1 (en) | Digital method For Providing Transportation Services | |
US20210312413A1 (en) | Application programming interfaces for structuring distributed systems | |
US20160210675A1 (en) | Ordering products / services | |
US20060136254A1 (en) | System and method for dispatching transportation to persons who want transportation | |
US20130103437A1 (en) | Digital method for providing transportation services related applications | |
WO2004013733A2 (en) | Method, system and apparatus for providing transportation services | |
US20140108663A1 (en) | Control system for real-time complex resource allocation | |
US20090099971A1 (en) | Methods and systems for marketing distressed inventory | |
JP2022110048A (ja) | 分散システムを構造化するためのアプリケーションプログラミングインタフェース | |
JP2021182293A (ja) | 配送マッチングシステム | |
JP2003256511A (ja) | 運送業務管理方法、運送業務管理システム、運送業務管理装置、運送業務管理用Webサーバ、運送業務管理用表示装置、荷送人端末装置、荷受人端末装置、運送業者端末装置、運送用車両 | |
KR20170023058A (ko) | 조합 방식의 운송차량 임대시스템 | |
KR20060097298A (ko) | 여행상품 중개 판매 시스템 및 방법 | |
KR102425961B1 (ko) | 차량 정비 서비스 통합 관리 시스템 및 이의 서비스 제공 방법 | |
KR20180029990A (ko) | 조합 방식의 운송차량 임대시스템 | |
KR20090127790A (ko) | 인터넷을 이용한 논스톱 퀵 서비스 배송 시스템 | |
JP2003256981A (ja) | 回送レンタカー運用方法及びそのシステム | |
KR20020005516A (ko) | 화물운송 자동배차 방법 및 그 장치 |