sam
e24925e1ed
- 新增 .dockerignore 文件，忽略多种临时及中间文件 - 新增 .gitattributes 文件，配置文本文件换行及合并行为 - 新增详细的 .gitignore 文件，排除多种开发及生成文件 - 新增 VS Code C# 代码片段，提升开发效率 - 添加 Directory.Build.props，统一 MSBuild 配置和代码分析规则 - 添加空的 Directory.Build.targets，预留构建任务扩展位置 - 添加 Directory.Packages.props，实现依赖包版本集中管理和声明
108 lines
6.6 KiB
Markdown
108 lines
6.6 KiB
Markdown
好的，根据您提供的思路，我为您完善了“一物一码会员营销系统”的业务说明部分。这份说明侧重于梳理核心业务逻辑和流程，希望能帮助您更清晰地表达项目规划。
|
||
|
||
一物一码会员营销系统 - 业务需求说明
|
||
|
||
1. 会员体系构建
|
||
|
||
1.1 核心业务逻辑：一物一码关联
|
||
|
||
本系统的基石是“一物一码”技术，即每个产品上的营销码都是唯一的。消费者购买产品后，通过扫描该码，即可触发一系列会员相关的业务操作。这不仅是防伪验真的手段，更是将线下消费行为转化为线上会员关系的核心入口。
|
||
|
||
1.2 前端主要业务功能
|
||
|
||
面向消费者（C端用户）的前端业务流如下：
|
||
|
||
• 会员注册/登录：提供基于手机号的快速注册与登录流程。业务上，重点在于扫码即注册或扫码后引导注册的无感化体验，极大降低会员转化门槛。
|
||
|
||
• 积分获取与反馈：
|
||
|
||
◦ 主要途径：消费者扫描产品上的营销码，经系统校验通过后，自动获得相应积分。这是积分获取的核心业务场景。
|
||
|
||
◦ 即时反馈：前端需清晰展示本次扫码获得的积分数、积分来源（如：购买XX产品）以及当前总积分。
|
||
|
||
◦ 规则透明：提供积分记录查询页面，让会员清晰了解每一笔积分的来源（扫码、活动等）和消耗（兑换、过期等）详情。
|
||
|
||
• 会员中心：展示会员基本信息、等级权益、积分余额与明细。
|
||
|
||
1.3 后端主要业务功能
|
||
|
||
面向系统管理员（Admin端）的后端业务功能，旨在支撑前端业务流并进行有效管理：
|
||
|
||
• 会员基础管理：支持会员账号的创建、查询、禁用及信息维护。核心在于将扫码行为与会员ID精准绑定，构建统一的会员档案。
|
||
|
||
• 积分配置与规则引擎（核心业务）：
|
||
|
||
◦ 规则创建：Admin端能够灵活配置积分规则。这包括：
|
||
|
||
▪ 基于产品/品类：为不同产品、不同品类设置不同的积分值。例如，高利润产品可配置更高积分以刺激购买。
|
||
|
||
▪ 基于时间/活动：支持设置限时积分翻倍、节假日专属积分等活动规则。
|
||
|
||
▪ 唯一性校验（去重规则）：这是业务规则的关键。系统必须确保同一个营销码只能被积分一次。当同一码被多次扫描时，系统应能识别并拒绝重复积分，同时可向后续扫描者展示“该码已被兑换”等提示，保障营销费用的公平性与有效性。
|
||
|
||
◦ 规则发布与生效：配置的规则需有明确的生效时间和状态控制，并支持测试验证。
|
||
|
||
• 积分记录审计：系统自动记录所有积分流水，包括会员ID、营销码、积分值、获取时间、规则来源等。Admin端需提供强大的查询与导出功能，用于业务分析、对账和争议处理。
|
||
|
||
• 会员画像与分层：基于会员的扫码频率、产品偏好、积分积累等数据，系统可自动为会员打标签（如：高频用户、母婴爱好者），或进行等级划分（如：普通、白银、黄金会员），并配置不同权益，为精准营销提供数据基础。
|
||
|
||
表：积分获取规则配置示例
|
||
|
||
规则维度 配置示例 业务目的
|
||
|
||
产品维度 A产品扫码得10分，B产品扫码得20分 引导消费高附加值产品
|
||
|
||
时间维度 国庆期间（10.1-10.7）扫码积分翻倍 刺激节假日销量
|
||
|
||
人群维度 黄金等级会员额外获得10%积分 提升高价值用户忠诚度
|
||
|
||
防作弊维度 同一手机号对同一营销码仅积分一次 防止刷单，保障营销成本
|
||
|
||
2. 会员积分消耗体系
|
||
|
||
积分消耗是提升会员粘性和促进复购的关键环节，其主要载体是积分商城。
|
||
|
||
2.1 积分商城的礼品库构建
|
||
|
||
礼品库是积分兑换业务的基础物资中心，其业务管理要点包括：
|
||
|
||
• 礼品类型管理：支持添加和管理多种类型的礼品，主要包括：
|
||
|
||
◦ 实物礼品：如电子产品、品牌周边、定制商品等，需关联库存管理系统。
|
||
|
||
◦ 虚拟礼品：如电商平台优惠券、视频会员卡、话费充值卡等，可实现自动发放和核销。
|
||
|
||
◦ 自有产品：可将部分产品也纳入礼品库，允许会员使用积分直接兑换或部分抵扣货款。
|
||
|
||
• 礼品信息与规则：为每个礼品设置名称、图片、详细说明、所需积分值、兑换总量和单人限兑次数等。
|
||
|
||
• 上下架与库存管理：支持礼品的上架（开放兑换）和下架（暂停兑换）操作，并对实物礼品进行库存预警和同步管理。
|
||
|
||
2.2 积分商城运营业务流
|
||
|
||
• 前端展示与兑换：前端应打造清晰的积分商城页面，对礼品进行分类展示（如：热门兑换、虚拟卡券、实物大奖）。会员选择礼品并确认兑换后，系统核心业务逻辑是：校验积分余额是否充足 → 校验礼品库存及限兑规则 → 扣减对应积分 → 生成一条积分兑换订单。
|
||
|
||
• 后端管理与配置：Admin端负责商城的日常运营，包括礼品的CRUD（增删改查）、设置热门推荐、监控兑换数据、并根据兑换情况调整礼品策略以控制成本和提升吸引力。
|
||
|
||
3. 会员订单体系构建
|
||
|
||
此处的订单特指由积分消费行为产生的“积分兑换订单”，与传统电商的销售订单隔离，便于专门管理。
|
||
|
||
3.1 积分兑换订单生成
|
||
|
||
当会员在积分商城成功兑换礼品后，系统自动生成一条积分兑换订单。该订单应包含以下核心业务信息：
|
||
• 订单基本信息：订单号、生成时间、会员ID。
|
||
|
||
• 兑换内容：礼品ID、礼品名称、兑换数量、消耗积分总额。
|
||
|
||
• 订单状态：待处理、已发货（实物）、已发放（虚拟）、已完成、已取消。
|
||
|
||
3.2 订单履约与跟踪
|
||
|
||
• 虚拟礼品订单：系统应尽可能实现自动化。订单生成后，状态自动变为“已发放”，并通过站内信、短信或邮件等方式将卡密或链接发送给会员，随后订单可自动关闭或设置有效期为“已完成”。
|
||
|
||
• 实物礼品订单：订单状态为“待处理”。后台运营人员需手动处理：审核订单 -> 联系物流发货 -> 在后台录入发货单号 -> 将订单状态更新为“已发货”。系统可将发货信息同步给会员，并提供物流跟踪接口。
|
||
|
||
• 订单查询：会员可在前端查看自己所有的积分兑换订单及其状态。Admin端则具备全面的订单查询、筛选和导出功能，用于履约管理和数据分析。
|
||
|
||
希望这份基于您思路完善的业务说明能对您有所帮助。如果您对某个业务环节有更具体的想法或需要进一步展开，我们可以继续讨论。 |