去年我接了一个家政公司的外包需求,对方原本靠微信群和电话派单,每天光是协调阿姨时间就要耗掉两三个小时。做完这个小程序后,他们的接单效率提升了将近一倍。这篇文章把我在家政小程序开发过程中踩过的坑和关键设计整理出来,希望能帮到准备做类似项目的独立开发者。
先想清楚:家政小程序的核心是什么
很多人一上来就想着做功能大全,结果做出来没人用。家政小程序的本质其实就三件事:
- 让用户快速下单:选服务、选时间、填地址,三步内完成
- 让阿姨快速接单:看到订单、抢单或派单、确认上门
- 让平台能管住钱和评价:支付、退款、评价、投诉
其他的什么会员体系、优惠券、积分商城,都是后期锦上添花的东西,第一版千万别做。
技术选型与项目结构
我用的是微信原生小程序 + 云开发,没有自己搭后端。原因很简单:家政业务量不大,云开发的数据库和云函数完全够用,还省去了服务器运维成本。如果你团队里没有后端,这是最优解。
目录结构大致如下:
miniprogram/
pages/
index/ 首页-服务分类
order/ 下单页
orders/ 我的订单
worker/ 阿姨端-接单大厅
components/
service-card/ 服务卡片
time-picker/ 时间选择器
utils/
request.js 云函数调用封装
cloudfunctions/
createOrder/ 创建订单
grabOrder/ 抢单
updateOrder/ 状态流转
payCallback/ 支付回调关键功能实现细节
1. 服务与时间的联动选择
家政服务分很多种:日常保洁、深度保洁、家电清洗、月嫂等。不同服务对应的时长和可预约时间不一样。我的做法是把服务配置写在云数据库里,前端拉取后动态渲染,避免改一次价格就要发一次版。
// 获取服务列表
const db = wx.cloud.database()
const res = await db.collection('services')
.where({ status: 1 })
.orderBy('sort', 'asc')
.get()
this.setData({ services: res.data })2. 订单状态机设计
这是最容易出问题的地方。订单状态必须严格定义,否则后期退款、投诉会一团乱。我定义的状态流转是:
pending待接单accepted已接单serving服务中completed已完成cancelled已取消refunding退款中
每个状态变更都通过云函数做校验,禁止前端直接改数据库。比如抢单时用事务保证只有一个阿姨能抢到:
// 云函数 grabOrder
const order = await db.collection('orders').doc(orderId).get()
if (order.data.status !== 'pending') {
return { code: -1, msg: '订单已被抢' }
}
await db.collection('orders').doc(orderId).update({
data: { status: 'accepted', workerId: wxContext.OPENID }
})3. 地址与定位
家政服务必须知道上门地址。我用了微信的 wx.chooseLocation 让用户选点,同时保存经纬度和详细地址文本。注意:一定要做地址校验,有些用户会随便选一个点,导致阿姨跑错地方。
踩过的坑
支付回调的幂等性
微信支付的回调可能会重复触发,如果不做幂等处理,用户付一次钱可能生成两笔订单。我的做法是在云函数里先查订单状态,只有 pending 才更新为 paid。
阿姨端的权限控制
阿姨和用户用的是同一个小程序,通过角色字段区分。所有涉及阿姨操作的云函数都要校验 role === 'worker',否则普通用户也能调接口抢单。
时间冲突检测
同一个阿姨同一时间段不能接两单。我在创建订单时用数据库的 where 查询该阿姨当天已接订单的时间段,做重叠判断。这个逻辑放在云函数里,前端只负责展示。
上线后的数据反馈
小程序上线两个月,日订单从最初的十几单涨到八十多单。用户最常用的功能是「再次预约」,所以我在订单详情页加了一个快捷复购按钮,转化率明显提升。阿姨端反馈最好的是「一键导航」,直接调用地图导航到用户地址,省去了手动输入的麻烦。
给独立开发者的建议
- 第一版只做核心流程,别贪多
- 能用云开发就别自己搭后端,省时间
- 订单状态机一定要提前设计好,后期改很痛苦
- 多做角色切换测试,用户端和阿姨端都要走一遍
家政小程序的技术难度其实不高,难点在于业务流程的梳理。把状态流转和权限控制做扎实,剩下的就是堆页面的事了。如果你也在做类似项目,欢迎交流。
评论 (0)
还没有评论,快来抢沙发吧~