把待办聚合成可处理的队列。
一次高风险处置,为什么要在四个页面之间来回切换?
上午,运营在待办队列发现一间商户同时出现资质待审核、商品违规未申诉与待结算订单。要不要限制经营,不能只看一个红色状态,还要确认违规是否成立、哪些交易会被中断,以及商户是否有补充材料。
这些依据却散落在商户、审核、商品、订单与结算入口。运营先拼凑事实,审核再重复核验,商户也不知道下一步该补什么。项目从这里开始:让一次处置从发现问题到留下结论,始终围绕同一间商户完成。



- 01运营发现从待办队列发现需要处理的商户。
- 02审核核验回看主体、经营状态与风险依据。
- 03商户补充提交资料并接收审核结论。
- 04完成处置更新状态,记录动作与处理原因。
让每一次商户处置,都知道下一步
不要求用户记住每个入口。系统先把需要处理的商户推到面前,再依次展开状态、依据与可执行动作,最后把结论留成可回看的记录。
在同一详情确认主体、经营与资质。
异常原因、规则阈值与建议动作一并说明。
记录状态变化、处置原因与操作人。
先看见今天最该处理的商户
运营面对的不是一张普通商户清单,而是几类性质不同的待办:待审核资质、违规处理中、店铺封禁中。列表按处理原因聚合,而不是按创建时间平铺,让会阻塞入驻或影响经营的对象先被看见。
家居日用 / 家具软装商品: 326
订单: 4,286
GMV: ¥386,420.00正常营业中
食品饮料 / 休闲零食商品: 184
订单: 1,164
GMV: ¥128,760.00待审核资质
数码家电 / 智能配件商品: 73
订单: 638
GMV: ¥76,940.00店铺封禁中
没有符合当前筛选条件的商户。
让判断始终围绕同一商户
商户详情页不只是资料陈列,而是一次连续判断:先核验身份、资质与经营状态;出现异常时,直接看到规则命中和建议动作;完成审核后,把结论写进可追溯的处置记录。
商品、订单与结算,都是同一判断的证据
商品、订单与结算不是彼此独立的后台,而是同一商户的经营证据。切换视图时,商户身份与经营状态始终保留,避免运营在不同系统里反复确认对象。
高风险动作,先看清影响再执行
以封禁商户为例:操作前核验依据,操作中确认权限、影响范围与时长,操作后留下可追溯的记录。
汇总审核、商品、订单与结算证据。
校验权限,明确影响范围与封禁时长。
记录操作人、时间、原因与状态变化。
风险依据:违规事件未完成申诉,且发生在当前治理周期内。
风险依据:存在多项待处理或申诉中的商品违规,需先判断影响范围。
风险依据:封禁会暂停新增订单与待结算款项,必须在操作前明确资金影响。
该操作将影响商户的经营与结算,请谨慎操作。
封禁指令已记录,处置状态已同步到操作留痕。
让每一次处置,都有据可查。
让治理真正服务于业务。
真正的商户治理,不是展示更多数据,而是在需要判断的时刻,让相关信息一起出现。从发现风险、核验依据,到确认影响与留下记录,处置才成为一条连续、可信的治理路径。
项目数据均已脱敏。本人负责信息架构、核心处置流程与组件状态设计。