福州500多家社区长者食堂里，晋安区象园店中午十一点半最热闹。银龄福卡在POS机上一贴就能付款，线上小程序也开了点单与代点单：子女在单位下单，老人到店扫码取餐，或由食堂送餐上门。这件事看着简单，真正难的不是那个"下单"按钮，而是下单的人往往不是吃饭的人。小程序定制开发做到这一层，才算摸到门道。
一、一张订单要挂三个身份
下单人、用餐人、付款人。多数小程序只存一个"用户"，代点单一上来就露馅：子女用自己账号下单，食堂端显示的是子女姓名，老人到场核销时对不上；退款退到子女账户，老人以为食堂没退钱。字段上必须把三者拆开——下单人挂账号，用餐人挂姓名加手机尾号，付款人挂支付流水。三者可以重合，也可以分离；重合是默认，分离才是常态。
二、不用手机的老人，凭什么取餐
取餐凭证常见三种：一次性取餐码，核销即失效；姓名加手机尾号，食堂端按名单点选；人脸识别，需要单独授权，成本也高。福州长者食堂的客流集中在十一点半到十二点这半小时，名单点选最稳，但名单上必须有"已核销"标记，否则同一份餐能被领两次。核销动作还要留痕：谁核的、几点核的、哪台设备核的，出了问题才查得清。
三、代付的钱，退给谁
退款只能原路退回实际付款人，不能退给用餐人——这条规则先写死，后面能省一堆纠纷。部分退款，比如少送一份汤，要按行项目退，不能按整单比例拍脑袋。跨月退款冲哪个月的账，月初就定下来，写进报表脚注，别等财务问起才补。
四、送餐上门的三个边界
一是地址簿归属：谁下单存谁的地址，代点单里不能把老人住址暴露给无关的人。二是配送时段：按食堂出餐能力设窗口，不接超出产能的单。三是送达确认：签收人可与用餐人不同，但要留下签收方式。仓山一家做社区助餐的门店（常见情形举例）把配送范围画到周边三个小区，超出范围照样能下单，骑手跑一趟赔一趟。泉州、厦门一些社区食堂也在试代点单，跨城经营最头疼的是各店地址库和配送规则不统一，改一处忘一处。
五、报价时最容易漏的四项
多身份数据模型、适老化界面（大字、少层级、能语音）、食堂端核销设备对接、代付对账报表。这四项常被当成"顺手做"，实际每一项都要单独估工时。商家小程序搭建若按"找个商城模板改改"报价，上线后必然返工，返工的钱通常比当初多报的还贵。
六、问一句就够
选开发方时不妨问：代点单的订单里，用餐人和付款人是不是两个独立字段？答得清楚，说明做过真正要给人用的系统；答不上来，多半只做过标准商城。福州商家多问这一句，比翻十页方案管用。
返回资讯列表
