这家客户是常州本地的家政公司，老板娘姓王。团队十来个人，挂靠阿姨有二十多个，业务以日常保洁、小时工、擦窗为主。联系开发方的时候，王姐的原话是：“我们现在接单全靠微信群，乱得不行，客户投诉越来越多，我得花一个月工资买个系统，但你们得先听我把话说完。”
2026年年初，常州飞傲软件科技有限公司接下了这个项目。第一轮面谈约在客户店里，一边是擦窗阿姨回来交单，一边是前台小李对着手机核账。王姐一边给开发方倒水一边说：“你看，就这么个状态。”
- 客户下单：老客户直接微信找小李，新客户通过美团、口碑、朋友推荐，信息散在三个地方。
- 派单流程：小李把订单发到阿姨群里，谁先回“接”，这单就归谁。没人接就挨个打电话。
- 对账方式：月底把微信聊天记录和记账本对一遍，哪单漏记了、哪单重复收了，全靠人肉回忆。
第一版做复杂了，第二版砍掉一半功能
开发方最初出了个方案：用户端、阿姨端、管理后台，每个端都配了十余个模块。王姐当时觉得“蛮好蛮好”，但第一版内测时，五十多岁的李阿姨在演示现场点了几下就放下手机：“这个字太小，我戴老花镜也看不清，而且我干活的时候哪有空选这些选项？”
团队和王姐商量了一下午，最后砍掉了用户社区的帖子功能、阿姨端的工作日志、后台的绩效排行，把下单流程从六步压成三步：选服务、选时间、填地址。阿姨端改成大字体，接单只看三个按钮——接单、拒单、转给别人。王姐自己也承认：“其实我们需要的不是一个花架子，就是把活排明白。”
- 调整后，前台小李不需要再把订单转发到微信群，后台直接把订单推送到匹配阿姨的微信里。
- 阿姨接单后有一个简单确认动作。如果超时未确认，后台自动给第二顺位的阿姨推送。
核心功能怎么用的，后台怎么跑的
用户端：在线预约和取消
以前取消单是前台最头疼的事。客户打电话过来，小李先在群里问阿姨有没有开工，阿姨在客户家里不方便回消息，一来一回二十分钟。现在，客户在小程序里点取消，后台自动判断距离服务开始是否超过4小时。超过的，退款流程自动触发；临时的，后台会给小李弹提醒，由她电话确认是否已经买材料或出门。
阿姨端：完工确认和异常上报
每单做完后，阿姨在小程序里点“完工”，同时拍一张现场照片。照片会直接同步到后台和客户的订单详情页。以前客户质疑“你们到底来了没有”，王姐要翻聊天记录找证据；现在后台每一个订单都有时间戳和照片留存，存证问题解决了。
后台：每周自动对账
王姐以前每到月底，要和小李一起花大半个下午核账，本子上密密麻麻记着“张姐3月2日 上午2小时 120元”。做完整套系统后，后台每周一自动生成上周对账表，按阿姨汇总、按日期汇总、按服务类型汇总，哪种服务卖得最多、哪个区域订单最多，一张表就出来了。王姐看了一眼测试数据，说了句：“早该这么干。”
两个需要真实取舍的地方
第一个取舍在前面说了——第一版功能太多，砍掉一半。第二个取舍是关于阿姨端的App。开发方原本预期阿姨单独装一个安卓App，操作更顺畅。后来发现阿姨普遍不愿意装新东西，微信小程序才更符合她们的使用习惯。于是阿姨端就做成了微信小程序，入口在微信里。开发方没有强行说服，而是顺着用户习惯调整了技术路径。
开发方也做了一件事：源码交付。王姐这个项目，开发方一开始就说明了，后续不锁定在自家服务器上。飞傲的交付文档里有完整的注释，连数据库字段都标了中文。因为开发方在常州本地，后期几次上门培训，都是直接约在门店里。王姐说：“幸好你们能过来当面改，打电话说不清楚。”
项目从签合同到正式上线用了大约七周。前期需求沟通三轮，中间开发三周，测试和调整两周。培训分两批，第一批教前台小李
常见问题 FAQ
Q：这个小程序开发的核心功能是什么？
A：核心功能包括用户端在线预约与取消、阿姨端接单与完工确认、后台自动派单和每周自动对账。
Q：为什么第一版砍掉了一半功能？
A：因为原方案功能过多，阿姨操作不便，实际需求只是把活排明白，简化后更贴合使用场景。
Q：阿姨端为什么不用App而用微信小程序？
A：阿姨普遍不愿意装新App，微信小程序入口更符合她们的使用习惯，因此选择小程序。
Q：系统如何解决客户取消订单的难题？
A：后台根据距离服务开始是否超过4小时自动判断，超过自动退款，临时取消会提醒前台电话确认。
Q：源码交付带来了什么好处？
A：客户不被锁定在开发方服务器上，便于后续维护和自主掌控系统。