配達履歴はウェブ上で確認できます。リクエスト受付時間、配達時間、距離、売上。
また、取引情報では配達完了の報告時刻も確認できます。配達完了操作を行った時刻のようです。
300件ほどウェブ上のデータと実配達時のメモを比較してみました。ただ距離については実測していないので未確認です。
配達完了時刻から配達時間戻った時刻がピックアップ時刻だと思うのですが、どうも実際の配達時間より長い場合が多いようです。
多くはお店への到着時刻がピックアップ時刻のようで、こちらが配達開始の操作をした時刻ではないようです。
記録によっては、ピックアップがリクエスト受付時刻より前になってしまうケースが1件あり謎です。
そして、リクエスト受付時刻ですが、これは、私が応答した時刻とほぼ同じ場合が多いのですが、たまに、10分以上違いがあるケースがあります。
では、実際の例です。
例１:12:08リクエスト、こちらの応答時刻は12:09、配達開始（ピックアップ完了）時刻は12:26、ドロップ完了時刻は12:35。配達時間14分25秒。距離2.43km。
上の例で、ドロップ完了から配達時間を戻ると12:21になります。このケースではメモによると店舗到着は12:17。この時刻は来訪を告げて、少し待つ場合にメモしています。
到着すると、お店の端末で何か確認しているようですが、どうもこれがピックアップの時刻として記録されるタイミングのようです。
到着と同時に商品を渡される場合は、どのタイミングでお店側がピックアップのタイミングとなる操作をしているのか見えませんが、記録から推測すると、商品が出来上がったタイミングではないかと思います。
履歴の配達時間は必ずしも実際の配達時間ではなく、お店がピックアップ操作した時刻から配達完了までの時間のようです。なので、ロングピックアップの場合、配達時間にピックアップの時間も一部含まれている可能性があり、お客さんには遅延ととられかねません。
例2：受付・同応答時刻が14:35で配達完了が15:02。その次のリクエストに応答したのは15:04。ピックアップ15:13、ドロップ15:19。配達時間6分46秒。距離0.77km。
この15:04に応答したリクエストの受付時刻は、ウェブ上の履歴によると14:05となってました。一つ前のリクエストより前のリクエストを1時間以上経ってから配信されたものでした。
ドロップに際して、特にクレームはありませんでした。というか、応対の様子は覚えていないので、ありふれたドロップだったと思いますが、お客さんはどのように思っていたのでしょう。不安です。
システム側の都合で、リクエストからの時間がより経過している案件を熟成案件と配達パートナーの間では呼ばれているそうです。スラングの類ですが、この1時間の遅延は350件の案件中では1件でしたが、30分くらいのものは数件ありました。
熟成かどうかは、配達が完了して履歴が登録されるまで知ることが出来ません。連続して配達が続けば読んでるヒマはないので、帰宅後に気づくくらいです。
評価は95％。この-５％が気になりますが、不手際だったという案件の記憶は無いし、指摘もないので、案外こういう熟成案件がからんでいるのかも。
以前マニュアルに、配達開始の時に「これから配達に出発する」という連絡を入れるという先輩の例がありましたが、この熟成案件のフォロー策だったのかな、と思います。実際は不明ですが。
注文アプリを使ったことがないのであれですが、配達に関する注意メモ、ドアの前に置いて下さいなど、は配達開始操作後にすぐ送られてくることから、配達開始時刻をお客さんは把握していると思ってました。
とはいえ、お客さんにとって遅延の責任は全て配達パートナーが負うようなものなので、お店から配達を開始した旨を連絡するのは、遅延があっても私の責任範囲の配達に関しては問題ないよと暗に宣言することになり、少しは不評回避になりそうかも。
ただ、熟成かどうかわからないので、全ての案件で送信する必要があるので、・・・どうしましょう。めんどいから数パーセントは気にしないという手もあるかな。
いやいや、顧客満足度のためにひと肌脱ぐのは当然ではないかと思えば、どうせピックアップ時刻は店任せならば、店への到着直後にピックアップ完了にして、商品待ちの間に送信すれば良いだけなので・・・うん、そうしよう、
かな。
