赛事系统功能说明

本文档用于客服、售前、销售、实施与售后团队理解赛事系统。系统由两个端组成：

• 后台管理端：访问地址为 https://sport.pospal.cn/ ，面向赛事主办方、运营人员、裁判长、管理员，用于创建赛事、管理报名、生成签表、编排赛程、录入成绩、查看排行与维护系统设置。
• 移动参赛端：面向会员、选手、队伍管理人，用于浏览赛事、报名参赛、管理选手/双打组合/团队、查看签表、赛程、成绩，以及处理支付、退款申请、共享管理与代报名授权。

一句话介绍：赛事系统是一套覆盖“赛事发布、报名收费、名单确认、签表生成、赛程安排、现场录分、成绩发布、排行沉淀”的全流程管理系统，适合网球、羽毛球、综合体育赛事、机构内部赛事、俱乐部公开赛等场景。

1. 产品定位与适用场景

赛事系统面向的是“要长期、规范、可复制地办体育赛事”的商户，不是一次性报名表工具。它更适合已经有会员、学员、俱乐部社群或公开赛事运营需求的机构，把一场赛事从招募报名、收款审核、名单确认、排签排赛、现场录分到赛后成绩沉淀串成一条清晰链路。

销售介绍时建议先从商户的办赛压力切入：

很多机构不是不会办赛，而是每办一场都要重新拉群、收表、对账、催缴、排签、排场地、发通知、统计成绩。人少时还能靠表格和群消息撑住，一旦有多个赛项、收费报名、候补、双打组合或团队赛，人工流程就很容易出错。赛事系统的价值，是把这些容易出错、容易争议、容易重复劳动的环节变成标准流程，让机构能更稳定地办赛、复办赛事，并把参赛体验做得更专业。

从商户视角看，系统解决的是四类核心问题：

• 招募和报名更清楚：参赛者在移动端看到赛事、赛项、名额、费用和规则，自助报名；商户后台统一查看报名进度，不再依赖群接龙和人工表格。
• 收费和名额更可控：收费报名、待审核、待支付、候补、退款、确认名单都有状态流转，减少“谁先报、谁已付、谁该补位、谁能退款”的口径争议。
• 排签和执行更有秩序：报名截止后确认名单，再进入签表和赛程，减少名单未定就排签、排完又改人的混乱。
• 赛后价值能沉淀：成绩、排行、历史报名、选手/组合/团队资料沉淀下来，方便后续做积分赛、会员运营、赛事复盘和下一场赛事招募。

适合重点销售的业务场景：

• 俱乐部会员赛：适合网球馆、羽毛球馆、运动俱乐部做月赛、积分赛、挑战赛、邀请赛。销售话术可强调“会员不用反复填资料，机构可以持续沉淀选手成绩和排行”。
• 青少年培训机构赛事：适合校区联赛、训练营结营赛、学员测评赛。销售话术可强调“按年龄、性别、组别组织报名，家长在移动端查看报名、赛程和成绩，减少老师反复通知”。
• 公开报名赛事：适合面向外部选手开放的公开赛、城市赛、品牌活动赛。销售话术可强调“支持审核、收费、候补、退款和名单确认，能承接更复杂的公开报名流程”。
• 双打、混双和团队赛事：适合需要组合、搭档、队伍参赛的赛事。销售话术可强调“不是临时填两个人名字，而是用正式选手、双打组合和团队作为报名主体，后续签表、赛程、成绩都能继承使用”。
• 多角色协作办赛：适合有运营、裁判长、裁判、管理员分工的赛事。销售话术可强调“运营管报名，裁判长管签表赛程，裁判管录分，后台权限和流程更清晰”。

向客户表达时，可以用以下定位：

• 对老板或负责人：这是一套帮助机构把赛事做成长期运营能力的系统，不只是办完一场活动，而是把会员活跃、赛事收入、成绩沉淀和品牌专业度串起来。
• 对赛事运营人员：它把报名、审核、收费、候补、退款、确认名单这些琐碎工作放进统一后台，减少反复对表和群内确认。
• 对裁判长和执行人员：它把名单、签表、赛程、录分连起来，避免临场找不到人、重复排场、成绩回填不一致。
• 对参赛者和家长：移动端可以自助报名、查看签表赛程和成绩，参赛信息更透明，体验更像正式赛事。

一句销售口径：

赛事系统的核心不是“做一个报名入口”，而是帮机构把办赛流程标准化。前台让会员报名和查赛程成绩，后台让工作人员管报名、名单、签表、赛程和成绩。对于经常办会员赛、青少年赛、公开赛的商户，它能明显减少人工沟通和表格错误，也能让赛事看起来更专业、更容易复办。

1.1 当前支持赛事与未来扩展口径

客服和销售需要明确区分“当前已支持”和“未来可扩展”，不能把规划方向说成已上线能力。

当前已支持的运动类型

当前赛事后台已明确支持两类运动赛事：

• 网球赛事。
• 羽毛球赛事。

当前网球和羽毛球都支持完整赛事流程：赛事创建、赛项配置、报名、审核、候补、支付退款、名单确认、签表、赛程、录分、成绩、排行。

当前已支持的赛项类型

当前赛项类型支持：

• 单打。
• 双打。
• 混双。
• 团体。

其中系统内置赛项模板主要覆盖网球和羽毛球的单打、双打、混双常用组别；团体赛的实体管理、报名主体、团队成员维护等能力已具备，但具体团体赛模板、赛制和计分规则需要按客户赛事规则确认配置。

当前内置赛项模板

网球内置模板示例：

• 男单、女单：U8、U10、U12、U14、U16、U18、公开组、娱乐组。
• 男双、女双：U12、U14、U16、公开组、娱乐组。
• 混双：U12、U14、公开组、娱乐组。

羽毛球内置模板示例：

• 男单、女单：U9、U11、U13、U15、U17、U19、公开组、娱乐组。
• 男双、女双：U13、U15、U17、公开组、娱乐组。
• 混双：U13、U15、公开组、娱乐组。

当前内置计分规则

网球内置计分规则包括：

• 2 盘 1 胜抢七。
• 2 盘 1 胜超级抢十。
• 3 盘 2 胜抢七。
• 长盘制。
• 短盘制。

羽毛球内置计分规则包括：

• 3 局 2 胜 21 分。
• 3 局 2 胜 15 分。
• 1 局 21 分。
• 限时 10 分钟。
• 3 局 2 胜 11 分。

未来扩展方向

未来可扩展的赛事类型应按“规则相近度”和“实施复杂度”分层说明：

• 优先扩展方向：乒乓球、匹克球、壁球等与网球/羽毛球类似的对阵淘汰类项目。这类项目通常可复用报名、签表、赛程、成绩主流程，但需要新增对应运动类型、赛项模板和计分规则。
• 团队对抗类方向：篮球、足球、排球等。这类项目可复用赛事、报名、团队、赛程和成绩框架，但通常需要补充小组赛、循环赛、积分榜、净胜分等更复杂赛制规则。
• 计时计量类方向：跑步、游泳、田径等。这类项目可复用报名、分组、成绩发布框架，但成绩口径不是对阵晋级，需要单独设计计时、排名、组别成绩、检录和成绩导入规则。
• 专项行业赛事方向：马术、拳击、击剑、射击、搏击、舞蹈、棋类、电竞等。这类项目往往有行业专属规则，需要单独评估报名主体、赛制、评分、裁判、成绩和安全管控。其中拳击、击剑、射击通常还需要重点确认分级规则、裁判判罚/评分口径、靶道或剑道等场地资源、成绩采集方式和安全合规要求。

对外表达建议：

• 可以说：“当前赛事系统已支持网球和羽毛球赛事，支持单打、双打、混双和团体赛项，并内置常用组别模板和计分规则。”
• 可以说：“系统架构上具备扩展更多运动项目的能力，新增项目通常需要补充运动类型、赛项模板、计分规则和成绩口径。”
• 不要说：“乒乓球、篮球、足球、游泳等已经全部上线可直接使用。”
• 不要说：“所有运动只要改个名称就能用。”不同运动的计分、排名、晋级和成绩规则可能完全不同。

2. 端侧分工

2.1 后台管理端

后台管理端访问地址为 https://sport.pospal.cn/ ，主要给赛事组织方使用，核心模块包括：

• 赛事管理：创建赛事、编辑赛事、维护赛项、报名规则、报名协议、赛事图片、场馆信息。
• 报名管理：后台代报名、审核报名、管理正式名单、候补、支付、退款、种子、确认名单。
• 签表管理：按赛项生成签表，处理种子、轮空、回避冲突、版本调整、发布签表。
• 赛程管理：生成赛程，安排时间、场地、裁判，检测冲突，发布赛程。
• 成绩管理：录入比分，处理正常完赛、弃权、退赛，修正成绩，查看成绩详情。
• 动态梯序表：按赛事或赛项查看排行、积分、胜负统计。
• 系统设置：员工管理、角色权限、场馆与场地、机构配置、支付配置、打印模板、审计日志等。

2.2 移动参赛端

移动参赛端主要给会员和参赛者使用，底部入口包括：

• 报名：浏览赛事、进入赛事详情、选择赛项报名。
• 签表：查看已发布签表、对阵树、轮空、晋级路径。
• 赛程：查看已发布赛程、比赛时间和场地。
• 成绩：查看个人成绩、报名实体成绩详情。
• 我的：查看我的报名、我的选手、双打组合、团队、邀请码、共享管理、代报名授权。

移动端不是单纯展示端，它承担了参赛者自助报名和实体维护能力：

• 会员可新增选手，也可通过公开编号和分享码添加已有选手。
• 会员可创建双打组合、团队，并用于双打、混双、团队赛报名。
• 会员可生成邀请码让他人加入组合或团队。
• 会员可生成管理分享码，把选手、组合、团队的长期管理权限分享给别人。
• 会员可对某赛事下某实体发起代报名授权，让别人代为报名，但不授予长期管理权。

2.3 C 端能力完整说明

赛事 C 端是参赛者使用的移动端，不只是查看页面，也包含会员账号、报名、支付、退款申请、参赛实体管理和赛事信息查看。

账号与登录能力：

• 会员使用手机号和密码登录。
• 支持“注册 / 激活会员账号”，用户输入手机号、验证码、密码、确认密码后提交注册；验证码通过“获取验证码”发送。
• 注册成功后会提示账号已设置，并引导返回登录页。
• 支持忘记密码/重置密码，用户输入手机号、验证码、新密码和确认密码后提交重置。
• 登录、注册、重置密码时都会校验手机号格式，密码至少 6 位，两次输入密码必须一致。
• C 端入口带机构上下文，同一个会员登录态按当前机构保存；切换到其他机构入口时，不能默认沿用原机构登录态。
• 登录或支付过程中，如果需要微信支付授权，系统会跳转授权并在返回后提示授权结果。

赛事浏览与报名入口：

• C 端“报名”页展示可报名赛事，支持搜索赛事名称或主办方。
• 赛事详情展示赛事基础信息、赛事介绍、报名状态、赛项列表和公告入口。
• 赛项列表展示报名进度、名额和赛项信息，用户点击“去报名”进入赛项报名页。
• 未登录用户可以浏览赛事、赛事详情、已发布签表和已发布赛程；但报名、我的报名、我的选手、组合、团队、授权、支付、退款和我的成绩需要登录。
• 如果用户通过代报名授权进入赛事详情，页面会提示当前处于代报名模式，并展示授权主体和授权人信息。

赛项报名能力：

• 进入赛项报名页后，系统会根据赛项类型要求用户选择对应报名实体。
• 赛项报名页展示年龄限制、签表人数、报名上限、报名费、报名进度、待审核数和候补数，方便会员判断是否还能报名。
• 单打赛项选择选手；双打或混双赛项选择已成型双打组合；团队赛项选择团队。
• 双打组合只有成员完整、状态就绪后才能用于双打/混双报名；成员未完整时需要先通过邀请码补全组合。
• 报名页会带出当前会员信息或主选手信息作为联系人参考，用户仍需确认联系人姓名；联系电话使用当前会员手机号，不在报名页随意改写。
• 学校/单位只在赛项要求采集时显示，通常作为报名补充信息填写。
• 如果当前会员没有可用选手、组合或团队，页面会引导去新增选手、新建组合或新建团队。
• 代报名模式下，系统会校验授权主体类型是否与当前赛项要求一致；不一致时不能用于该赛项报名。

报名详情、支付与退款：

• “我的报名”展示会员自己的报名记录，包含赛事、赛项、报名时间、状态和候补序号等信息。
• 报名详情展示报名状态、报名实体、联系人、参赛成员、支付信息和退款信息。
• 报名详情会保留参赛成员快照，后续选手、组合或团队资料变化，不应随意改写历史报名事实。
• 待支付报名展示支付卡片，可发起支付、继续支付、重新发起支付或前往微信支付授权。
• 支付信息包含支付单状态、已支付金额、待支付金额、支付记录和授权状态。
• 当前报名待审核时，C 端会提示审核通过后才进入支付环节。
• 未支付报名可以取消，取消后关闭未完成支付并释放名额。
• 已支付报名不能直接取消，应展示申请退款入口。
• 移动端会员申请退款时必须填写退款原因，提交后等待后台审核，不直接执行退款。
• 退款状态会展示待审核、退款处理中、已退款、失败、已驳回、已取消等进度。

“我的”中心能力：

• 展示会员昵称/手机号和会员 ID，会员 ID 可复制，用于别人创建代报名授权时指定被授权人。
• 支持退出登录。
• “我的报名”用于查看报名记录和进入报名详情。
• “我的选手”用于新增选手、添加已有选手、编辑选手、设置主选手。
• “更多”中提供我的双打组合、我的团队、实体邀请码、共享管理、代报名授权等入口。

选手管理能力：

• 新增选手支持姓名、性别、生日、手机号、证件类型、证件号、是否主选手。
• 新增时系统会做疑似重复检查，提示“可能已存在”，用户可继续新建或改为添加已有选手。
• 添加已有选手需要先输入公开编号定位，再输入现有管理人提供的分享码完成添加。
• 公开编号只负责定位，不授予管理权。
• 分享码用于把已有选手添加到当前会员管理列表，分享码会过期，成功使用一次后会失效。
• 编辑选手时可更新资料、生成分享码、设置主选手。
• 删除相关操作分两种：如果还有其他管理人，是“从我的选手中移除”；如果没有其他管理人，是“归档选手”。归档后不再用于新报名，历史记录保留。
• 如果移除或归档的是主选手，且当前会员仍管理其他选手，需要先指定新的主选手。

双打组合能力：

• “我的双打组合”展示组合列表、成员、角色、状态和更新时间。
• 可新建双打组合；当前支持先用 1 位选手发起组合，再通过邀请码邀请另一位成员加入。
• 双打组合最多 2 位成员，满 2 人后组合成员锁定。
• 成员完整的组合可用于双打/混双报名；成员未完整的组合不能用于报名。
• 组合详情展示公开编号、成员状态、共享管理入口、生成加入邀请码入口和代报名授权入口。
• 公开编号只负责定位组合；长期管理权需要通过共享管理生成管理分享码。
• 如果组合还有其他管理人，用户可移除自己的管理权限；如果没有其他管理人，则归档组合，历史报名快照不受影响。

团队能力：

• “我的团队”展示团队列表、成员和状态。
• 可新建团队，选择当前可管理选手作为团队成员。
• 团队详情支持修改团队名称、维护团队成员。
• 加入团队和成为团队管理人是两件事：邀请码用于加入团队，管理分享码用于共享长期管理权限。
• 团队可生成公开编号、管理分享码、加入邀请码，也可进入代报名授权。
• 如果团队还有其他管理人，用户可移除自己的管理权限；如果没有其他管理人，则归档团队，归档后不再用于新报名，历史赛事快照保留。

实体邀请码能力：

• 适用于双打组合和团队。
• 管理人可生成加入邀请码，邀请码有效期为 1 小时。
• 管理人可复制或撤销邀请码。
• 被邀请人输入邀请码后，需要从自己长期管理的选手中选择一位加入对应组合或团队。
• 加入组合或团队不等于获得该组合或团队的长期管理权。

共享管理能力：

• 适用于双打组合和团队，也适用于选手分享场景中的管理授权逻辑。
• 公开编号用于定位实体，管理分享码用于授予长期管理权限。
• 管理人可生成 1 小时有效的管理分享码，并复制或撤销。
• 接收方需要先输入公开编号解析实体，再输入管理分享码领取管理权限。
• 如果接收方已经是该实体管理人，则无需重复领取。
• 共享管理不会自动改变团队成员关系或组合成员关系。

代报名授权能力：

• 页面分为“我收到的”“我发出的”“新建授权”。
• 收到授权后，被授权人可以在指定赛事下代为完成报名，但报名仍记在授权人名下。
• 发出的授权可查看被授权会员、授权实体和状态，并可撤销。
• 新建授权时需要选择赛事、授权主体类型和授权主体，并填写被授权会员 ID。
• 授权主体可为选手、双打组合或团队。
• 代报名授权只放行本次赛事报名动作，不授予长期管理权。

组队与协作参赛能力总览：

• C 端支持三类参赛实体：选手、双打组合、团队。
• 双打组合用于双打/混双赛项报名；团队用于团队赛项报名。
• 会员可以在“我的双打组合”中新建组合，先选择 1 位自己管理的选手发起组合，再通过加入邀请码邀请另一位成员加入。
• 双打组合最多 2 位成员，成员满 2 人后组合成型并锁定，才能用于双打/混双报名。
• 会员可以在“我的团队”中新建团队，选择自己管理的选手作为团队成员，后续可维护团队名称和成员。
• 双打组合和团队都支持“通过邀请码加入”：别人发来邀请码后，当前会员从自己管理的选手中选择一位加入对应组合或团队。
• 邀请码只解决“成员加入”问题，不等于获得组合或团队的管理权。
• 双打组合和团队都支持“共享管理”：管理人通过公开编号和管理分享码，把长期管理权限分享给其他会员。
• 管理分享码只解决“管理权共享”问题，不会自动改变组合成员或团队成员。
• 双打组合和团队都可以进入“代报名授权”：授权别人为指定赛事下的组合或团队代为报名。
• 代报名授权只解决“帮忙报名”问题，不会授予长期管理权。
• 如果组合或团队仍有其他管理人，当前会员可以移除自己的管理权限；如果没有其他管理人，则归档组合或团队，历史报名快照保留。

组队相关概念区分：

• 加入邀请码：让某个选手加入双打组合或团队。
• 公开编号：用于定位选手、双打组合或团队，本身不授权。
• 分享码：用于把已有选手添加到自己的管理列表。
• 管理分享码：用于领取双打组合或团队的长期管理权限。
• 代报名授权：用于在某个赛事下帮别人完成报名。

签表查看能力：

• C 端签表页只展示已发布签表；未发布签表不展示详情。
• 签表按赛事分组展示，并统计已发布签表的赛项数量。
• 登录用户的已报名赛项会置顶或标记为“我的”。
• 签表详情展示完整对阵树、轮次、轮空、待赛、已完赛、比分、胜者和晋级路径。
• 用户可查看自己的参赛主体在签表中的位置和晋级路径。

赛程查看能力：

• C 端赛程页只展示已发布赛程；未发布赛程不可进入详情。
• 赛程按赛事分组展示，并统计已发布赛程的赛项数量。
• 登录用户的已报名赛项会置顶或标记为“我的”。
• 赛程详情支持按时间线查看，也支持按场地查看。
• 比赛卡片展示轮次、场次、对阵、状态、比赛时间和场地。
• 未安排时间或场地的比赛会显示为时间待定或场地待定。

成绩查看能力：

• “成绩”页展示我的成绩，需要登录后查看。
• 成绩列表展示赛事、赛项、更新时间和是否已发布。
• 成绩详情展示报名实体的对局结果、轮次、场次、比分、场地、状态等。
• 成绩未发布时，C 端应明确提示“成绩未发布”。
• 验证码查成绩页面目前属于能力占位，若提示暂未开启，不能承诺该能力已正式开放。

赛事公告能力：

• 如商户开启公告能力，C 端可进入“赛事公告”页面。
• 公告页支持选择赛事，查看该赛事下公告列表。
• 公告详情展示标题、发布时间、摘要和正文内容。
• 如果公告能力未开启，应按商户配置解释，不要承诺所有赛事都一定有公告入口。

C 端能力边界：

• C 端会员不能直接审核报名、确认收款、执行退款、生成签表、发布赛程或录入成绩，这些属于后台管理端能力。
• C 端会员不能仅凭公开编号管理他人选手、组合或团队；必须有分享码、管理分享码或有效代报名授权。
• C 端会员不能直接修改已发布签表、赛程或成绩。
• C 端只展示已发布签表和已发布赛程，未发布内容不面向参赛者开放。

2.4 按业务场景介绍 C 端完整链路

介绍 C 端时，不建议只说“有报名、签表、赛程、成绩、我的”。更好的口径是按参赛者真实使用场景讲完整链路。

场景一：新会员第一次参加赛事

1. 会员先通过“注册 / 激活会员账号”设置账号：输入手机号，获取并填写验证码，设置密码并确认密码。
2. 注册成功后返回登录页，用手机号和密码登录。
3. 如果忘记密码，可通过手机号、验证码、新密码和确认密码重置。
4. 登录后进入“报名”页，浏览当前可报名赛事。
5. 在赛事详情中查看赛事时间、地点、介绍、报名状态、公告和可报名赛项。
6. 进入赛项详情，查看赛项类型、性别/年龄要求、报名费、名额进度和报名规则。
7. 如果是单打赛项，会员需要先新增或选择自己的选手档案；如果是双打/混双，需要先选择已成型组合；如果是团队赛，需要选择团队。
8. 填写或确认联系人信息，提交报名。
9. 免费或无需审核的报名可直接进入正式；需要审核的报名进入待审核；收费报名进入待支付。
10. 待支付报名在报名详情中完成支付或微信支付授权。
11. 报名成功后，会员可在“我的报名”持续查看报名状态、候补序号、支付状态和退款状态。

这个场景要强调：C 端不是只让用户填一张报名表，而是把账号、选手档案、报名、支付和报名状态跟踪串成闭环。

场景一延伸：C 端注册与报名赛事标准操作链路

客服讲“C 端怎么报名赛事”时，可以按以下标准路径说明。

第一步：注册或登录账号

• 新用户点击“新用户注册”，进入“注册 / 激活会员账号”。
• 输入手机号，点击“获取验证码”。
• 输入验证码，设置密码，再次输入确认密码。
• 提交注册后，系统提示账号已设置，用户返回登录页。
• 老用户直接使用手机号和密码登录。
• 忘记密码时，进入“忘记密码”，输入手机号、验证码、新密码和确认密码后重置。

第二步：进入赛事报名入口

• 登录后进入底部“报名”页。
• 页面展示当前机构下可浏览的赛事列表。
• 用户可通过搜索框按赛事名称或主办方搜索。
• 赛事卡片展示赛事名称、日期、主办方和报名中标识。
• 点击赛事卡片进入赛事详情。

第三步：查看赛事详情并选择赛项

• 赛事详情展示赛事封面、赛事名称、赛期、主办方、协办方、赛事介绍。
• 如果开启公告能力，用户可进入“赛事公告”查看公告列表和公告详情。
• 赛项列表展示该赛事下可报名赛项。
• 每个赛项展示赛项名称、赛项类型、性别要求、报名进度、报名费用等信息。
• 用户点击“去报名”进入赛项报名页。

第四步：准备报名实体

• 单打赛项需要选择选手。
• 双打或混双赛项需要选择已成型双打组合。
• 团队赛项需要选择团队。
• 如果没有可用选手，系统引导去新增选手。
• 如果没有可用双打组合，系统引导去新建组合；组合成员未完整时不能报名，需要先通过邀请码补全。
• 如果没有可用团队，系统引导去新建团队并维护成员。

第五步：提交报名

• 用户在赛项报名页选择报名实体。
• 系统带出当前会员信息作为联系人参考，用户确认联系人姓名和手机号。
• 用户提交报名。
• 如果报名失败，系统会提示原因，例如名额已满、候补已满、报名实体不符合赛项要求、授权主体不匹配等。

第六步：报名提交后的状态

• 如果赛项免费且无需审核，报名可直接进入正式。
• 如果需要审核，报名进入待审核，等待后台处理。
• 如果是收费赛项，报名进入待支付，用户需要到报名详情完成支付。
• 如果名额已满但开启候补，报名进入候补，并展示候补序号。
• 如果用户通过代报名授权提交报名，报名仍归授权人主体；若当前代报名人不能支付，系统会提示已为授权发起人提交报名，并由授权人查看、支付或取消。

第七步：支付和后续查看

• 待支付报名会在报名详情展示支付卡片。
• 用户可立即支付、继续支付或重新发起支付。
• 如需微信支付授权，系统会跳转授权并在返回后提示授权结果。
• 支付完成后，报名状态更新。
• 用户后续可在“我的报名”查看报名状态、支付状态、候补状态、退款状态。

第八步：取消或退款

• 未支付报名可以直接取消，取消后关闭未完成支付并释放名额。
• 已支付报名不能直接取消，只能申请退款。
• 会员提交退款申请后，由后台审核和执行退款。
• 退款完成前不释放名额；退款被驳回时，报名回到正式状态。

场景二：家长或会员管理多个参赛选手

1. 会员在“我的选手”中维护自己管理的选手。
2. 可新增选手，填写姓名、性别、生日、手机号、证件信息，并设置主选手。
3. 系统会做疑似重复检查，避免同一个选手被重复建档。
4. 如果选手已经由别人创建，会员可通过公开编号先定位，再用对方提供的分享码添加到自己的管理列表。
5. 后续报名时，会员可在单打赛项中选择自己管理的选手参赛。
6. 如果某个选手不再由当前会员管理，可从我的选手中移除；如果没有其他管理人，则按归档处理，历史报名和成绩保留。

这个场景要强调：选手是可长期复用的参赛实体，不是每次报名临时填写的文本。

场景三：双打或混双报名

1. 会员先在“我的双打组合”中新建组合。
2. 当前可先用 1 位选手发起组合，再生成加入邀请码邀请另一位成员加入。
3. 对方输入邀请码后，从自己管理的选手中选择一位加入组合。
4. 组合满 2 人后状态变为就绪，成员锁定。
5. 报名双打或混双赛项时，会员选择已就绪的组合完成报名。
6. 如果组合还差成员，系统会提示需要补全，不能直接用于报名。
7. 如果需要让其他人长期管理该组合，需要走共享管理，使用公开编号加管理分享码。

这个场景要强调：邀请码用于“加入组合”，管理分享码用于“共享管理权”，二者不是一回事。

场景四：团队赛报名

1. 会员在“我的团队”中新建团队。
2. 选择自己管理的选手作为团队成员。
3. 后续可维护团队名称和成员。
4. 团队可生成加入邀请码，让其他会员用自己的选手加入团队。
5. 团队也可通过共享管理把长期管理权限分享给别人。
6. 报名团队赛项时，会员选择团队作为报名实体。
7. 团队报名成功后，团队快照会进入报名记录，后续团队成员变化不应随意改写历史报名事实。

这个场景要强调：团队既是报名实体，也是长期管理对象；加入团队和成为团队管理人是两类不同动作。

场景五：别人代我报名

1. 授权人在“代报名授权”中选择赛事和授权主体。
2. 授权主体可以是选手、双打组合或团队。
3. 授权人填写被授权会员 ID，创建授权。
4. 被授权人在“我收到的”授权中看到授权记录。
5. 被授权人可按授权进入赛事详情，以代报名模式为该实体完成报名。
6. 报名完成后，报名仍归授权人主体，不归被授权人。
7. 被授权人不会因此获得该选手、组合或团队的长期管理权。
8. 授权人可撤销授权，授权也会按有效期过期。

这个场景要强调：代报名授权只解决“这次赛事谁帮谁报名”，不解决长期管理权转移。

场景六：报名后查看参赛安排

1. 后台确认名单并发布签表后，C 端“签表”页展示已发布签表。
2. 登录会员自己的赛项会被标记或置顶为“我的”。
3. 用户可进入签表详情查看对阵树、轮次、轮空、晋级路径和比分。
4. 后台发布赛程后，C 端“赛程”页展示已发布赛程。
5. 用户可按时间线或场地查看比赛安排。
6. 比赛卡片展示对阵双方、比赛状态、时间、场地、轮次和场次。
7. 未发布的签表和赛程不会在 C 端开放给参赛者查看。

这个场景要强调：C 端展示的是后台已发布的正式信息，避免参赛者看到草稿排期或未确认签表。

场景七：比赛结束后查看成绩

1. 后台录入比赛成绩后，C 端成绩页展示会员相关成绩。
2. 用户可进入成绩详情，查看赛事、赛项、轮次、场次、对阵、比分、结局和场地。
3. 如果成绩尚未发布，C 端应明确提示成绩未发布。
4. 如果商户后续启用验证码查成绩，用户可通过验证码查询；当前应按系统提示说明是否开放，不能默认承诺已启用。

这个场景要强调：成绩查看依赖后台录分和发布状态，C 端不负责录分和成绩修正。

场景八：报名退出、取消与退款

1. 用户在“我的报名”进入报名详情。
2. 如果报名尚未支付，可直接取消报名。
3. 取消未支付报名后，系统关闭未完成支付并释放名额。
4. 如果报名已经支付，C 端不能直接取消，只能申请退款。
5. 会员提交退款申请后，进入后台审核流程。
6. 退款审核通过并真正退款完成后，才释放名额。
7. 如果退款被驳回，报名回到正式状态，不释放名额。

这个场景要强调：未支付取消和已支付退款是两条不同业务链路，不能混为一谈。

场景九：赛事公告触达参赛者

1. 如果商户开启赛事公告能力，会员可在赛事详情或公告入口查看公告。
2. 公告列表按赛事展示，用户可切换赛事查看对应公告。
3. 公告详情展示标题、发布时间、摘要和正文。
4. 如果商户未开启公告能力，客服应解释为当前赛事未开放公告入口，而不是系统故障。

这个场景要强调：公告是赛事运营触达能力，是否开放取决于商户配置。

场景十：C 端和后台协同关系

• C 端负责参赛者自助操作：登录、维护参赛实体、报名、支付、申请退款、查看签表赛程成绩。
• 后台负责赛事组织方操作：创建赛事、配置规则、审核报名、确认收款、处理退款、确认名单、生成签表、发布赛程、录入成绩。
• C 端看到的签表、赛程、成绩，来自后台发布或录入后的正式结果。
• 如果参赛者反馈看不到签表、赛程或成绩，客服应先判断后台是否已发布或成绩是否已开放，而不是直接判断 C 端异常。

2.5 C 端细节规则与客服排障口径

这一节用于补足 C 端容易被问到但容易答偏的细节。客服 AI 回答用户问题时，应先按业务场景判断规则边界，再判断是否可能是系统异常。

机构入口与登录边界：

• C 端赛事入口按机构区分，不同机构的赛事、报名、选手、组合、团队和登录态不能混为一谈。
• 用户从 A 机构入口登录后，进入 B 机构入口时可能需要重新登录；这不是账号丢失，而是机构上下文不同。
• 公开可浏览内容通常包括赛事列表、赛事详情、已发布签表、已发布赛程和部分公告内容。
• 需要会员登录后才能操作的内容包括报名、我的报名、报名详情、支付、取消报名、申请退款、我的成绩、我的选手、双打组合、团队、邀请码、共享管理和代报名授权。
• 未登录用户进入赛项报名页时，系统会提示先登录会员账号，登录后再回到原报名链路。

赛事与赛项展示规则：

• 赛事列表支持按赛事名称或主办方搜索，展示的是当前机构下可浏览的赛事。
• 赛事详情展示赛事基础信息、赛事介绍、赛期、主办方、协办方、报名状态、赛项列表；公告入口取决于商户是否开启公告能力。
• 赛项报名页会展示赛项类型、性别要求、年龄限制、签表人数、报名上限、报名费、报名进度、待审核数和候补数。
• 赛项名额是否可报，不只看报名上限，还要结合报名时间、报名阶段、审核、支付、候补上限和报名主体是否合规。

报名主体选择规则：

• 单打赛项只能选择选手报名。
• 双打和混双赛项只能选择已成型的双打组合报名。
• 团队赛项只能选择团队报名。
• 如果没有可用选手，系统会引导新增选手或添加已有选手。
• 如果有双打组合但成员未补全，不能用于报名；C 端会提示还有待补全组合，需要补齐 2 位成员后才可报名。
• 如果没有可用团队，系统会引导新建团队并维护成员。
• 代报名模式下，授权主体类型必须与赛项要求一致；例如授权的是选手，就不能用于双打组合赛项。

报名信息填写规则：

• 联系人姓名会优先带出当前会员显示名或主选手姓名，但用户仍需确认。
• 联系电话使用当前会员手机号，报名页不作为手机号修改入口；如果手机号缺失，应提示用户重新登录或联系工作人员处理账号信息。
• 学校/单位只在赛项要求采集时出现，属于报名补充信息。
• 提交报名失败时，常见原因包括报名未开始或已截止、名额已满、候补已满、年龄或性别不符、重复报名、报名主体不符合赛项要求、授权不匹配、协议未确认等。

报名提交后的状态规则：

• 待审核表示报名已提交，但需要后台审核；审核通过后才进入支付或正式名单流程。
• 待支付表示报名已通过审核或自动通过，但还未完成支付或确认收款。
• 正式表示已进入正式报名名单。
• 候补表示正式名额已满，但允许按候补顺位等待补位。
• 已拒绝、已取消、已退款、未入选都属于历史状态，不再参与当前正式名单。
• 候补报名在详情或列表中应展示候补序号，客服解释时要避免把候补说成报名成功入围。
• 代报名提交后，报名归授权发起人主体；如果代报名人不能支付，应由授权发起人查看、支付或取消。

支付规则：

• 待支付报名会在报名详情展示支付卡片，用户可发起支付、继续支付或刷新支付状态。
• 支付状态包括待支付、支付中、已支付、已过期、已取消。
• 微信支付授权可能出现授权成功、授权过期、授权已被消费、授权状态无效、授权未完成等提示；客服应按页面提示引导重新授权或重试。
• 如果支付渠道未返回跳转地址、返回脚本为空、支付信息加载失败或支付单异常，应建议用户稍后重试；持续异常时联系工作人员检查支付配置和报名支付单。
• 待审核报名不会立即展示支付动作，应先由后台审核通过。

取消与退款规则：

• 未支付报名可以取消，取消后关闭未完成支付并释放名额。
• 已支付报名不能直接取消，必须走退款申请或后台退款流程。
• C 端会员申请退款必须填写退款原因。
• C 端只能提交退款申请，不能直接执行退款；退款是否通过、退款比例、退款方式由后台规则和工作人员处理。
• 退款进度可能是待审核、退款处理中、已退款、退款失败、已驳回、已取消。
• 退款被驳回时会展示驳回原因，报名通常回到正式状态。
• 退款完成前不释放名额；只有退款完成后才释放名额，并按候补规则处理补位。

选手与共享规则：

• 新增选手时会做疑似重复检查，提示用户继续新建或改为添加已有选手。
• 添加已有选手需要两步：先用公开编号定位选手，再用现有管理人提供的分享码领取管理关系。
• 公开编号不是授权码，只能定位选手、组合或团队。
• 选手分享码会过期，且成功使用一次后会失效。
• 如果用户已经管理该选手，不需要重复添加。
• 移除选手管理关系和归档选手不是同一件事：还有其他管理人时是移除自己的管理权限；没有其他管理人时才是归档，历史报名和成绩仍保留。
• 如果移除或归档的是主选手，且当前会员还管理其他选手，需要先指定新的主选手。

组队与协作规则：

• 双打组合最多 2 位成员，满 2 人后组合成型并锁定；如需更换搭档，通常应新建组合。
• 加入邀请码只用于让某位选手加入双打组合或团队，不授予长期管理权。
• 被邀请人使用邀请码时，需要从自己长期管理的选手中选择一位加入。
• 团队成员和团队管理人是两个概念：加入团队不等于拥有团队管理权。
• 管理分享码用于授予长期管理权限，不会自动改变组合成员或团队成员。
• 邀请码和管理分享码通常 1 小时有效，管理人可复制或撤销。
• 代报名授权只允许被授权人在指定赛事下帮忙报名，不授予选手、组合或团队的长期管理权。
• 代报名授权有“我收到的”“我发出的”“新建授权”等视角；授权可撤销，也会按有效期过期。

签表、赛程、成绩与公告规则：

• C 端签表页只展示后台已发布签表；未发布签表不会开放详情。
• C 端赛程页只展示后台已发布赛程；未发布赛程不会开放详情。
• 登录会员自己的赛项会在签表或赛程中置顶或标记为“我的”，方便快速查看。
• 赛程可按时间线或场地查看；未安排时间或场地时，会显示时间待定或场地待定。
• 报名详情可直接进入“查看该报名成绩”。
• 我的成绩需要登录查看；成绩未发布时，应解释为后台尚未发布或当前未开放，不要说成数据丢失。
• 验证码查成绩如果页面提示暂未开启，应按未开启解释，不能承诺所有赛事都支持验证码查询成绩。
• 赛事公告取决于商户能力开关；未开启公告入口时，不应判断为 C 端故障。

3. 售前视角：如何向客户介绍

3.1 推荐介绍口径

可以这样介绍：

这套赛事系统覆盖赛事运营全流程。后台可以创建赛事、设置赛项和报名规则、审核报名、处理候补与退款、生成签表、安排赛程、录入成绩和查看排行；移动端给会员使用，会员可以自助报名、管理选手和团队、查看签表赛程成绩。它适合需要规范报名、减少人工排表、提升赛事执行效率的体育机构和俱乐部。

强调点：

• 不是“报名表单工具”，而是赛事运营系统。
• 不只是后台管理，也有参赛者移动端。
• 不只是单打赛事，也支持双打、混双、团队等实体报名。
• 不只是报名和收费，还覆盖候补、退款、名单确认、签表、赛程、录分、排行。

3.2 客户痛点与对应能力

客户常见痛点：

• 报名信息分散在表格、群消息、收款记录里，容易漏人、错人。
• 多赛项报名时，选手、组合、团队管理混乱。
• 名额满了以后候补和补位靠人工记，容易争议。
• 收费报名、退款比例、退款截止、退款审核没有统一口径。
• 签表靠人工抽签和排版，种子、轮空、回避规则容易出错。
• 赛程排场地、裁判、时间冲突难检查。
• 比赛成绩和晋级需要重复维护，结果公布慢。
• 完赛后没有统一积分、排行和历史沉淀。

系统对应能力：

• 报名统一进入系统，状态清晰可追踪。
• 选手、组合、团队作为正式实体管理，报名时直接选择实体。
• 名额、候补、支付、退款都有状态机规则。
• 报名截止后可确认名单，锁定正式名单后进入签表流程。
• 签表支持生成、调整、发布，发布后进入只读和晋级模式。
• 赛程支持生成、编辑时间/场地/裁判、冲突检测、发布。
• 成绩录入后可推动晋级和排行计算。
• 移动端同步展示报名、签表、赛程、成绩，减少人工通知。

3.3 售前演示建议流程

建议按真实赛事流程演示，不要按菜单逐个点：

1. 后台创建赛事：填写赛事基础信息、时间、场馆、主办方、封面、赛事介绍。
2. 配置赛项：添加单打、双打、混双或团队赛项，设置名额、签表规模、年龄/性别要求、计分规则。
3. 配置报名规则：设置报名时间、审核方式、报名费、支付方式、候补、退款规则、报名协议。
4. 移动端报名：会员浏览赛事，选择赛项，选择选手/组合/团队，提交报名并支付或等待审核。
5. 后台报名管理：审核、确认收款、处理候补、设置种子、确认名单。
6. 后台签表管理：生成签表，查看种子和轮空，处理回避冲突，发布签表。
7. 后台赛程管理：生成赛程，安排时间、场地、裁判，查看冲突并发布。
8. 移动端查看：参赛者查看签表、赛程、我的报名。
9. 后台成绩管理：录入比分、处理弃权/退赛、修正成绩。
10. 移动端成绩与后台排行：查看成绩详情和动态梯序表。

3.4 适合重点强调的差异化能力

• 报名不是临时文本，而是绑定统一会员主体和正式参赛实体。
• 单打、双打、团队的报名模型清晰，后续签表、赛程、成绩可以继承使用。
• 候补有自动递补和手动递补两种模式。
• 未支付取消和已支付退款是两条不同流程，退款完成前不释放名额。
• 后台直接退款和移动端会员申请退款区分清楚。
• 种子支持设置、锁定、补齐、重排，并和签表发布锁定联动。
• 签表发布后会生成对阵，BYE 自动晋级，录分后胜者自动进入下一轮。
• 赛程可以检测场地、时间、裁判冲突。
• 动态梯序表区分“单赛项正式排行”和“赛事总排行参考”。

4. 销售视角：功能、承诺与确认清单

4.1 可明确承诺的能力

销售可以明确说明系统支持：

• 多赛事管理：创建、编辑、发布、下架、按状态和时间筛选。
• 多赛项配置：支持不同赛项类型、名额、签表规模、报名规则、计分规则。
• 报名审核：支持自动审核和人工审核。
• 收费报名：支持报名费、待支付、已支付、线下确认收款等状态管理。
• 候补管理：支持名额满后进入候补，支持自动或手动递补。
• 退款管理：支持退款规则、退款申请、后台审核、后台直接退款。
• 后台代报名：运营人员可在后台为会员创建报名。
• 选手/组合/团队实体：支持单打选手、双打组合、团队赛团队。
• 代报名授权：会员可授权他人帮自己在指定赛事下为指定实体报名。
• 签表管理：支持生成签表、查看草稿、手动调整、发布、版本历史。
• 回避规则：可按同队、同校等信息做回避参考和冲突提示。
• 赛程管理：支持生成赛程、编辑比赛时间/场地/裁判、冲突检测、发布。
• 成绩管理：支持正常完赛、弃权、退赛、成绩修正、成绩详情。
• 移动端展示：参赛者可查看报名、签表、赛程、成绩。
• 系统设置：支持员工、角色权限、场馆、场地等基础配置。

4.2 销售必须提前确认的问题

成交前建议确认以下内容，避免实施时出现口径偏差：

• 客户办的是什么运动项目？目前系统已有网球、羽毛球等计分规则样例，其他运动是否需要新增规则。
• 客户是否只办单打，还是有双打、混双、团队赛。
• 客户是否需要收费报名，收款方式是线上、线下，还是两者都需要。
• 客户是否需要退款，退款截止、退款比例、是否需要审核。
• 客户报名是否需要审核，还是报名即通过。
• 客户是否需要候补，候补是自动递补还是人工确认。
• 客户是否有年龄、性别、每人最多报名项目数、禁止重复报名等限制。
• 客户是否需要设置种子，种子由谁维护，是否需要锁定。
• 客户是否需要按学校、俱乐部、队伍做签表回避。
• 客户是否需要场地和裁判排程，是否存在多场馆、多场地。
• 客户是否要求导出 PDF/Excel、打印签表、成绩表、对阵表等。
• 客户是否需要和现有会员、支付、通知、积分体系做额外打通。

4.3 谨慎承诺的内容

以下内容不要直接承诺，需确认版本和实施范围：

• 不要承诺所有运动项目的复杂计分规则都开箱即用。不同项目可能需要配置或定制。
• 不要承诺签表可以自动解决所有公平性问题。系统能生成、提示冲突和支持调整，但最终规则仍需赛事方确认。
• 不要承诺赛程自动排出来就一定是最终可执行。场馆容量、裁判人力、临时调整仍需人工确认。
• 不要承诺退款一定自动原路秒退。退款方式取决于原支付方式、支付渠道和当前配置。
• 不要承诺已发布签表可以随意修改。已发布后会进入保护状态，涉及名单、种子、赛果、排期的修改都有严格限制。
• 不要承诺移动端可以让任何人直接操作他人选手或团队。长期管理权和代报名授权是两类不同权限。
• 不要把“公开编号”说成“授权码”。公开编号只能定位实体，不能直接授予管理权。
• 不要把“代报名授权”说成“获得长期管理权”。代报名只允许完成指定赛事报名动作。

5. 售后视角：实施、培训与排障

5.1 上线实施建议步骤

1. 建立后台组织和员工：先确认主账号、运营人员、裁判长、裁判等角色。
2. 配置场馆和场地：维护场馆名称、地址、城市、联系人、场地编号、类型、状态。
3. 配置赛事基础信息：赛事名称、日期、场馆、主办方、介绍、图片。
4. 配置赛项和规则：赛项类型、名额、签表规模、年龄/性别、计分规则。
5. 配置报名规则：报名时间、审核方式、报名费、支付方式、候补、退款、协议。
6. 小范围试报名：用测试会员验证报名、支付、审核、候补、退款申请。
7. 培训后台运营：报名审核、候补递补、确认名单、种子设置。
8. 培训赛事执行人员：签表生成、赛程安排、冲突检测、录分和修正。
9. 开放正式报名：报名中重点关注待审核、待支付、候补队列。
10. 赛前确认名单：处理完待审核、待支付、候补后再确认名单。
11. 发布签表和赛程：发布前检查种子、轮空、冲突、场地和时间。
12. 赛中录分：按比赛结果录入正常完赛、弃权或退赛。
13. 赛后确认成绩与排行：检查成绩、导出或公布结果。

5.2 员工与权限培训重点

后台支持员工管理和角色权限：

• 员工可维护姓名、手机号、工号、状态、密码。
• 同一组织内员工工号和手机号需要唯一。
• 停用员工后，该员工不能继续登录。
• 主账号用于系统初始化和兜底管理，不允许停用或删除。
• 系统角色包括超级管理员、赛事总监、裁判长、裁判等。
• 超级管理员拥有全部权限。
• 赛事总监侧重赛事运营，不建议授予员工和角色管理权限。
• 裁判长侧重赛程和比赛执行。
• 裁判侧重查看赛事和录入比分。
• 系统角色为默认权限，不建议随意修改；自定义角色能力需按版本确认。

售后培训建议：

• 管理员负责员工、角色、系统设置。
• 运营负责赛事、报名、支付、退款、名单确认。
• 裁判长负责签表、赛程、冲突处理。
• 裁判负责现场录分。

5.3 场馆与场地培训重点

• 场馆信息包括名称、地址、城市、容量、联系人、设施、状态。
• 场地信息包括编号/名称、所属场馆、类型、地面、容量、直播设备、状态。
• 停用场馆后，该场馆下场地在业务上不可用。
• 场馆停用后不应继续维护其下场地。
• 维护中或不可用的场地不能用于赛程编排。
• 同一场馆下场地编号应避免重复。
• 停用或删除已被赛程占用的场馆/场地时，应先确认是否存在在途赛程。

5.4 报名管理排障口径

后台报名管理核心原则：

• 报名管理不是简单列表操作，而是“报名中 → 报名截止 → 名单已确定”的阶段流程。
• “确认名单”是报名阶段进入签表阶段的关键关卡；确认名单后，正式参赛名单锁定，未入选候补归档，后续进入签表管理。
• 后台报名管理入口支持按赛事、赛项、状态、来源、退款状态、关键词、时间等维度筛选；建议客服排障时先确认当前选择的是哪个赛事和哪个赛项。
• 后台概览会展示正式进度、签表规模、正式名额、BYE、待审核、待支付、候补、候补模式、报名费和退款截止等信息，这些信息会直接影响能否确认名单和生成签表。

后台报名阶段规则：

• 报名中：可以新建报名、审核报名、处理支付、处理候补递补、取消未支付报名、处理退款。
• 报名截止：不再允许新增报名，但仍可继续审核、支付、候补递补、取消未支付报名、处理退款；处理完遗留事项后才能确认名单。
• 名单已确定：不再允许新增报名、审核通过、候补递补、取消报名、确认收款或退款；可以在签表生成前维护正式报名的种子信息。
• 阶段只能向前推进，不能从名单已确定退回报名截止，也不能从报名截止退回报名中。
• 下架赛事只影响对外展示和新增报名，不等于自动完成报名截止或确认名单。
• 某赛项签表一旦发布，该赛项会禁止修改种子和任何影响签表公平性的报名变更。

后台新建报名规则：

• 后台新建报名只能在报名中阶段进行。
• 赛事必须处于已发布状态，已下架赛事不能新增报名。
• 赛项报名名额不能大于签表规模，否则无法正常报名和生成签表。
• 报名主体必须匹配赛项类型：单打用选手，双打/混双用双打组合，团队赛用团队。
• 双打组合必须补齐 2 位成员后才能报名。
• 后台新建报名也会校验性别、年龄、重复报名、同一选手最多参与双打队伍数等动态规则。
• 收费赛项后台新增报名可选择未支付或已支付；如果名额已满进入候补，不能直接用“已支付”方式新增候补报名。

后台审核规则：

• 只有待审核报名可以审核通过或拒绝。
• 审核通过后，如果有正式名额，免费赛项进入正式，收费赛项进入待支付。
• 如果正式名额已满且开启候补，审核通过后可进入候补。
• 如果名额已满且未开启候补，或候补也已满，审核通过会被阻止。
• 名单已确定后不能再审核通过。
• 赛项签表发布后，不能再审核会影响该赛项名单的报名。

后台确认收款规则：

• 确认收款主要用于待支付报名。
• 当前报名必须存在支付信息，且支付单处于未支付状态。
• 如果已有线上支付流程处理中，应等待线上支付完成或重启支付后再处理，不能直接现金确认。
• 确认收款后，报名从待支付进入正式。
• 名单已确定后不能再确认收款。

后台候补递补规则：

• 候补递补只适用于开启候补的赛事。
• 自动递补模式下，名额释放后系统按候补顺位处理，后台无需手动递补。
• 手动递补模式下，必须有空余正式名额，才能把候补转正。
• 免费赛项候补转正后进入正式；收费赛项候补转正后进入待支付。
• 候补取消或递补后，剩余候补序号会重排。
• 名单已确定后不能再递补候补。

确认名单前必须满足的条件：

• 必须先选择具体赛事。
• 当前赛事必须处于报名截止阶段；报名中阶段不能确认名单。
• 赛事至少要有正式报名；如果没有任何成功报名，不可确认名单。
• 不能存在待审核报名；待审核必须先审核通过或拒绝。
• 不能存在待支付报名；待支付必须先完成支付、后台确认收款、支付超时处理或取消。
• 手动递补模式下，如果某赛项还有空位且还有候补，必须先完成手动递补，不能跳过候补直接确认名单。
• 若存在候补但没有空位，确认名单时未能递补的候补会归档为未入选。
• 种子号不连续、BYE 比例过高、种子数量过多等属于签表前风险提示，通常不是确认名单的硬性阻断；但建议在生成签表前修正。

确认名单后的影响：

• 赛事阶段变为名单已确定。
• 正式参赛名单锁定，不可再新增报名、候补递补或直接取消报名。
• 未能递补的候补报名归档为未入选。
• 确认名单后可前往签表管理生成签表。
• 签表生成前仍可维护正式报名的种子信息；签表发布后，种子和影响签表的名单变更会被锁定。
• 如果确认名单前遗漏待审核、待支付或候补补位问题，后续会影响签表生成和赛事公平性，因此应在确认前处理干净。

报名无法创建，常见原因：

• 赛事不在报名中。
• 赛事已下架，不能新增报名。
• 当前赛事已报名截止或名单已确定。
• 赛项名额已满且未开启候补。
• 候补已满。
• 赛项报名名额大于签表规模。
• 年龄或性别不符合赛项规则。
• 同一赛项不允许重复报名。
• 同一选手超过该赛项允许参与的双打队伍数量。
• 双打组合成员不完整。
• 团队成员不符合赛项要求。
• 当前会员没有该选手、组合或团队的长期管理权，也没有有效代报名授权。
• 需要确认报名协议但未勾选。

报名无法取消，常见原因：

• 报名已支付，需要走退款流程，不能直接取消。
• 名单已确定。
• 签表已发布，禁止影响正式名单。
• 该报名设置了锁定种子，需要先解除锁定。

候补无法转正，常见原因：

• 当前没有空余正式名额。
• 当前赛事为自动递补模式，无需手动转正。
• 名单已确定或签表已发布。
• 收费赛项转正后需进入待支付或确认收款。

确认名单失败，常见原因：

• 赛事仍处于报名中，尚未报名截止。
• 没有任何正式报名，无法确认空名单。
• 还有待审核报名。
• 还有待支付报名。
• 手动递补模式下存在空位且有候补未处理。
• 直接绕过页面操作时，系统仍会按上述规则阻止确认名单。

5.5 签表管理排障口径

签表无法生成，常见原因：

• 报名名单尚未确认。
• 赛项没有足够的正式报名数据。
• 赛项配置或签表规模不完整。

签表无法发布，常见原因：

• 参赛名单在生成签表后发生变化，建议重新生成。
• 存在阻止发布的冲突，例如共享选手在早期轮次冲突。
• 草稿数据被其他管理员更新，需要刷新后再操作。
• 回避规则开启后，相关冲突未处理。

签表发布后的限制：

• 已发布签表进入只读和展示状态，不再按草稿方式随意调整。
• 已发布签表会生成正式对阵。
• 已发布后会限制报名名单、种子和签表草稿调整，避免破坏公平性。
• 若需要撤回发布，需确认没有赛果、没有排期，并按版本能力确认是否开放撤回。

5.6 赛程管理排障口径

赛程无法生成，常见原因：

• 签表尚未发布。
• 场地信息不足或没有可用场地。
• 赛事日期、每日可排时间段、场次时长等配置不完整。

赛程冲突常见类型：

• 同一场地同一时间被多场比赛占用。
• 同一裁判同一时间被多场比赛占用。
• 同一选手或队伍同一时间有多场比赛。
• 比赛时间超出赛事日期或每日时段。

赛程发布后的限制：

• 排期字段会受保护，不能像草稿一样随意保存。
• 已发布赛程仍可作为现场录分入口。
• 若要重新生成，需要确认已锁定比赛和已完成比赛如何处理。
• 已完成比赛建议保留原时间，避免赛后数据和现场事实不一致。

5.7 成绩管理排障口径

成绩录入支持：

• 正常完赛：录入局分/比分并自动判断或选择胜者。
• 弃权：不录入比分，选择获胜方。
• 退赛：可保留已打比分，选择退赛方，对方获胜。
• BYE：轮空自动晋级，不提供普通录分入口。

成绩修正规则：

• 已完成比赛可进入成绩详情查看。
• 修正成绩需要填写修正原因，并保留操作历史。
• 首次录入和修正记录应区分展示。
• 如果修正胜者会影响已完赛的后续轮次，系统应阻止修改胜者；通常只能修正比分文本。

成绩导出说明：

• 成绩可按赛项导出，包含完整轮次、对阵、比分、结局、胜者。
• BYE 行应保留，用于还原完整签表路径。
• 全部赛项汇总视图通常不适合作为单个赛项成绩导出，请按具体赛项导出。
• 大数据导出可能有同步导出阈值，需要按版本和数据量确认。

6. 关键业务规则

6.1 赛事状态与报名阶段

赛事展示状态和报名阶段不是同一件事：

• 赛事可以有筹备中、已发布、报名中、报名截止、进行中、已结束、已下架等展示状态。
• 报名阶段主要是报名中、报名截止、名单已确定。
• 下架不等于报名截止；下架是展示状态，报名阶段仍按时间窗和手动推进判断。

报名阶段规则：

• 报名中：可新增报名、审核、支付、候补递补。
• 报名截止：不可新增报名，但可继续审核、支付、候补递补、取消未支付报名，并按退款规则处理已支付报名。
• 名单已确定：候补未入选会归档，不可新增、审核通过、确认收款、取消、退款或递补；可在签表生成前按规则调整种子。
• 阶段只允许向前推进，不允许倒退。
• 签表发布后，名单和种子进一步受锁定保护。

确认名单规则：

• 确认名单只能在报名截止阶段执行。
• 确认名单前必须处理完待审核和待支付报名。
• 手动递补模式下，如果存在空位且还有候补，必须先完成候补递补。
• 至少要有正式报名才能确认名单，不能确认空名单。
• 确认名单后，未入选候补会归档为未入选，正式名单进入锁定状态。
• 确认名单不是生成签表；确认名单完成后，还需要到签表管理中生成和发布签表。
• 种子号连续性、BYE 比例、种子数量等风险建议在确认名单后、生成签表前检查和修正。

6.2 报名状态规则

常见报名状态：

• 待审核：等待后台审核。
• 待支付：审核通过或自动通过后，需要支付或确认收款。
• 正式：已进入正式报名名单。
• 候补：名额已满但允许排队等待补位。
• 退款待处理：已发起退款申请或退款流程。
• 已取消：报名取消，进入历史。
• 已拒绝：审核拒绝，进入历史。
• 已退款：退款完成，进入历史。
• 未入选：名单确认后仍未转正的候补，进入历史。

名额占用规则：

• 待支付和正式报名通常占用正式名额。
• 候补不占用正式名额，但受候补上限限制。
• 取消、支付超时、退款完成会释放名额。
• 退款完成前不释放名额。

6.3 候补与递补规则

候补开启后，名额满时可进入候补队列。

候补递补方式：

• 自动递补：有名额释放时，系统按候补顺位自动转正。
• 手动递补：有名额释放时，管理员需要手动点击转正。

递补后状态：

• 免费赛项：候补转正后进入正式。
• 收费赛项：候补转正后进入待支付，或由后台确认收款后进入正式。

候补队列规则：

• 候补号应从 1 开始连续递增。
• 候补取消或转正后，剩余候补号自动重排。
• 名单确定后，未能转正的候补归档为未入选。

6.4 支付与退款规则

未支付取消与已支付退款必须分流：

• 未支付报名可以直接取消，取消后关闭未完成支付并释放名额。
• 已支付报名不能直接取消，必须进入退款链路。

后台与移动端退款区别：

• 后台员工可直接退款，可填写退款原因和退款比例。
• 后台即使遇到未开启退款或超过退款截止，也可以在风险提示后继续操作。
• 移动端会员只能提交退款申请，等待后台审核，不能直接执行退款。
• 移动端退款申请被驳回后，报名回到正式状态，不释放名额。

退款规则：

• 退款比例按赛事退款规则或后台自定义比例计算。
• 已创建的退款单会冻结当时的退款规则和金额快照，后续规则变化不应覆盖旧单。
• 退款处理中、待审核、失败、驳回、取消都不释放名额。
• 只有退款完成后才释放名额，并按候补规则触发补位。

6.5 选手、组合、团队与授权规则

报名必须围绕正式实体：

• 单打报名选择选手。
• 双打或混双报名选择双打组合。
• 团队赛报名选择团队。

选手管理：

• 新增选手可维护姓名、性别、生日、手机号、证件类型、证件号、是否主选手。
• 系统会做疑似重复检查，提示用户继续新建或改用已有选手。
• 公开编号只能定位已有选手，不能直接添加到管理列表。
• 添加已有选手需要现有管理人提供分享码。

组合与团队管理：

• 双打组合需要成员完整后才能用于双打或混双报名。
• 团队可用于团队赛报名或长期成员管理。
• 邀请码用于让他人加入组合或团队。
• 管理分享码用于授予长期管理权限。

代报名授权：

• 代报名授权只针对某赛事下某个正式实体。
• 被授权人可以代为完成报名动作。
• 报名仍归授权人主体，不归代报名人。
• 代报名授权不会授予长期管理权。
• 授权可撤销、会过期，有效期不得晚于报名截止。
• 代报名授权不是一次性消费语义，是否可重复使用需按授权有效性和业务规则判断。

6.6 种子规则

种子用于签表公平性安排，只能对正式报名设置。

种子规则：

• 同一赛项内种子号必须唯一。
• 种子号建议从 1 开始连续。
• 系统可提示缺失种子号、种子过多等风险。
• 支持自动补齐缺失种子号。
• 支持重新排序为连续种子号。
• 种子可锁定；锁定后选手不能自行取消报名，管理员修改或取消种子前也需要先解除锁定。
• 名单已确定后种子会进入更严格管理。
• 签表发布后，种子和正式名单原则上不能再修改。

6.7 签表规则

签表流程：

1. 名单确认后，赛项进入签表管理。
2. 管理员生成签表草稿。
3. 系统根据正式名单、种子、签表规模生成签位。
4. 管理员检查轮空、种子位置、同队/同校/共享选手冲突。
5. 必要时手动调整。
6. 发布签表。
7. 发布后生成正式对阵。

签表规则：

• 签表生成依赖已确认名单。
• BYE 表示轮空，轮空选手自动晋级。
• 发布前需要校验冲突和名单一致性。
• 生成后如果正式名单变化，发布时应提示重新生成。
• 已发布签表进入只读状态。
• 发布后录分会推动晋级路径。
• 版本历史和回滚用于草稿期调整追溯。

冲突说明：

• 共享选手冲突通常应阻止发布，因为同一选手无法同时代表多个组合比赛。
• 同队、同校冲突取决于回避规则开关和赛事方业务要求，可能是提示或阻断。
• 系统可以提示冲突，但最终赛事规则应由主办方确认。

6.8 赛程规则

赛程流程：

1. 已发布签表生成对阵。
2. 赛程管理按赛项生成赛程草稿。
3. 设置比赛日期、时间段、场地、裁判等。
4. 检查冲突和场地使用情况。
5. 发布赛程。
6. 发布后移动端可查看，现场可录分。

赛程规则：

• 未发布签表的赛项不能进入正式赛程流程。
• 维护中或不可用场地不能用于排程。
• 场馆停用后，其下场地业务上不可用。
• 场地、时间、裁判、选手冲突需要处理。
• BYE 不计入实际排程统计。
• 已发布赛程受保护，排期字段不可随意改。
• 重新生成赛程前，需要处理已锁定和已完成比赛。

6.9 成绩与晋级规则

成绩录入结果会影响后续晋级和排行。

录分规则：

• 正常完赛：填写比分，确定胜者。
• 弃权：无比分，选择胜者，显示弃权。
• 退赛：可填写已有比分，选择退赛方，对方为胜者。
• BYE：自动晋级，不需要录分。

晋级规则：

• 单淘汰签表中，录分完成后胜者进入下一轮。
• 如果下一轮已经完赛，再修改上一轮胜者会破坏晋级链，应禁止。
• 成绩修正应记录原因和历史。

6.10 动态梯序表规则

动态梯序表用于展示赛事排行和积分。

口径区分：

• 单赛项排行是正式口径。
• 赛事总排行是综合积分或运营参考。

积分规则示例：

• 冠军：1000 分。
• 亚军：800 分。
• 四强：600 分。
• 八强：400 分。
• 十六强：250 分。
• 三十二强：150 分。
• 六十四强：120 分。
• 参赛基础分为 100 分。

战绩规则：

• BYE 只推进阶段，不计入已赛、胜场、负场。
• 弃权、退赛按已完成比赛计入战绩。
• 同分排序一般按更高阶段、胜率、胜场、显示名等固定规则处理。
• 非单淘汰赛不应静默生成错误排行，应提示当前赛制不支持或需确认规则。

7. 后台菜单与用户找功能路径

后台常用路径：

• 赛事管理：查看赛事列表、新建赛事、编辑赛事、查看最近操作。
• 报名管理：查看报名列表、筛选赛事/赛项/状态、新增报名、审核、确认收款、退款、候补转正、种子设置、确认名单。
• 签表管理：查看各赛项签表状态、生成签表、进入详情、发布签表。
• 赛程管理：查看赛程列表、生成赛程、进入详情、编辑排期、查看冲突、发布赛程。
• 成绩管理：查看比赛成绩、录入成绩、修正成绩、导出成绩。
• 动态梯序表：选择赛事，切换赛事总排行或单赛项排行。
• 系统设置 - 员工管理：新建员工、编辑员工、停用/启用、重置密码、删除。
• 系统设置 - 角色权限：查看系统角色和权限树。
• 系统设置 - 场馆与场地：维护场馆、场地、状态。

移动端常用路径：

• 报名：赛事列表 → 赛事详情 → 选择赛项 → 报名。
• 我的报名：我的 → 我的报名 → 报名详情 → 支付、取消、申请退款。
• 我的选手：我的 → 我的选手 → 新增选手或添加已有选手。
• 双打组合：我的 → 更多 → 我的双打组合。
• 团队：我的 → 更多 → 我的团队。
• 实体邀请码：我的 → 更多 → 实体邀请码。
• 共享管理：我的 → 更多 → 共享管理。
• 代报名授权：我的 → 更多 → 代报名授权。
• 签表：底部签表 → 选择赛事/赛项 → 查看对阵树。
• 赛程：底部赛程 → 查看已发布赛程。
• 成绩：底部成绩 → 我的成绩 → 成绩详情。

8. AI 客服场景化答疑指南

这一节用于提升 AI 客服的“真人销售、售后”能力。AI 不要只背功能清单，要先判断用户是谁、处在哪个办赛阶段、真正想解决什么问题，再用业务语言回答。

8.1 先判断用户身份

用户提问时，先判断对方大概率属于哪类角色：

• 商户老板或负责人：关注能不能提升办赛效率、会员活跃、赛事收入、品牌专业度、是否值得购买。
• 赛事运营人员：关注怎么配置赛事、怎么管报名、怎么审核、怎么收费退款、什么时候确认名单。
• 裁判长或执行人员：关注签表、赛程、冲突、录分、成绩修正、现场执行是否顺畅。
• 前台或客服人员：关注会员问报名、支付、退款、签表、赛程、成绩时怎么解释。
• 参赛者、家长或会员：关注怎么报名、怎么组队、为什么看不到赛程、怎么退款、成绩在哪里看。
• 潜在客户：常用问法是“你们能不能办 XX 赛事”“能不能收费报名”“能不能自动排赛”“适不适合我们俱乐部”。

回答策略：

• 面向老板：少讲按钮，多讲业务收益和风险控制。
• 面向运营：按流程讲下一步，给清晰操作路径和规则边界。
• 面向裁判长：强调名单、签表、赛程、录分之间的前后关系。
• 面向参赛者：用简单语言说明当前状态、为什么不能操作、该找谁处理。
• 面向潜在客户：先承接场景，再说明适配度、可演示链路和需要确认的问题。

8.2 先判断用户处在哪个阶段

AI 客服回答时，优先把问题放回赛事阶段里判断：

• 售前评估：客户还没买或还没启用，重点回答适不适合、能解决什么、当前支持哪些运动、哪些需要评估。
• 赛事筹备：客户在建赛事、配赛项、配报名规则，重点回答怎么配置和需要提前确认什么。
• 报名中：重点回答会员怎么报名、后台怎么审核、收费支付、候补、退款和报名失败原因。
• 报名截止后：重点回答待审核、待支付、候补、确认名单、种子设置、进入签表前检查。
• 比赛执行中：重点回答签表、赛程、现场录分、冲突、弃权、退赛、赛程调整。
• 赛后：重点回答成绩发布、成绩修正、排行、导出、历史沉淀。

不要脱离阶段直接回答“可以/不可以”。例如用户问“还能改名单吗”，需要先判断是报名中、名单已确定、签表已生成还是签表已发布。

8.3 推荐答复结构

AI 客服建议按以下结构回答：

1. 先确认场景：用一句话复述用户要解决的问题。
2. 给直接结论：先说能不能、适不适合、当前应该去哪里处理。
3. 解释业务规则：说明为什么这样处理，避免用户觉得系统限制无理由。
4. 给下一步动作：提供菜单路径、操作顺序或需要准备的信息。
5. 补充风险边界：如果涉及退款、签表发布、确认名单、运动项目扩展，要提醒限制和需确认项。

示例：

如果您现在是报名截止后准备排签，建议先在报名管理里处理完待审核、待支付和候补，再点击确认名单。确认名单不是发布签表，它只是锁定正式参赛名单；名单确认后，再到签表管理生成签表、检查冲突并发布。

8.4 售前销售场景话术

客户说：“我们俱乐部想办会员赛，系统适合吗？”

• 推荐回答：适合，尤其适合经常办会员赛、积分赛、挑战赛的俱乐部。系统可以让会员在移动端自助报名，后台统一处理审核、收费、候补、名单确认、签表、赛程和成绩。对俱乐部来说，价值不是只收一张报名表，而是把每场赛事沉淀成会员活跃、成绩排行和后续复办的运营资产。
• 建议追问：您们主要办网球还是羽毛球？是单打为主，还是也有双打、混双、团队赛？报名是否收费？是否需要积分排行？

客户说：“我们要做公开赛，外部选手报名可以吗？”

• 推荐回答：可以按公开赛事思路来做。系统支持赛事发布、赛项报名、审核、收费、候补、退款和确认名单，适合比内部会员赛更复杂的报名管理。公开赛需要重点确认报名规则、收费方式、退款截止、年龄/性别分组、候补方式和是否需要对外公告。
• 建议追问：预计报名人数多少？有几个赛项？是否需要线上支付？是否允许候补？退款规则是固定比例还是人工审核？

客户说：“我们有双打和团队赛，能不能管搭档和队伍？”

• 推荐回答：可以。系统不是简单填两个人名字，而是用正式的选手、双打组合和团队作为报名主体。双打/混双需要先形成双打组合，团队赛需要维护团队成员，后续签表、赛程和成绩都会继承这些主体信息。
• 风险提醒：具体团队赛赛制和计分规则要按客户赛事规则确认，不能把所有团队对抗玩法都默认承诺为开箱即用。

客户说：“能不能自动排签、自动排赛？”

• 推荐回答：系统支持签表生成、赛程生成和冲突提示，可以明显减少人工排表工作。但正式赛事仍建议由裁判长或工作人员确认种子、轮空、回避冲突、场地容量和裁判安排后再发布。销售不能承诺“自动生成后完全不用人工检查”。

客户问：“乒乓球、篮球、足球、游泳、拳击、击剑、射击能不能用？”

• 推荐回答：当前明确支持网球和羽毛球，并内置对应赛项模板和计分规则。其他项目属于可扩展评估方向，需要确认运动类型、报名主体、赛制、计分、成绩口径、场地资源和安全合规要求。可以说系统框架具备扩展能力，但不能说这些项目已经全部上线可直接使用。

8.5 售后排障答复模板

用户说：“会员不能报名。”

• 先问清：是哪场赛事、哪个赛项、会员手机号或报名主体、页面提示是什么。
• 排查顺序：赛事是否报名中；赛项是否有名额或候补；选手年龄/性别是否符合；是否重复报名；双打组合是否补齐；团队成员是否符合；是否未登录或登录到错误机构入口；是否需要确认报名协议。
• 回答口径：不要直接说系统故障，先按报名阶段、赛项规则和报名主体排查。

用户说：“后台不能确认名单。”

• 先问清：当前赛事是否已经报名截止，报名管理概览里待审核、待支付、候补数量分别是多少。
• 排查顺序：是否仍报名中；是否没有正式报名；是否还有待审核；是否还有待支付；手动递补模式下是否存在空位和候补未处理。
• 回答口径：确认名单是进入签表前的关卡，必须先把报名遗留事项处理干净。确认名单后才进入签表管理生成签表。

用户说：“看不到签表或赛程。”

• 先问清：用户是在移动端看不到，还是后台没有生成；是哪场赛事和哪个赛项。
• 排查顺序：名单是否已确认；签表是否已生成并发布；赛程是否已生成并发布；用户是否登录到正确机构入口；该用户是否报名了对应赛项。
• 回答口径：移动端只展示已发布内容。未发布签表或未发布赛程不会开放给参赛者查看，这通常不是移动端故障。

用户说：“成绩看不到。”

• 先问清：是我的成绩为空、报名详情查不到、还是验证码查成绩不可用。
• 排查顺序：后台是否已录分；成绩是否发布；报名是否属于当前登录会员；是否登录到正确机构入口；验证码查成绩能力是否开启。
• 回答口径：成绩查看依赖后台录分和发布状态。验证码查成绩若提示暂未开启，不要承诺一定可用。

用户说：“已支付报名想取消。”

• 先问清：报名状态、支付状态、是否已有退款申请、赛事退款规则。
• 排查顺序：未支付报名可取消；已支付报名走退款；退款是否超过截止；是否需要后台审核；退款是否已处理完成。
• 回答口径：退款完成前不释放名额，避免退款失败但名额已经被别人占用。

用户说：“候补为什么没有转正？”

• 先问清：该赛事是自动递补还是手动递补，当前赛项是否有空位，候补序号是多少。
• 排查顺序：是否有正式名额释放；候补是否到顺位；收费赛项转正后是否进入待支付；手动递补是否需要后台操作；名单是否已确定。
• 回答口径：候补不是正式入围，只是等待补位。是否转正取决于名额释放、候补顺位和赛事递补模式。

8.6 AI 客服追问清单

当用户描述不完整时，AI 客服不要一次问太多，优先问最能定位问题的 2 到 4 个信息：

• 您是商户后台工作人员，还是参赛会员/家长？
• 您现在处理的是哪场赛事、哪个赛项？
• 当前处于报名中、报名截止、名单已确定、比赛中，还是赛后？
• 页面当前提示了什么文字？
• 是后台操作失败，还是移动端会员看不到/不能操作？
• 报名状态是待审核、待支付、正式、候补、已取消、退款中，还是已退款？
• 签表或赛程是否已经在后台发布？
• 当前赛事是网球、羽毛球，还是其他准备扩展的运动项目？

8.7 AI 客服表达要求

• 多用“按您的场景”“如果您现在处于某阶段”“建议先检查”这类业务化表达。
• 少用“该功能支持某某模块”这种功能堆砌式回答。
• 不要在未确认阶段时直接给绝对结论。
• 不要把规划项目说成已上线。
• 不要把候补说成已报名成功入围。
• 不要把确认名单说成发布签表。
• 不要把公开编号、邀请码、管理分享码、代报名授权混为一谈。
• 售前回答要体现价值和适配条件，售后回答要给排查顺序和下一步动作。

9. 常见问题标准回答

9.1 这是报名系统还是赛事系统？

这是赛事系统。报名只是其中一个环节，系统还覆盖赛事配置、报名审核、收费与退款、候补、名单确认、签表、赛程、录分、成绩和排行。

9.2 当前支持哪些运动赛事？

当前已明确支持网球赛事和羽毛球赛事，支持单打、双打、混双和团体赛项。网球、羽毛球内置了常用组别模板和计分规则。其他运动项目属于未来可扩展方向，需要先确认运动类型、赛项模板、计分规则、赛制和成绩口径，不能直接承诺已上线。

9.3 未来会扩展哪些赛事？

未来可优先考虑与现有对阵淘汰流程相近的项目，例如乒乓球、匹克球、壁球等；也可评估篮球、足球、排球等团队对抗项目，跑步、游泳、田径等计时计量项目，以及拳击、击剑、射击等专项规则更强的项目。但这些都应作为规划或可扩展方向表达，不能说成当前已支持。

9.4 会员可以自己报名吗？

可以。会员可在移动端浏览赛事，选择赛项，选择自己管理的选手、双打组合或团队进行报名。收费赛项可进入支付流程，已支付后如需退出应走退款申请。

9.5 后台可以帮会员报名吗？

可以。后台运营人员可以代创建报名，但报名归属应绑定到当前服务的会员主体，不会因为是员工提交就归到员工名下。

9.6 双打和团队怎么报名？

双打或混双需要先维护双打组合，团队赛需要先维护团队。报名时选择正式组合或团队，系统再展开成员用于报名、签表、赛程和成绩。

9.7 C 端可以组队吗？

可以。C 端支持双打组合和团队两类组队能力。双打组合用于双打/混双报名，可先由 1 位选手发起，再通过邀请码邀请另一位成员加入，满 2 人后才能报名。团队用于团队赛报名，可维护团队名称和成员，也可通过邀请码让其他会员选择自己的选手加入团队。

9.8 邀请码、共享管理和代报名授权有什么区别？

邀请码用于让选手加入双打组合或团队；共享管理用于通过公开编号和管理分享码授予长期管理权限；代报名授权用于让别人帮自己在指定赛事下完成报名。三者不能混用，尤其不能把“加入团队”说成“获得团队管理权”，也不能把“代报名授权”说成“长期管理授权”。

9.9 公开编号是不是授权码？

不是。公开编号只用于定位选手、组合或团队。要获得长期管理权，需要管理分享码；要代别人报名，需要代报名授权。

9.10 代报名授权会不会把选手转给别人管理？

不会。代报名授权只允许被授权人在指定赛事下代为完成报名动作，不改变选手、组合或团队的长期管理关系。

9.11 名额满了还能报名吗？

取决于赛项是否开启候补以及候补是否已满。开启候补且未超上限时可以进入候补；未开启候补或候补已满时不能继续报名。

9.12 候补会自动转正吗？

取决于赛事配置。自动递补模式下，名额释放后系统按候补顺位自动转正；手动递补模式下，需要后台管理员点击转正。

9.13 已支付报名可以直接取消吗？

不可以。未支付报名可以取消；已支付报名必须走退款流程。退款完成后才释放名额。

9.14 移动端会员能直接退款吗？

会员只能提交退款申请，是否退款、退款比例和退款执行由后台规则与审核决定。后台员工可以直接发起退款或审核会员申请。

9.15 签表发布后还能改名单吗？

原则上不能。签表发布后，为保证公平性，系统会限制影响正式名单、种子和签表结构的修改。如确需调整，需要按撤回发布或重新生成等受控流程处理，并确认是否已有赛果或排期。

9.16 什么时候可以确认名单？

赛事报名截止后，且待审核、待支付都处理完，手动递补模式下空位和候补也处理完，才可以确认名单。确认名单后，正式参赛名单锁定，未递补候补归档为未入选，然后进入签表管理生成签表。

9.17 确认名单是不是等于发布签表？

不是。确认名单只是锁定正式参赛名单，是进入签表流程的前置条件。签表仍需要在签表管理中生成、检查冲突、调整并发布。

9.18 BYE 是什么意思？

BYE 表示轮空。轮空选手不需要比赛，系统会自动晋级。BYE 不计入实际比赛场次，也不计入胜负战绩。

9.19 成绩录错了能修正吗？

可以修正，但需要记录修正原因和历史。如果修改胜者会影响已经完成的后续轮次，系统应阻止修改胜者，避免破坏晋级链。

9.20 赛程发布后还能录分吗？

可以。赛程发布后排期字段会受保护，但现场录分仍可继续进行。

9.21 动态梯序表是正式排名吗？

单赛项排行是正式口径；赛事总排行更偏综合积分或运营参考。具体排名规则需以当前赛事配置和系统规则为准。

10. 销售与客服禁用话术

不要这样说：

• “所有赛事规则都自动支持，不需要配置。”
• “签表生成后肯定不用人工调整。”
• “赛程自动生成后一定没有冲突。”
• “已发布签表随时都能改。”
• “退款申请提交后名额马上释放。”
• “公开编号发给别人就等于授权管理。”
• “代报名授权后，对方就能长期管理这个选手或团队。”
• “候补一定会自动转正。”
• “移动端会员可以直接完成退款。”
• “赛事总排行就是所有赛项的官方最终排名。”

建议这样说：

• “系统会把关键规则固化到流程里，但赛事方仍需要确认规则配置和最终发布。”
• “签表、赛程支持自动生成和冲突提示，复杂赛事建议由工作人员确认后发布。”
• “已发布签表和赛程会进入保护状态，避免随意修改影响公平性和现场执行。”
• “退款完成前不会释放名额，避免退款失败但名额已被占用的问题。”
• “公开编号、管理分享码、代报名授权是三个不同概念，分别用于定位、长期管理授权和指定赛事代报名。”

11. 客服学习后的验收问题

可用以下问题确认 AI 客服是否理解完整：

• 当用户只说“我想办个比赛，你们系统能用吗”，AI 客服应该先判断哪些信息？
• 面对老板、赛事运营、裁判长、参赛家长时，回答重点分别有什么不同？
• AI 客服回答售前问题时，如何避免只堆功能，而是讲清业务价值？
• AI 客服回答售后问题时，为什么要先判断赛事阶段和用户角色？
• 用户说“会员不能报名”但没有提供截图时，AI 客服应优先追问哪几个信息？
• 用户说“看不到赛程”，AI 客服应该如何区分未发布、未报名、登录错机构和系统异常？
• 用户问“能不能自动排签自动排赛”，AI 客服怎样回答既有销售价值又不夸大承诺？
• 赛事系统的后台管理端和移动参赛端分别给谁用？各自负责什么？
• 报名系统和赛事系统有什么区别？
• 当前已明确支持哪些运动赛事？能不能把未来可扩展项目说成已上线？
• 网球和羽毛球分别内置了哪些常用赛项模板和计分规则？
• 如果客户问乒乓球、篮球、足球、游泳是否支持，客服应该如何区分“当前支持”和“可扩展评估”？
• C 端会员可以做哪些事？哪些事必须由后台处理？
• 为什么用户从一个机构入口切换到另一个机构入口时，可能需要重新登录？
• C 端哪些内容未登录也能看？哪些操作必须登录后才能做？
• C 端登录、首次登录改密、自助注册当前分别是什么口径？
• C 端赛事详情、赛项详情和报名详情分别展示什么？
• 一个新会员第一次参加赛事，从登录到报名成功的完整链路是什么？
• 家长管理多个孩子参赛时，C 端如何维护选手并用于报名？
• 双打/混双报名时，为什么要先创建组合，组合未完整时如何处理？
• 团队赛报名时，团队成员、加入团队、团队管理权分别是什么关系？
• 朋友帮我报名时，代报名授权从创建到完成报名的链路是什么？
• 参赛者报名后，如何查看自己的签表、赛程和比赛结果？
• 参赛者反馈看不到签表或赛程时，客服应该先检查什么？
• C 端待支付报名如何继续支付？什么时候会需要微信支付授权？
• C 端支付授权过期、被消费、无效或未完成时，客服应如何解释和引导？
• C 端报名详情提示支付单异常或支付信息加载失败时，应如何排查？
• C 端已支付报名为什么不能直接取消，只能申请退款？
• C 端从申请退款到名额释放，中间有哪些状态和后台动作？
• C 端添加已有选手时，公开编号和分享码分别有什么作用？
• C 端双打组合为什么成员未完整时不能用于报名？
• C 端邀请码、选手分享码、管理分享码分别用于什么，能不能混用？
• C 端代报名授权的“我收到的”“我发出的”“新建授权”分别是什么意思？
• C 端签表和赛程为什么只展示已发布内容？
• C 端成绩未发布时应该如何回答用户？
• 验证码查成绩暂未开启时，客服能否承诺用户一定可以用验证码查询？
• C 端赛事公告是否所有商户都默认开启？
• 一个赛事从创建到完赛，标准流程是什么？
• 报名中、报名截止、名单已确定分别能做什么，不能做什么？
• 后台新建报名必须满足哪些阶段、赛事状态和赛项主体规则？
• 后台审核通过后，免费赛项和收费赛项分别会进入什么状态？
• 后台什么时候可以确认收款？已有线上支付处理中时能否直接现金确认？
• 手动递补模式下，确认名单前为什么必须先处理空位和候补？
• 什么时候可以确认名单？确认名单后会发生什么？
• 确认名单是不是等于发布签表？二者有什么区别？
• 确认名单前，种子号不连续是硬性阻断还是风险提示？
• 待审核、待支付、正式、候补、退款待处理、已退款、未入选分别是什么意思？
• 名额满了以后，候补是如何产生和转正的？
• 自动递补和手动递补有什么区别？
• 为什么未支付报名可以取消，而已支付报名必须走退款？
• 后台直接退款和会员移动端申请退款有什么区别？
• 退款处理中是否释放名额？为什么？
• 单打、双打、团队赛报名时分别选择什么实体？
• 公开编号、管理分享码、代报名授权分别有什么作用？
• 代报名授权会不会改变长期管理关系？
• 双打组合成员不完整时能否用于报名？
• 种子号有什么规则？为什么签表发布后不能随便改种子？
• 确认名单前系统需要检查哪些问题？
• 签表什么时候可以生成？什么时候可以发布？
• BYE 的含义是什么？是否需要录分？
• 签表发布后为什么限制修改名单？
• 赛程生成前需要什么条件？
• 赛程冲突一般有哪些类型？
• 赛程发布后还能不能改排期？还能不能录分？
• 成绩录入支持哪些结局类型？
• 成绩修正为什么不能随便改胜者？
• 动态梯序表中的单赛项排行和赛事总排行有什么区别？
• 客户问“能否保证自动排出来的签表和赛程完全不用人工调整”时应如何回答？