Files
LLHS/01_设计/废品回收小程序产品需求文档.md
2025-08-12 14:02:16 +08:00

11 KiB
Raw Blame History

废品回收小程序产品需求文档 (PRD) V2.0

文档状态: 修订中 版本: 2.0 修订日期: 2025-08-08 作者: Claude, AI产品助手


修订历史

版本 修订日期 修订人 修订内容
1.0 2025-08-07 Claude 初稿,定义了用户端和小站端的核心功能
2.0 2025-08-08 Claude 根据反馈重构,细化为四端模型,增强可执行性

1. 项目概述

1.1 项目背景

本项目旨在通过数字化的O2O平台连接社区居民、社区回收小站、物流司机和后端处理中心打造一个高效、透明、便捷的废品回收生态系统。平台以微信小程序为主要载体解决传统废品回收流程中信息不对称、效率低下、用户体验差等痛点。

1.2 核心问题与解决方案

  • 居民侧: 出售废品渠道少、价格不透明、流程繁琐 → 提供一个稳定、便捷、价格透明的线上出售渠道。
  • 小站侧: 人工记账易出错、库存管理混乱、与上游对接效率低 → 提供一套移动化、自动化的记账、库存及对接工具。
  • 物流侧: 揽收路线不科学、交接凭证混乱、运输过程不可控 → 提供数字化的揽收任务管理和扫码交接功能。
  • 公司侧: 缺乏全局数据、无法精细化运营、业务模式难以复制 → 搭建一个集数据监控、运营管理、财务结算于一体的中心化管理后台。

1.3 项目目标

  • V1.0 (MVP) 目标:
    • 验证核心商业模式:居民到小站的回收流程。
    • 在1-2个试点社区实现每周100+笔交易。
    • C端用户次月留存率达到30%B端小站无主动流失。

1.4 核心用户画像

  • C端 - 居民:
    • 王大妈: 65岁退休在家对价格敏感会用微信但对复杂操作有困难。希望卖废品能像去超市买菜一样简单。
  • B端 - 小站站长:
    • 李老板: 45岁社区超市店主。希望回收操作不影响主业记账清晰能快速和上游完成交接结算。
  • 物流端 - 司机:
    • 张师傅: 35岁回收车队司机。希望能有清晰的揽收路线交接时不用手写单据扫个码就能搞定。
  • 后台 - 运营经理:
    • 小陈: 28岁公司运营。希望实时看到各小站的回收数据能灵活调整回收品类和价格。

2. 整体业务流程

graph TD
    subgraph C端用户
        A[1.居民携带废品到小站] --> B{2.出示个人收款码};
    end

    subgraph B端用户
        B --> C[3.站长扫码识别用户];
        C --> D[4.选择品类, 输入重量];
        D --> E[5.确认金额, 完成交易];
        E --> F((资金计入用户余额));
        E --> G[6.定期向上游发起交接];
    end

    subgraph 物流端
        G --> H[7.司机接单, 前往小站];
        H --> I[8.扫小站出库码, 核对品类重量];
        I --> J[9.确认揽收, 运输至打包站];
    end

    subgraph 管理后台
        K[品类/价格管理] --> D;
        F --> L[订单流水监控];
        G --> M[库存数据监控];
        I --> N[物流状态跟踪];
        J --> O[财务结算管理];
    end

3. C端居民端小程序

核心定位:让卖废品像收钱一样简单。

3.1 功能模块详述

3.1.1 登录/注册

  • 需求: 微信一键授权登录,自动创建账户,无需额外注册步骤。

3.1.2 首页 (核心页面)

  • 界面元素:
    1. 【我的卖品码】: 页面最中心、最大的按钮,点击后全屏显示个人专属二维码,并调高屏幕亮度。
    2. 【附近小站】: 列表或地图形式,展示附近合作小站的位置、实时营业状态(营业中/休息中)、距离我有多远、联系电话。
    3. 【今日回收价】: 醒目位置展示主要品类(纸壳、塑料瓶等)的单价(元/斤)。

3.1.3 “我的”页面

  • 界面元素:
    1. 【我的余额】: 突出显示当前账户余额。
    2. 【提现】(V1.1): 将余额提现至微信零钱。需进行实名认证。
    3. 【交易记录】: 列表形式,展示每一笔交易的时间、地点、品类、重量、金额。
    4. 【联系客服】: 提供客服电话或在线咨询入口。

3.1.4 消息通知

  • 需求:
    • 交易成功后,收到模板消息推送,告知本次收入金额。
    • 提现成功后,收到模板消息推送。

4. B端小站端小程序

核心定位:高效的移动回收工作站。

4.1 功能模块详述

4.1.1 登录

  • 需求: 由管理员在后台创建账号,站长通过“手机号+验证码”登录。

4.1.2 工作台 (首页)

  • 界面元素:
    1. 【开始回收】: 核心操作按钮,点击进入扫码回收流程。
    2. 【今日汇总】: 数据卡片,展示当日回收总单数、总重量、总金额。
    3. 【库存盘点】: 查看当前各类废品的库存重量。当库存达到预警阈值时,系统应有明显提示。
    4. 【向上游交接】: 生成出库单,一键通知物流团队上门揽收,并出示出库二维码。

4.1.3 回收流程 (核心业务)

  1. 扫码识客: 点击“开始回收”启动扫码器扫描C端用户的“卖品码”。成功后显示用户昵称。
  2. 录入信息:
    • 品类选择: 大按钮形式选择“纸壳”、“塑料瓶”等。
    • 重量输入: 手动输入称重后的重量。
    • 系统自动计算金额并显示。
  3. 确认交易: 与用户核对无误后,点击“确认”。系统二次弹窗确认。
  4. 语音播报: 交易成功后,必须有清晰的语音播报,如“收款成功5.8元”,方便老年用户确认。

4.1.4 账单与库存

  • 账单: 查看每日、每周的交易流水和收入汇总。
  • 库存: 实时查看各品类库存,达到阈值时有提醒。

5. 物流端 (打包站/司机端)

核心定位:精准、高效的废品“快递员”。 (初期可为H5页面或集成在B端小程序中)

5.1 功能模块详述

5.1.1 揽收任务

  • 需求: 查看由系统(或后台运营)派发的揽收任务列表,包含小站地址、预计揽收重量、联系方式。
  • 功能: 支持路线规划。

5.1.2 扫码交接

  • 需求: 到达小站后,扫描小站端生成的“出库码”。
  • 流程: 扫码后,页面显示待交接的品类和重量。司机确认实际收到的重量,可进行修改。双方确认后,完成交接。

5.1.3 状态更新

  • 需求: 可手动更新任务状态,如“运输中”、“已入库”。

6. 大仓管理端 (Web/PC)

核心定位:业务流转的仓储枢纽,数据准确性的最终保障。

6.1 功能模块详述

6.1.1 扫码确认入库

  • 需求: 司机运抵大仓后,仓管员扫描司机任务单(或出库单)上的二维码。
  • 流程: 系统自动带出司机、来源小站、货品品类及重量等信息。仓管员核对实物后确认,完成入库操作。库存数据自动更新。

6.1.2 实时库存监控

  • 需求: 在PC端或数据大屏上以可视化图表展示所有品类的实时库存量、库存周转天数、存放位置等。
  • 目标: 为仓储规划和销售决策提供数据支持。

6.1.3 出库管理

  • 需求: 当与下游回收商(如打包站)达成交易后,可在系统中选择品类和重量,一键生成标准化的出库单。
  • 凭证: 出库单可打印,作为与下游结算和备货的依据。

7. 统一管理后台 (Web端)

核心定位:公司的“大脑”,驱动业务运转。

6.1 功能模块详述

6.1.1 Dashboard 数据看板

  • 需求: 实时展示核心KPI今日交易额、活跃用户数、各小站回收量排名、各品类回收趋势图等,形成数据驾驶舱。

6.1.2 用户管理

  • 需求: 查询C端用户信息、交易记录、账户状态。

6.1.3 小站管理

  • 需求: 小站的入驻审核、信息管理(名称、地址、地理位置、负责人、营业时间)、地理位置分布图、服务状态(营业/休息)管理。

6.1.4 品类与价格管理

  • 需求: 动态添加/修改/停用回收品类,实时调整各品类在不同区域或站点的回收单价。支持设置不同品类的物流损耗参数。

6.1.5 订单与库存管理

  • 需求: 查询全平台所有交易流水。实时监控各小站、各打包站的库存情况。

6.1.6 物流管理

  • 需求: 查看物流司机信息,手动派发或调整揽收任务,跟踪任务状态。

6.1.7 财务管理

  • 需求: 管理与小站、物流司机的结算周期和账单,支持账单导出。

6.1.8 系统管理

  • 需求: 后台操作员的角色与权限管理。对异常登录行为进行告警

6.1.9 报警中心

  • 需求: 集中查看和处理系统产生的各类业务异常报警(如库存异常、交易异常、物流延误),记录处理过程与结果,并支持上报给相关负责人。

8. 非功能性需求

  • 性能: 扫码响应时间 < 1秒。页面加载时间 < 2秒。系统核心接口可用性 > 99.9%。
  • 易用性: C端和B端界面必须严格遵循“适老化”设计大字体、高对比度、操作简单。
  • 安全性: 交易、支付、个人信息等敏感数据必须加密传输和存储。需有完善的权限管理体系,防止未授权访问。
  • 可扩展性: 架构设计应支持未来新品类、新城市、新业务模式(如积分商城、上门回收)的快速扩展。
  • 可观测性 (Observability):
    • 监控与告警: 对服务器、数据库、核心接口等进行实时监控并在出现异常如CPU过高、响应超时通过短信/邮件/企业微信发出告警。
    • 日志管理: 建立集中化的日志平台,支持按关键字、时间、服务模块快速检索日志,以便于高效排查问题。
  • 可维护性:
    • 版本更新与回滚: 发布流程应支持一键回滚到上一个稳定版本。
    • 容量规划: 定期输出系统资源使用趋势报告,为扩容提供决策依据。

9. 版本迭代规划 (Roadmap)

  • V1.0 (MVP):
    • 核心功能: C端 + B端核心回收流程、管理后台基础框架品类价格、订单查看
    • 目标: 跑通“居民->小站”核心商业模式闭环。
  • V1.1:
    • 新增功能: 物流端H5、后台物流管理、后台小站管理、C端提现功能。
    • 目标: 引入物流角色,实现“小站->大仓”规范化清运。
  • V1.2:
    • 新增功能: 大仓管理模块、后台财务结算模块、数据报表优化。
    • 目标: 完善全链路管理,提升运营和财务效率。
  • V1.3:
    • 新增功能: C端积分商城、精细化运营工具如用户分层、活动配置
    • 目标: 探索增值服务,提升用户粘性。