上门这行最容易在两处糊掉账：一处是车费，技师跑一趟二三十公里，油钱和时间算不算进服务价、算谁的、退不退，各座城的口径还不一样；另一处是分成，平台、门店、技师都要动这一笔，车费那份还得单独结，一到月底就靠人工对表。人的问题更麻烦：谁能接单、今天还能接几单、这个时段空不空，全靠群里喊，客服兼排班，漏一单就是一次投诉。

这套系统按车费独立核算、三方分账留痕、状态一段段推来搭：车费按城市配起步公里数与超公里单价，下单时用经纬度量出真实距离给出预估，并把当城的参数写成订单快照，事后改价改址都动不了已成单的那笔账；订单从待支付到服务完成分八个状态，技师端每个状态一个独立动作，平台与门店同屏看得到卡在哪一段；技师与门店各有独立账户与流水，每笔订单单独生成结算记录，服务佣金、车费、车费佣金、推广佣金分列存放。加钟走加钟单、换项目走补差价单，两张单都单独支付、单独退款，没人能把原单金额改乱。

  • 数据口径：订单、加钟与补差价、结算记录、技师与门店账户流水、提现申请、城市车费参数、地图密钥状态分别建表，服务地址与车费配置在下单时写快照，每笔余额变动都记下来源类型、来源单号与变动后余额
  • 风控口径：技师身份证正反面、人像实照、工作照、资格证、健康证与学历逐项上传、后台逐项审核，门店主体资质与每周营业时段另走一条申请审核线；服务半径与当日可接单量两道闸门，改派技师时只列该时段空闲的人并记下原技师与新技师
  • 交付边界：以现有上门调度能力为底子，按你的品类、客单与分成模型做定制；小程序主体、类目资质、微信支付与支付宝商户、地图密钥、短信与对象存储等账号由你方申请，实人核身、内容安全送检与自动打款需相应主体资质另行开通，具体上线范围、周期与授权边界以需求评估结论为准