报名与身份服务
承载报名信息、身份核验和骑手凭证，让参与者与主办方围绕同一身份状态继续后续服务。
核心是状态连续，不只是把纸质表单搬到线上。
PROJECT BACKGROUND
近千人参加、六个沿途点位，一场骑行活动需要同时管理人、路线和服务状态。
客户是一家大型政府赛事主办方，面向约 1000 名骑行参与者组织 2026 年大型活动。服务不只发生在活动当天，而是从报名、身份核验开始，持续到骑手凭证、路线引导、沿途打卡、权益领取和现场咨询。
参与者需要一个连续入口，主办方则需要知道服务推进到哪一步，并把大量重复问题与真正的现场异常区分开。
活动规模约 1000 名骑行参与者
路线服务6 个沿途站点 / 打卡点
用户入口微信小程序一站式承载
知识服务活动规则、路线点位与高频问答
01 / 业务原貌
参与者看到的是一场活动，组织者面对的是一条跨越多个环节的服务链。
报名信息、身份核验、骑手凭证、路线说明、点位签到和活动权益分别由不同材料与人员维护。越接近活动日期，路线、时间、资格和签到类问题越集中，工作人员容易在重复沟通中消耗精力。
01 报名
提交身份与参赛信息，等待资格确认。
02 核验
主办方确认参与资格并生成骑手凭证。
03 行前准备
查询路线、规则、时间、装备与服务信息。
04 现场参与
沿 6 个点位完成路线引导、扫码与打卡。
05 权益服务
完成权益领取、问题咨询和异常处理。
02 / 核心问题
单点功能并不复杂，难的是让千人规模下的状态和口径保持一致。
入口分散
报名、凭证、路线、打卡和咨询若分布在多个链接与群消息中，参与者需要反复寻找。
身份与进度难串联
组织者需要知道谁已报名、是否核验、到达哪个点位、权益是否完成。
重复咨询挤占现场
大量路线、时间、规则问题内容相似，却需要工作人员一次次回答。
活动数据难复用
服务过程如果只停留在临时表格和群聊，活动结束后很难复盘参与路径和信息缺口。
03 / 建设目标
让参与者沿一个入口完成主要动作，让工作人员只接住必须由人处理的异常。
项目以微信小程序作为统一入口，连接报名、身份核验、骑手凭证、路线、扫码打卡与权益服务；同时把正式规则和路线点位组织成 AI 问答知识范围，为高频问题提供一致回答。
问答服务的边界从一开始就被限定：只回答已发布信息；遇到临时变化、资格争议、安全和个体异常时，明确转交现场人员。
04 / 方案模块
前台是一套小程序，背后对应三条彼此连接的业务能力。
路线、点位与扫码打卡
集中展示路线和 6 个站点信息，支持沿途扫码打卡，并把参与进度与活动权益连接起来。
参与者知道下一步去哪，组织者看到服务推进到哪。
AI 问答与人工分流
围绕活动规则、路线点位和常见问题提供统一回答，无法覆盖或涉及风险的问题进入人工处理。
系统承担公开信息检索，现场团队承担变化、风险与责任。
05 / 参与者旅程
把报名、行前准备和现场参与连成一个可理解的过程。
01 在线报名
提交必要信息，查看当前报名与审核状态。
02 获取凭证
身份确认后获得骑手凭证和活动须知。
03 查询准备
从同一入口查看路线、时间、规则并提出问题。
04 沿途打卡
按路线到达站点，扫码记录活动进度。
05 完成服务
领取对应权益；异常和争议转由现场人员处理。
06 / 项目结果
参与者获得统一入口，主办方获得一条可观察、可继续复用的服务链。
参与规模
系统围绕约 1000 名骑行参与者的完整服务过程建设。
规模数字说明项目范围，不等同于并发峰值或最终到场人数。
路线服务
6 个沿途站点进入统一路线、打卡和进度链路。
临时封路、天气和安全调度仍以现场正式通知为准。
参与体验
报名、凭证、路线、打卡、权益与问答集中在微信小程序。
一站式入口减少信息跳转，但不能替代所有现场服务。
组织复用
报名状态、参与进度和未覆盖问题可以用于活动复盘。
后续复用需要继续遵守数据权限、保存期限和用途边界。
证据说明：本页依据项目交付记录整理并匿名化。对“服务效率提升”和“减少重复咨询”只描述工作方式变化；在没有完整统计口径前，不对外宣称具体百分比。
07 / 人机边界
AI 回答公开规则，人处理变化、风险和责任。
AI 可以处理
- 路线、时间、签到与公开规则查询
- 常见问题的统一口径回答
- 记录未知问题和知识缺口
仍由人决定
- 临时通知、路线调整与现场调度
- 安全、医疗和紧急事件处理
- 个人报名、资格和争议判断
08 / 适用边界
服务流程明确、公开信息稳定的大型活动更适合复制这套思路。
更适合
参与人数多、服务环节清楚、重复咨询集中，并能指定权威信息发布与人工升级责任人。
不适合直接照搬
信息持续变化却没有统一发布机制，或希望问答系统承担安全、医疗与现场指挥责任。