该由人确认的事，串成一条线。
不再多加一块新界面，而是把现有渠道进来的活儿理清楚，只把该由人拍板的决定挑出来。
渠道照旧
无需增加新工具，直接在您正在使用的邮件、店铺咨询、GitHub Issue、Discord之上叠加Velros AI。我们一起搭建所需的界面、待审批箱和报表，跑起来再逐步改进。
插件与主题
- 咨询渠道统一
- 退款与授权审批
- 故障复现整理
原有的触点保留，只把该由人确认的事挑出来。
咨询渠道统一 · 退款与授权审批 · 故障复现整理
这样的咨询，这样处理。
插件与主题每天真实进来的请求，连同要确认的事和下一处该改的地方，都留在一屏里。
过去靠人一件件盯着的顺序，原样搬过来。
- 分类 把散落在邮箱、微店店铺和 GitHub Issue 里的请求，自动归为安装、故障、授权、退款、评价几类。
- 核对 用订单号比对付款与授权发放记录，故障则记录到具体的 WordPress／PHP 版本和复现条件。
- 起草 临时解决办法或是否退款的回复，按顾客的语气先拟好草稿。
- 审批 退款、重发授权、路线图调整都以审批卡呈现，您点一下即可发出。
看得见的
把从邮件、店铺咨询、GitHub Issue、Discord进来的原文、日志、员工修改和待审批原因都留存下来，作为下一个版本改进的依据。
停下来的
退款、授权与价格调整、路线图承诺、批量群发，均需负责人或主管确认后再执行。
懂这行的人，和你一起把标准立起来。
Velros运营设计师与一线专家一起，把安装与故障处理、授权、退款、功能建议的处理标准，转化为可落地的运营流程。
Velros 运营设计团队
行业的标准设计与每周改进
持续改进
把员工的修改和暂缓的缘由收拢起来，重新整理成下一周的运营规则。
人的时间
重复的核对少了，人就能把更多时间放在要紧的决定和增长机会上。
深入
安装咨询堆积的时候，开发者做不出下一个版本
卖出一个插件或主题，咨询就没完没了。装不上、和别的插件冲突、许可证密钥不生效、要退款。其中大部分要么文档里已经写了，要么重装一次就好，都是重复。可就在你被这些重复缠住的时候，真正要紧的修 bug 和下一个版本一直在往后拖。真正需要人来判断的，只有要不要退款、要不要再放一个许可证、这个需求要不要进路线图。
从收到咨询到处理完
-
把分散的渠道汇到一处
把散落在邮件、店铺(WordPress·Shopify)咨询箱和 GitHub Issue 里的消息归拢成一条，按同一版本、同一症状归类展示。
-
重复咨询整理成草稿退回
安装步骤、停用冲突插件、清缓存、重新激活许可证等文档里已有的答案，会按该用户的环境整理成回复草稿和 bug 复现清单。
-
需要判断的交给审批卡
退款、追加许可证、"把这个加进下一版"这类请求，会作为审批卡交给人来确认。在你发送之前，什么都不会发出去。
由人来确认的事
- 退款
- 撤销支付和退款，都在核对金额与理由后由人来批准。会把店铺政策和数字商品的退换条件并排展示。
- 许可证例外
- 站点数超额、密钥重发、开发用追加席位这类例外不会自动放开，由人确认。
- 路线图纳入
- 功能需求是进下一版还是做成付费插件，属于产品方向，由人来定。草稿只回复"审阅中"。
不能漏掉的期限与义务
- 数字商品的无理由退货例外
- 在线下载或消费者已拆封的计算机软件等数字化商品，不适用七日无理由退货(第二十五条)。是否退款按你公示的政策处理，并在售前把这一例外说清楚。
- 交易条件公示
- 退款、许可证条件、经营者信息和退货方式应在销售页面事先公示。草稿始终以你已公示的政策为依据来回复，而不是临时给例外。
- 个人信息处理
- 买家的邮箱和支付信息只在取得同意的目的范围内使用，不擅自提供给第三方。用于处理咨询的信息，只用于该目的。
《中华人民共和国消费者权益保护法》第25条 · 《中华人民共和国个人信息保护法》
常见问题
- 会自动发回复吗?
- 不会。重复咨询也只做到草稿，发送要在人确认之后才发出。退款、许可证一律走审批卡。
- 会一起看 GitHub Issue 吗?
- 会。把邮件、店铺咨询箱和 GitHub Issue 汇到一处，按同一版本、同一症状归类，还会把 bug 复现清单整理成草稿。
- 会替我定退款规则吗?
- 不会。规则以你设定的政策为准，原样作为依据。Velros 把这套政策和法定告知条件并排展示，最终由人来定。
进来的事
微信、电话、点评、邮件，在一处看
要确认的事
员工看的事和人看的事，分开
会变好的事
重复咨询和漏掉的跟进，每周都少一点