餐车收摊即结薪
小店收摊时确认当天异常班次，即可汇总工资、小费、税款预留和会计所需文件。
餐车、小摊和快闪店收摊时，员工用贴在工作区的固定二维码登记到岗和离岗。老板不必整天维护后台，而是在每天关店后打开一张结算页，看到当天班次、销售额、小费和异常工时。漏打卡、超长班次或小费分配异常会被单独挑出，其他记录默认直接进入待结算状态。
老板逐项确认少数异常后，产品按已设置的岗位、时薪和小费规则生成每人应付金额，并把销售记录与班次对应起来。若员工临时换班，页面会要求确认实际工作人和交接时间，避免把金额算到错误的人名下。结算完成后，每位员工只会收到自己的工时、小费和应付摘要，不会看到同事的收入。
月底，系统把已确认的班次、工资和税款预留整理成会计可导入的文件，并保留修改痕迹供复核。第一版不替雇主提交报税或自动打款，也不猜测当地劳动法；税率、加班规则和小费政策必须由店主或会计先确认。它先解决每天收摊后最容易散落的事实记录，再把这些记录交给现有薪资流程。
为什么是现在
7月25日，一名餐车业主公开询问能否把员工打卡、工资和税务放进同一应用；其现状仍是手工记工时，再交由会计处理工资与税务。S1
目标用户
核心用户是员工人数不多、营业地点经常变化的餐车、小摊和快闪店老板。最痛的时刻是关店后清点现金、核对小费并准备工资资料时。此时员工已经离场，漏打卡和临时换班很难再追问。老板需要的不是持续维护排班后台，而是快速确认当天事实，并把可信结果交给会计。
最小切入点
从单一 POS 生态切入，优先连接 Square。Labor API 可读取和更新工时卡，并包含岗位、工资率和现金小费字段。S2 Payments API 可按商家账户读取付款记录。S3 员工通过固定二维码进入轻量网页，用短期凭证确认身份后打卡。服务端按营业日汇总工时、销售和小费，再用明确规则标记异常。首版不做税务计算引擎，也不发起工资支付。输出采用通用 CSV，并保留每次修改的操作者、原值和新值。
以小博大
先在餐车协会、本地餐饮经营者群和会计师客户群中寻找仍用纸表的店主。提供一张可打印的二维码模板，以及一份真实收摊数据的导入演示。与服务小餐饮客户的独立记账员合作，让其把结算页作为月末对账前置步骤。获客内容应围绕漏打卡、小费争议和换班错付三个具体问题，而不是宣传完整薪资替代。
竞品与缝隙
- HomebaseGoogle
- Homebase 已提供共享平板、电脑或 POS 上的员工打卡，并用个人 PIN 识别员工。工时和休息记录会汇入工资表，还能提示漏打卡与加班问题。S4 它覆盖排班、工时和薪资，是功能更完整的直接替代品。可切入的缝隙不是再做一套完整人事系统，而是服务没有固定收银台的餐车和快闪摊位。固定二维码可减少安装员工应用、配置共享设备的阻力。收摊页还应把销售、小费和换班交接放在同一次确认中。产品价值取决于老板能否每天快速处理少数异常，再把结果送入原有会计流程。若用户已经深度使用 Homebase，迁移价值会很弱。更现实的定位是补充层，而不是要求商家替换现有薪资系统。
- Square POS + Square ShiftsGoogle
- Square 的 Labor API 可读取和更新工时卡，也能记录岗位、工资率与现金小费。Payments API 则可读取商家的付款记录。S2S3 因此，使用 Square 的商家已经具备连接销售与工时的数据基础。真正的缝隙在收摊后的核对动作，而不是数据采集本身。可把漏打卡、超长班次、换班和小费差异集中到一页，让正常记录直接待结算。固定二维码还可覆盖员工不接触 POS 的摊位工作区。难点是不能把付款时间简单当成某位员工的贡献，也不能擅自推断小费归属。若 Square 已能完整满足商家的工时与薪资流程，这个产品只能依靠更短的每日确认路径取胜。首批客户应是使用 Square 收款，却仍靠纸张或聊天记录补工时的经营者。
怎么赚钱
按营业点收取月度订阅费，包含基础员工额度、每日结算页和会计导出。超过额度的员工按阶梯加价。POS 数据连接可作为付费附加项，报税和打款仍由现有薪资服务承接。
反方视角
固定二维码容易被转发，员工可能在未到现场时打卡。若加入定位、自拍或设备绑定，隐私争议和支持成本会迅速增加。销售与班次也并非天然对应，多人协作和跨班付款会造成错误归因。小费规则常受岗位、班次和当地规定影响，错误分配会直接损害员工信任。税款预留若被理解为准确税额，还可能让老板产生错误依赖。产品必须清楚区分原始记录、店主规则和人工修改。若每天仍需处理大量例外，收摊页就会变成另一套繁琐后台。