前端视角看上门履约：从用户下单到履约完成

上门履约服务是一种在客户指定地点提供产品或服务的业务模式。随着移动互联网技术的发展，上门服务变得越来越普遍，从家政服务、维修服务到医疗护理，各行各业都在尝试这种新的服务模式。

转转上门履约服务目前支持的业务有：上门回收，上门售后，上门寄卖，上门以旧换新等业务，目前已开通200+的城市支持上门业务。为方便描述下文简称「上门履约」，上门履约人员简称「工程师」，地图均使用高德地图演示。

本文将从前端开发视角探讨上门履约服务中的几个关键技术应用，根据实际的业务情况不同的履约服务可能有所差异，以下是上门履约业务从用户下单前到订单完成的流程图，本文将从用户下单前和下单后的履约服务分别介绍相关技术实现。

用户下单前

在用户下单前我们需要获取用户的经纬度信息或用户填写的上门服务地址信息，根据解析后的经纬度信息判断是否在履约服务区域，如该区域在履约服务区域中则分配对应的上门服务工程师，核心流程如下：

上述流程涉及的关键技术点如下：

用户位置

小程序平台：在小程序中我们可以调用类似wx.getLocation的能力获取用户经纬度信息，不同的小程序平台有一定的区别，但基本都有提供位置服务能力。
原生App中H5页面：在原生App中的H5页面可通过客户端提供能力获取用户位置信息，具体的调用方式可以和客户端开发人员约定。
浏览器H5页面：可以通过浏览器的Geolocation API来获取用户的位置信息。调用示例：navigator.geolocation.getCurrentPosition((position) => {})

以上位置调用都会涉及到用户权限，可能用户未授权或不愿意授权等原因导致无法获取到精准的位置信息，这种情况则需要通过用户的下单地址进行地理编码解析出对应的经纬度位置信息。如以下高德地图地理编码解析API接口示例：

vbnet 复制代码

https://restapi.amap.com/v3/geocode/geo?address=北京市朝阳区阜通东大街6号&output=XML&key=<用户的key>

返回结果字段如下：

地理围栏

上门服务并不是所有地方都开放服务，例如偏远地区，人流量少，景区，交通不便地区等。只会针对高密度下单区域开放履约服务，需要需要运营人员配置相关开放的区域即地理围栏，在高德地图中可以使用new AMap.PolygonEditor多边形编辑器绘制创建电子围栏（由点组成的闭合多边形图形）。

js 复制代码

const polygon = new AMap.Polygon({
  path: path,
  strokeColor: "#FF33FF",
  strokeWeight: 6,
  strokeOpacity: 0.2,
  fillOpacity: 0.4,
  fillColor: '#1791fc',
  zIndex: 50,
  bubble: true,
})
const polyEditor = new AMap.PolygonEditor(map, polygon);
polyEditor.setTarget()
polyEditor.open();

以下是创建完成的围栏效果，围栏最终会是一个一个的小块拼接起来，这里的每个小围栏最终会和上门工程师绑定，就像某团外卖小哥一样，每个上门工程师都会固定在某一个区域履约订单。

有了用户的位置信息和已开通的围栏数据，只需要判断该坐标是否在围栏内即可判断该地址是否支持上门履约。目前我们采用射线算法进行匹配，该算法从待判断的点向特定方向引射线，计算与多边形的交点个数。如果交点个数为偶数或0，则表示点在多边形外部；如果为奇数，则表示点在多边形内部。此外还需要单独处理一些特殊情况，例如点恰好位于顶点或边上的情况。

如果当前用户下单地址支持上门履约服务，用户下单后即可根据命中的围栏查询出对应的上门工程师，进行后续的履约服务跟进。

用户下单后

为了确保用户下单后能够以更高的效率完成订单履约，接下来将从订单分配、联系用户、订单导航以及路线规划等方面讨论实现过程。

订单分配

当一个上门履约服务的订单被创建时，会根据以下步骤来分配服对应的上门工程师：

根据用户订单中提供的地址信息，查询到该地址命中的电子围栏
根据地图围栏查找当日已排班的工程师。
确定工程师后就会将这个新的订单分配给这位工程师，并推送相关信息引导前往指定地址履约订单。

简单流程图如下图所示：

联系用户

上门履约并不同外卖场景，需要与用户面对面质检，导致可上门的时间区间有一定的浮动，所以用户下单后的首要环节是与用户取得联系，约定可以上门的时间和地点。这个场景会存在用户下单手机号码无法接通，履约地点信号差，用户下单地址模糊无法精确到门牌号等情况，目前有多种方式与用户取得联系。

隐私号联系：为保障用户隐私通过第三方隐私号与用户取得联系，平常大家接到的外卖和打车平台的电话都是隐私号联系。
App PUSH：发送App系统消息提示用户履约相关进度，如无法联系用户时提醒用户、上门工程师正在前往上门地点等。
短信提醒：在关键节点发送短信提醒用户。
IM聊天：上门工程师直接通过聊天的方式和用户沟通，此种方式的开发落地成本较大，但实现的效果较好，比如可以在聊天中发送精准的定位地址，拍摄相关建筑街道图片沟通履约地点和用户确认相关细节。

导航 & 规划

与用户确认上门时间后需要在约定的时间内前往履约，则需要上门工程师提前规划好履约订单顺序，以便达到最高效率完成订单。

// 折现路径
const LngLatArray = [
  new AMap.LngLat(116.368904, 39.913423),
  new AMap.LngLat(116.382122, 39.901176),
  new AMap.LngLat(116.387271, 39.912501),
  new AMap.LngLat(116.398258, 39.9046),
];
// 创建折线 Polyline 实例
const polyline = new AMap.Polyline({
  path: LngLatArray,
  strokeWeight: 5,
  strokeOpacity: 1,
  strokeColor,
  showDir: isShow,
  lineJoin: 'round',
  lineCap: 'round'
})
// 将折线添加至地图实例
map.add(polyline)

上述代码仅是导航轨迹的绘制，另外的起点、终点和预计时间及距离的标识需要单独设置AMap.Marker绘制。

履约规划

在实际履约过程中为了提高履约效率，这种我们需要对今日的订单规划履约路线，根据订单的紧急程度、地理位置、预计到达时间、周边工程师等因素，对订单进行排序，决定订单履约的先后顺序。避免发生来回跑单，降低履约成本。如下图所示，通过在订单上标记的数字，推荐给工程师订单履约的先后顺序：

地图也支持开启订单质检的履约路线，方便工程师快速了解导航行程，提高效率。

这里主要运用了点标记AMap.Marker的使用，通过content属性传入html标签内容，自定义需要显示的标记内容，如上图中的订单履约时间，先后顺序，是否联系过用户(不同颜色区分)等。并对每个订单的marker绑定点击事件便于后续的其他订单交互操作。

js 复制代码

const marker = new AMap.Marker({
  content: '<div>......</div>',
  position: [lng, lat],
  draggable: true
})
marker.on('click', (event, info) => {
  console.log(event, info)
})

质检服务

工程师们在到达客户指定的服务地点后，将开始进行质检服务。目前支持检测的设备类型包括手机、笔记本电脑、平板电脑、耳机和相机等，涵盖了多个不同的产品质检。

不同产品的质检方式有所区别，代码整体的复杂度较高。且由于该质检服务不仅用于上门服务，公司内部的其他业务场景也有需求，为了避免重复开发，我们决定将质检功能封装成一个独立的SDK。这样其他业务需要使用质检服务时，只需接入这个SDK，无需从头开始开发，提高了开发效率，并且方便统一管理和维护。

以上是对用户下单后的相关探讨，用户下单后系统自动订单分配给对应工程师、通过多种方式与用户联系确认上门细节、利用地图导航和路线规划以提高履约效率。此外质检功能被封装成SDK以供不同业务场景复用，从而提升开发效率和服务质量。

总结

本文从前端开发的角度出发探讨了在上门履约服务中的几个关键技术应用。涉及用户位置获取、地理围栏设置、联系用户、导航规划及质检SDK等环节。上门履约业务根据不同的上门场景有所差异，欢迎交流分享经验~

作者：王绪侨，转转FE，负责转转上门业务前端开发。

> 转转研发中心及业界小伙伴们的技术学习交流平台，定期分享一线的实战经验及业界前沿的技术话题。

> 关注公众号「转转技术」（综合性）、「大转转FE」（专注于FE）、「转转QA」（专注于QA），更多干货实践，欢迎交流分享~