例外
用量汇总依据不确定时
不擅自填金额，标注需确认，交由人核验。
在线独立创业者每到月底都要用表格把用量扒到一起，手动跟 Stripe 账单对齐，一有计费咨询又得回头翻日志。用量事件、套餐设置、账单明细、咨询各在一处，超额和差错往往很晚才发现。计费一旦对不上，信任和营收会同时漏掉。
这样的数据，会这样整理。
把真实进来的活儿归拢起来，连每一步依据什么判断，也一并留下来。
-
用量、计费信号汇集
把用量事件、套餐超额、计费咨询、支付失败汇到一条队列。
判断 用账号标识把用量与计费归并。为的是不把同一账号的数字散着放。 -
用量汇总、比对
按账号汇总用量，与套餐额度、账单明细比对。
判断 先把汇总与实际计费对不上的项上报。因为在计费前不抓住，就会变成多计或少计。 -
计费摘要初稿
做好计费摘要、超额说明、咨询答复的初稿。
判断 不定金额，只整理依据上报。金额确定属于人。 -
支付失败、结算准备
把支付失败重试与结算资料整理好，上报给人。
判断 发出计费的动作只做准备，确定交给人。 -
计费跟踪卡
做一张含账号、用量、计费状态、下一步动作的卡片，作为未结项跟踪。
判断 挂上结案条件（计费确定、咨询解决），让它不会从队列里消失。
依据不确定，就不确定金额。
现场真正会卡住的例外，我们提前定好。规则套不上的时候不硬办，连同依据一起交给人。
例外
超额疑似临时故障时
不马上计费，作为原因确认清单上报，交由人判断。
例外
计费咨询与退款请求混在一起时
把计费确认开为主案例，把退款判断单独分支，上报给人。
计费金额和抵扣额度，由人确定。
牵扯到钱、合同、个人信息和品牌的执行，只做到草稿为止；发送与敲定，要等人审批之后才动。
-
计费金额确定
是涉及钱的核心判断，始终由人确定。
-
费用调整、抵扣额度发放
是会成先例的金钱调整，属于人。
-
批量计费发送
一旦发出更正就麻烦，由人检查后再发。
-
超额费用追加计费
是向客户卡上扣款的动作，回退之前由人确定。
-
发票、结算资料确定
开错有负担，由人检查。
用什么来确认
看计费是否又准又快。
计费准备时长
在导入前后实测从用量汇总到计费摘要完成的时长。
计费咨询条数
在导入前后测量计费相关咨询的条数。计费越准，越少。
支付失败恢复率
在导入前后测量失败支付中重新成功的比例。
规则
会处理用量与支付信息这类敏感个人信息，因此按目的最小化保存，计费金额与开具在人确认之后再确定。
需要人亲自扛着的事变少了。
散落的核对和重复的回复先整理好递上来，员工就能把时间花在复核和例外上，人只看真正要紧的决定。
运营诊断待确认的事都堆到人身上。
每到月末就用电子表格把用量凑齐、手工对账单，来了咨询还得再核一遍。
备好的活儿先递上来。
用量和账单咨询汇进一个队列，连摘要都备好，金额由人来确定。
账单准备时间
账单咨询条数
扣款失败挽回率
把这件事托付出去之前，大家会问什么
关于按用量计费，大家实际上最先确认的那些问题。
计费金额是 Velros AI 确定的吗？
用量汇总与计费摘要会准备好，实际计费金额确定与发送由人确认后再执行。
对超额的客户会自动计费吗？
只上报到超额说明初稿，追加计费或套餐上调由人判断。
发票也在这里开吗？
把开票所需的分项用量明细整理上报，实际开具由人检查后再进行。
