在前后端开发联调前 的提交20260223
This commit is contained in:
406
docs/prd/小程序前后端.txt
Normal file
406
docs/prd/小程序前后端.txt
Normal file
@@ -0,0 +1,406 @@
|
||||
# 指数和用法
|
||||
均在DWS层实现,指数单独有INDEX标记
|
||||
## 指数参数新增
|
||||
|
||||
### 新增指数
|
||||
对全部客户,增加一个消费指数,依据:消费能力,消费频率,消费趋势,全部会员卡储值额度。
|
||||
|
||||
### 新增参数
|
||||
对全部客户,增加:30天/60天/90天内的 到店次数/消费总金额/次均消费额度/累计充值次数/累计充值金额。
|
||||
|
||||
### 新增统计
|
||||
统计每名助教带来的订单流水,订单流水-助教服务分成,助教时效流水,助教时效流水-助教服务分成。
|
||||
为了好说明,我们假设一个订单结构:
|
||||
- 台费 2 份:A台3小时 小计200元,B台4小时,小计400元。
|
||||
- 酒水食品:600元。
|
||||
- 助教 3 人 均为专业课:
|
||||
甲服务 A台 2个小时 小计320元,助教分成280元;
|
||||
乙服务 B台 1个小时 小计100元,助教分成80元;
|
||||
丙服务 A台 2小时,B台2小时 小计800元,助教分成750元;
|
||||
|
||||
#### 订单流水
|
||||
即助教参与的本订单的流水 = 200+400+600+320+100+800 = 2420元。也就是3个助教,每人+2820的订单流水。
|
||||
意义:知道助教的营业最大流水,潜力上限。
|
||||
|
||||
#### 订单流水-助教服务分成
|
||||
即助教参与的本订单的流水 - 助教费用提供的流水 = 2420-280-80-750 = 1310元。也就是3个助教,每人+1310。
|
||||
意义:知道助教为球房带来的毛利最大流水,潜力上限。
|
||||
另外,给这个统计,起一个合适的直观易懂的名字。
|
||||
|
||||
#### 助教时效流水
|
||||
每名助教折算其参与的服务时长,贡献的订单金额。
|
||||
计算:
|
||||
1、先计算台桌与助教服务时长的关系,如果助教服务时长总和大于台桌使用时间,则按照助教服务时长平分。如果小于台桌使用时间,则按比例折算台桌使用时间后,再按照助教服务时长平分。
|
||||
台桌A:甲丙助教共计服务4小时,大于台桌使用时长3小时,按4小时计算单价。
|
||||
台桌B:乙丙助教共计服务3小时,小于台桌使用时长4小时,按台桌使用3小时的比例计算。
|
||||
2、计算助教总时长:2+1+2+2 = 7小时
|
||||
3、台费比例(上述计算) + 助教各自服务流水 + 酒水食品按助教总时长与目标助教服务的比例均分。
|
||||
|
||||
助教甲 = 200/(2+2)*2 + 320 + 600/7*2 = 520元
|
||||
助教乙 = (400/4*3)/(1+2)*1 + 100 + 600/7*1 = 285.71元
|
||||
助教丙 = 200/(2+2)*2 + (400/4*3)/(1+2)*2 + 800 + 600/7*(2+2) = 1442.86元
|
||||
|
||||
意义:知道助教单人实力,为球房带来的最大流水,直观能力。
|
||||
另外,给这个统计,起一个合适的直观易懂的名字。
|
||||
|
||||
#### 助教时效流水-助教服务分成
|
||||
即每名助教在上述 助教时效流水 基础上,减去助教分成。
|
||||
计算:
|
||||
助教甲 = 520 - 280 = 240元
|
||||
助教乙 = 285.71 - 80 = 205.71元
|
||||
助教丙 = 1442.86 - 750 = 692.86元
|
||||
|
||||
意义:知道助教单人实力,为球房带来的最大毛利,直观能力。
|
||||
另外,给这个统计,起一个合适的直观易懂的名字。
|
||||
|
||||
#### 超休/打赏课
|
||||
超休/打赏课个算各的,我们假设一个订单结构:
|
||||
助教丁 打赏流水:190元 助教分走100元
|
||||
|
||||
助教丁 订单流水 = 190元
|
||||
助教丁 订单流水-助教服务分成 = 190-100 = 90元
|
||||
助教丁 助教时效流水 = 190 元
|
||||
助教丁 助教时效流水-助教服务分成 = 190-100=90 元
|
||||
|
||||
## 现有指数参数
|
||||
- NCI 新客转化指数(member)
|
||||
作用:新客欢迎建联与二访转化优先级排序、抑制高活跃避免打扰。
|
||||
原始数据:首访/单访、近14/60天到店次数、距上次到店/充值天数、消费与余额、充值未回访。
|
||||
可分解分项:welcome 子分、convert 子分、紧迫度、可救度、充值未回访压力/价值加成、免打扰窗口与 touch_multiplier、活跃抑制项。
|
||||
使用数据:客户行为数据(到店/充值/消费/余额)+“充值未回访”派生状态。
|
||||
算法:欢迎/转化双窗口评分→抑制→0–10 映射。
|
||||
|
||||
- WBI 老客挽回指数(member)
|
||||
作用:老客召回紧急程度与价值潜力综合排序,并给出建议回访时点。
|
||||
原始数据:距上次到店/充值天数、个人到店间隔分布(周期)、近14/60天降频、充值未回访、近180天消费与余额、分层NEW/OLD/STOP(高余额STOP例外)。
|
||||
可分解分项:分流标签、超期度(经验CDF及 alpha 变换)、降频项、充值未回访压力项、价值项、抑制/门控(hard_floor_days、recency_gate_days、slope_days)、额外输出 ideal_interval_days/ideal_next_visit_date。
|
||||
使用数据:客户到店/充值/消费/余额 + 历史到店间隔统计。
|
||||
算法:分流→组合评分→门控抑制→0–10 映射。
|
||||
|
||||
- RS 关系强度指数(pair:客户-助教)
|
||||
作用:判断助教与客户是否真正熟络、作为关系底座。
|
||||
原始数据:合并会话次数、会话时长、课型权重、会话距今天数、最近一次服务距今天数。
|
||||
可分解分项:f_score、d_score、base=weight_f*f_score+weight_d*d_score、时间衰减项、门控 gate=r_score^gate_alpha、rs_raw=base*gate。
|
||||
使用数据:客户-助教互动/服务日志(含课型权重、时长、时间戳)。
|
||||
算法:互动量衰减×最近接触门控→0–10 映射。
|
||||
|
||||
- OS 归属份额指数(pair:客户-助教)
|
||||
作用:客户归属分配、防多人撞单,输出主责/共管/公海/未分配。
|
||||
原始数据:同一客户在各助教上的 RS。
|
||||
可分解分项:过滤阈值 min_rs_raw_for_ownership、总量阈值 min_total_rs_raw、份额 os=rs_i/sum(rs_eligible)、os_rank、标签阈值 main_threshold/gap_threshold/comanage_threshold。
|
||||
使用数据:仅 RS 及阈值策略(不直接用行为明细)。
|
||||
算法:过滤→份额化→阈值打标。
|
||||
|
||||
- MS 动量/升温指数(pair:客户-助教)
|
||||
作用:识别近期升温/回流趋势,用于跟进紧急程度(不替代关系强度)。
|
||||
原始数据:短期加权频次 f_short、长期加权频次 f_long、课型权重 course_weight、时间衰减(不含时长、且不乘 RS)。
|
||||
可分解分项:ratio=f_short/f_long、ms_raw=max(0,log(ratio))(及短/长期频次本身)。
|
||||
使用数据:客户-助教频次序列(带课型权重、时间衰减)。
|
||||
算法:短期相对长期的正向增量→0–10 映射。
|
||||
|
||||
- ML 付费关联指数(pair:客户-助教)
|
||||
作用:判断由谁推动储值/增值更可能成功,严格使用人工归因。
|
||||
原始数据:人工台账归因充值金额、距今天数,来源 dws_ml_manual_order_alloc(Excel 导入)。
|
||||
可分解分项:对数压缩 log1p(amount/amount_base)、时间衰减累加、无台账则 ml_raw=0。
|
||||
使用数据:仅人工台账表(不使用自动归因/行为推断归因)。
|
||||
算法:金额log压缩+时间衰减累加→0–10 映射。
|
||||
|
||||
- 理想到店间隔天数 ideal_interval_days(days)
|
||||
作用:估计客户个人理想回访节奏,为召回门控与建议日期提供标尺。
|
||||
原始数据:历史到店日期序列→间隔天数分布(并结合近期是否降频/超期的派生信号)。
|
||||
可分解分项:个人周期统计量(如分位/均值/稳定度等实现相关)、配套输出 ideal_next_visit_date。
|
||||
使用数据:客户到店历史(时间戳/日期)+ 由此计算的间隔分布。
|
||||
算法:从个人历史间隔估计合理周期并推算下一次建议到店日期。
|
||||
|
||||
更详细的文档见项目文件。
|
||||
|
||||
## 场景说明
|
||||
### 客户任务分配相关
|
||||
- 新客首次到店/单访(NEW)
|
||||
主用指数为 NCI(welcome),如存在服务记录则辅用 RS/OS。分派时,NEW 客户按 NCI_welcome 从高到低分配给“新客官/当班”;若已出现服务记录,则优先分给 RS 最高的助教(更匹配既有服务关系)。
|
||||
|
||||
- 多助教共同服务、避免撞单
|
||||
主用指数为 OS,辅用 RS。先过滤 RS 过低的噪声配对;当 OS ≥ 阈值 时判定主责助教;OS 处于中间区间则进入共管机制;OS 较低则客户进入公海,避免多人重复跟进。
|
||||
|
||||
- 老客召回紧急程度
|
||||
OLD 客户召回(过门槛且可触达):主用指数为 WBI,辅用 OS/RS(选人),如涉及储值则辅用 ML。OLD 客户按 WBI 排序形成召回队列;优先派给 OS 主责助教;无明确归属的客户进入公海召回组统一处理。
|
||||
|
||||
- 跟进紧急程度
|
||||
近期明显升温/回流:主用指数为 MS,辅用 OS、RS。在各助教名下按 MS 排序生成任务优先级;派单仅给 OS 主责助教执行,减少多人同时触达造成干扰。
|
||||
|
||||
- 关系强但开始变冷(尚未进入老客召回)
|
||||
主用指数为 RS,辅用 MS。优先处理“RS 高 + 近期温度下降”的组合客户;执行仍由 OS 主责助教承接,保证动作一致性与归属稳定。
|
||||
|
||||
- 充值未回访(recharge_unconsumed=1):主用指数为 WBI(充值相关信号),辅用 ML、OS、RS。按 WBI 高者优先;由 ML 高 且 OS 合理 的助教主推,以提高转化与成交效率。
|
||||
|
||||
- 二访转化窗口(Need×Salvage 高)
|
||||
主用指数为 NCI(convert),辅用 OS/RS(用于选人)。NEW 客户按 NCI_convert 排序推进;触达频次由 NCI 的内置抑制机制控制,防止过度打扰。
|
||||
|
||||
- 增值推荐(由谁推)储值/包时/陪练等:
|
||||
主用指数为 ML,辅用 OS、RS、MS。先基于客户价值/意愿侧筛人(该部分通常已体现在 NCI/WBI 的价值项中),再用 ML 选择最适合的助教推进,并用 OS 明确责任归属。
|
||||
|
||||
- 触达控制(避免打扰)
|
||||
新客刚来过、仍活跃:主用指数为 NCI(内置抑制),无辅助指数。对触达任务队列,直接使用 NCI 的抑制结果 下调优先级或不派单,控制触达节奏与打扰风险。
|
||||
|
||||
- 门店管理/复盘—助教名下 RS 高但 WBI 也高(熟客仍流失):
|
||||
这里不是派单场景,而是“异常监控看板”。用 WBI + RS 作为主信号组合,辅用 OS、MS 辅助定位;通过组合筛选出需要复盘的助教与客户群,用于服务质量诊断与管理改进。
|
||||
|
||||
# 身份与登录
|
||||
- 登录与审核:如docs/h5_ui/pages/login.html页面所示,用户需要使用微信登录,若是新用户,则提交申请信息:docs/h5_ui/pages/apply.html。通过提交申请,根据审核情况有若干状态:
|
||||
审核中:docs/h5_ui/pages/reviewing.html;
|
||||
审核拒绝:docs/h5_ui/pages/no-permission.html;
|
||||
审核通过:根据指定店面,指定身份,进入相应页面。
|
||||
- 每个页面,都要根据登录用户身份权限,展示允许的数据和与其相关的关联内容。
|
||||
|
||||
## 用户与身份管理
|
||||
- 小程序的用户管理,身份配置,各种身份权限对应 的功能,需要集成到web-admin管理后台中。设计并实现轻量级用户管理功能:
|
||||
- 用户申请后,可指定是否通过。若选择通过,则通过前将其归属至哪个店(siteID,显示名称),并指定其身份。以及用户身份用户归属店面的编辑。
|
||||
- 可新建身份,编辑身份权限。身份对应的权限有:任务板块可见;看版板块可见以及下属财务板块、客户板块、助教板块可见;
|
||||
- 权限列表是固定的.
|
||||
|
||||
# 全局功能逻辑
|
||||
## 任务与完成任务的条件
|
||||
- 展示任务:见指数表格和用法说明,筛选每个助教今天的任务列表。这里你需要思考并再补充一些规则细节。比如任务逻辑是什么,我的想法是一旦助教和客人发生过服务,则就会出现在我的新客及我的常客列表中,作为销售线索;任务列表中会根据各种指数进行判断。
|
||||
- 所以,我觉得任务列表中的任务更像该客户的关系体现,完成任务只是标记一次服务,但展示上,一定是一个任务一个任务构成的。不知道我表达清楚没有,你认为是否合理?
|
||||
- 助教的召回任务完成:当有和该任务匹配的助教,为匹配的客户服务订单出现,则标记本次任务已完成。注意,无论此任务当前状态是高优先召回;优先召回;关系构建还是客户回访都算召回完成。但要记录此任务完成时的状态。
|
||||
- 助教的回访任务完成:当有客户回访任务时,该助教给该客户增加了一条备注,则通过AI应用6进行评分,低于5则不算完成。高于等于5记做完成。允许删除重新备注,只计算客户回访任务后的第一个备注。关于任务标签跳变:出现过客户回访后,2天内备注有效。2天内再次出现客户回访任务,则旧的回访任务被顶替。
|
||||
|
||||
## 某助教客源(客户所属助教)
|
||||
- 根据指数,确定某客户是哪个助教的客源。
|
||||
- 注意!客户可能属于多个助教,这是正常的。如果多个助教对某客户的RS没有很大的差距(50%)以上,则此客户属于多个助教。
|
||||
|
||||
## icon与表示:
|
||||
- 助教与客户成对的RS指数,会有4档爱心icon进行意会传达:
|
||||
💖:RS>8.5 | 🧡:RS>7 | 💛:RS>5 | 💙:RS<5
|
||||
- 助教 及 客户喜好项目的标签,通过房间消费得出:
|
||||
台球/黑八/追分:🎱;斯诺克:斯;麻将:🀅;团建 为 🎤;
|
||||
- 任务归属与放弃:在列表页,反应客户和助教关系的场景时,助教名称右侧会出现“跟”和“弃”的文字icon。跟代表此客户出现在了该助教的任务列表中,且任务类型为“高优先召回”,或“优先召回”。
|
||||
|
||||
## 当月/本周 的展示:
|
||||
- 当展示内容有当月/本周 等含有正在进行的状态,则对于财务金额,绩效工资等内容将出现"预估"字样。但注意!这个字样根据页面和样式不同,展示位置和展示方式均不同。要结合页面进行处理。
|
||||
|
||||
## 备注
|
||||
用户会对某客户增加各种各样的备注。
|
||||
对于特殊的内容,要进行字段归总和抽象。现在有生日这个信息,我们要记录这个生日信息是谁添加的,添加时间和生日的值。在后续数据更新时,主要不要覆盖这个记录,建议和通过API - ODS - DWD上来的值做隔离。
|
||||
|
||||
|
||||
# AI接口
|
||||
## 模型
|
||||
- 接入多个阿里云百炼的AI智能体应用:
|
||||
应用1 对话使用:需要和权限,即可见信息方面进行联动,做信息隔离限制。
|
||||
应用2 看版 - 财务 使用。
|
||||
应用3 客户全信息 分析使用。
|
||||
应用4 单助教对客户(任务视角) 任务及客户分析使用。
|
||||
应用5 单助教对客户(任务视角) 任务话术分析使用。
|
||||
应用6 完成客户回访,备注含金量的判断分析使用。
|
||||
|
||||
作为测试,先调通一个AI智能体应用:
|
||||
|
||||
文档参考:https://help.aliyun.com/zh/model-studio/first-api-call-to-qwen#e4cd73d544i3r
|
||||
Base URL:
|
||||
|
||||
华北2(北京):https://dashscope.aliyuncs.com/compatible-mode/v1
|
||||
|
||||
用来测试的应用ID: 见 .env → BAILIAN_TEST_APP_ID
|
||||
api-key: 见 .env → BAILIAN_API_KEY
|
||||
|
||||
变量名:传入当前用户ID。变量名:User_ID(通过 biz_params 中的 user_prompt_params 字段传值)
|
||||
|
||||
传入内容:当前页面的内容文本。提供开启对话的背景信息。
|
||||
|
||||
## 入口与信息
|
||||
部分页面右下角存在AI按钮,点击跳转chat.html页面进行对话。
|
||||
部分页面下方催在“问问助手”,点击跳转chat.html页面进行对话。
|
||||
会将本页的信息带到AI对话页面。
|
||||
在开启AI对话后,任何AI对话的开启,使用应用1 ,且要传值页面内容和当前用户信息。
|
||||
|
||||
## 通用
|
||||
- 智能体的信息发送和返回内容都要在数据库中保留。记录时间,ID,返回内容等接口返回的字段 和 发起人。有登录用户和系统,也就是说,系统发送的也要记录。
|
||||
- 使用业界较为成熟的方法,将每个页的内容转化成文本,方便AI阅读。用户会针对某些内容提问AI。
|
||||
- 应用1 一般对话,若从其他页面触发对话,会有一些页面上下文信息传入,开启AI对话。
|
||||
|
||||
## 财务
|
||||
- 应用2
|
||||
上传:当前页面中的信息(2个条件的交叉结果+环比) 。
|
||||
上传内容变量控制:智能分析,需要将几个时间筛选,分别进行更新。含本月/上月/本周/上周/前3个月 不含本月/本季度/上季度/最近6个月不含本月。
|
||||
返回变量的财务分析报告。
|
||||
|
||||
## 客户
|
||||
- 应用3 客户全信息
|
||||
上传:客户60天订单详情(***这里需要整理订单信息详情,你需要做一个文档,整理DWD层暂时只用feiqiu的连接器的DWD***),客户应该到店日期,当前与上次到店的间隔日期。
|
||||
返回:客户分析含标签,消费习惯分析。
|
||||
|
||||
|
||||
## 助教
|
||||
### 单独任务
|
||||
- 应用4
|
||||
上传:客户与我的关系相关60天订单详情(***同应用3的一样,只不过要筛选出与当前助教有关的订单***),客户应该到店日期,当前与上次到店的间隔日期。
|
||||
返回:客户和我的关系分析、任务建议、一句话总结、我的关系情况。
|
||||
|
||||
- 应用5
|
||||
上传:客户与我的关系相关订单详情(***同应用4***),应用3的返回内容,客户应该到店日期,当前与上次到店的间隔日期,客户和我的关系分析、任务建议。
|
||||
返回:5条话术参考。
|
||||
|
||||
### 回访信息含金量
|
||||
- 应用6
|
||||
上传:触发回访任务的备注,客户信息及全部备注。
|
||||
返回:1-10分数,以及评价。(6分为标准分,被别人备注过多的信息酌情扣分,无价值/低价值/时效性低/个性化弱/业务性若/私密性低等弱销售线索信息酌情扣分。反之高价值信息则酌情加分)
|
||||
|
||||
|
||||
|
||||
# 页面
|
||||
|
||||
## task-list.html
|
||||
- 展示当前任务(结合任务分配逻辑),按照以下顺序,优先级归类:
|
||||
优先级0:根据(WBI+NCI)指数展示列表。>7为高优先召回。>5为优先召回。
|
||||
优先级1:完成某任务后没有备注,且则标记tag客户回访。完成任务后加了备注,则跳过。
|
||||
优先级2:关系分数<6,则标记tag关系构建。
|
||||
|
||||
### 长按任务
|
||||
- 按住任务可弹出选项:置顶任务,放弃任务,问问AI助手。
|
||||
- 点击放弃任务弹出备注,必须输入放弃任务的原因,后端进行记录。放入已放弃列表。并将任务简述,替换为放弃原因。
|
||||
点击置顶任务,展示在置顶列表中。
|
||||
- 可以对已置顶任务取消置顶;可以对已放弃任务取消放弃。
|
||||
- AI接口:每个任务,将任务详情页信息带给AI。跳转到chat.html中。
|
||||
|
||||
|
||||
### 绩效计算
|
||||
通过 当前用户的门店,助教级别,按照DWS符合的绩效规则,计算当前月绩效、跳档和工资核算。展示相关数据。
|
||||
此页面展示的所有数据均为折算后的数据。
|
||||
|
||||
到达XXX即得YYY
|
||||
XXX为每个档位跳档线的时长。
|
||||
YYY为max(跳档线满足后前后的差值最小值,当前助教实际跳档后获得的差值)。
|
||||
跳档线满足后前后的差值最小值(没有超休打赏激励):
|
||||
Tier0 → Tier1:120*(28-18)= 1200元
|
||||
Tier1 → Tier2:150*(18-13)= 750元
|
||||
Tier2 → Tier3:180*(13-10)= 540元
|
||||
Tier3 → Tier4:210*(10-8)= 420元
|
||||
|
||||
举例:
|
||||
助教A 普通课50小时 打赏课10小时。
|
||||
则 50*(28-18)+10*190*(0.5-0.4)=690
|
||||
max(1200,690)=1200
|
||||
|
||||
助教B 普通课130小时 打赏课10小时。
|
||||
则 130*(18-13)+15*190*(0.4-0.35)= 792.5
|
||||
max(750,792.5)=792.5
|
||||
|
||||
|
||||
## performance.html
|
||||
- 收入与业绩档位在DWS(没有的话DWD)中读出,展示。
|
||||
- 本月/上月服务记录明细列出有我的所有服务课程,按照由近及远的时间顺序排列,从DWS(没有的话DWD)中获取。需要处理按天的的归总整合数据。
|
||||
- 我的新客(首次服务过的客户在最近2月内,且服务总次数小于等于2),按照最后服务时间排列。
|
||||
- 我的常客 (2月内,服务次数最多的客户)。次数,小时数,我从其支付的助教费中,能拿到多少工资的合计。
|
||||
- 服务明细:需要处理天/月的归总整合数据。展示每次服务的详情和收入/预估收入。
|
||||
|
||||
|
||||
## performance-records.html
|
||||
- 按照页面选择的口径,展示口径范围内全部业绩。
|
||||
- 需要处理天/月的归总整合数据。
|
||||
|
||||
### 每条业绩展示内容
|
||||
记录时间:结账时间。
|
||||
课程类型:基础课/包厢课/打赏课
|
||||
台桌/房间:如果是没有台桌房间的打赏课 则显示 “打赏”
|
||||
会员昵称:如果有则显示。
|
||||
开始时间:课程开始时间。
|
||||
结束时间:课程结束时间。
|
||||
业绩分钟:展示业绩分钟,如果有定档折算惩罚,则括号中展示。格式:120分钟(定档折算30分钟)。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## board-finance.html
|
||||
- AI接口:对于当前页面中的信息,智能分析,需要将几个时间筛选,分别进行更新。含本月/上月/本周/上周/前3个月 不含本月/本季度/上季度/最近6个月不含本月。
|
||||
- 需要对各个时间区域和各个项目区域以及环比进行交叉条件数据读取的优化,可以考虑DWS层进行数据快照。
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## board-finance.html
|
||||
- AI接口:展示当前筛选项,财务的AI分析。
|
||||
- 筛选:展示当前2组筛选的交集结果。选择了除全部区域以外的选项,则预收资产板块消失。收入结构去掉非筛选的区域。
|
||||
|
||||
## board-customer.html
|
||||
- 每个筛选维度,都展示不同内容。列表展示前100名。
|
||||
- 维度筛选更新,按顺序:最应召回(默认),最大消费潜力,最高余额,最近充值,最高消费 近60天,最频繁 近60天,最近到店,最专一
|
||||
- 维度筛选:
|
||||
最应召回:取客户召回指数,由高到低排列。
|
||||
最大消费潜力:通过统计 注册用户日期 最近30天充值与金额(高权重) 最近30、10天消费金额总和(高权重) 最近30天消费频率变化 这几个指标单独或权重加成,分析出每个客户的消费潜力。需要符合经营直觉,科学合理。
|
||||
最高消费 最近60天:统计每个客户最近60天的所有消费,从高到底排列。
|
||||
最高余额:统计最近当前,每个客户的余额(客户名下所有卡的余额),从高到底排列。
|
||||
最频繁 近60天:统计每个客户60天内到店的总天数,从高到底排列。
|
||||
最近到店:统计每个客户到店的时间,从近到远。
|
||||
最专一:统计每个客户对全部助教的亲密度,并取最大值,由高到低排列。
|
||||
- 类型筛选:加上选项中台费包厢流水的过滤。
|
||||
- 筛选互斥:
|
||||
最专一默认类型筛选为不限,且不能修改。
|
||||
- 需要对各个时间区域和各个项目区域以及环比进行交叉条件数据读取的优化,可以考虑DWS层进行数据快照。
|
||||
|
||||
|
||||
## board-coach.html
|
||||
展示以下选项的交集结果
|
||||
- 需要对各个时间区域和各个项目区域以及环比进行交叉条件数据读取的优化,可以考虑DWS层进行数据快照。
|
||||
|
||||
### 维度筛选
|
||||
- 筛选条件:定档业绩最高,定档业绩最低,工资最高,工资最低,高客源储值额最高,任务完成最多。
|
||||
- 业绩是定档业绩
|
||||
- 工资是核算后的工资
|
||||
- 高客源储值:统计助教 关系值>2的 全部客户的全部会员卡储值额,按照会员卡储值总额从高到到底排列。
|
||||
- 任务完成最多:统计周期内每个助教完成任务数量。
|
||||
- 客源储值:统计每个助教关系大于3的客户,每个客户的所有卡金额合计。
|
||||
|
||||
|
||||
|
||||
### 项目筛选
|
||||
- 按项目类型分:全部,中🎱,斯诺克,麻将,团建。
|
||||
|
||||
### 日期维度筛选
|
||||
- 按日期间隔分:本月,上月,本周,上周,前3个月不含本月,本季度,上季度,最近6个月不含本月。
|
||||
|
||||
|
||||
## coach-detail.html
|
||||
- 客户数:RS > 2的 客户数量。
|
||||
- 工龄:入职时间到当前的时间的年数。
|
||||
- 点击备注按钮,支持查看此助教为该客户做的备注。
|
||||
|
||||
## customer-detail.html
|
||||
### 消费记录
|
||||
每条样式分为2种:
|
||||
- dwd_settlement_head 的 settle_type 为 台桌结账的,下沉到table_fee_log,因为有的订单包含多个房间台桌。每条记录是该台费详情,展示关联/统计项,台桌关联总金额需要汇总。
|
||||
- dwd_settlement_head 的 settle_type 为 商城订单 的,每条记录含:助教列表(助教花名级别,课程类型,服务时长(若有绩效折算,则展示“定档绩效:XXX小时”),支付的金额,食品酒水总金额。
|
||||
- 金额为0的项,不展示。正价金额,(若有团购,或折扣,展示实付金额)
|
||||
- 总金额只在消费条目>1时出现。
|
||||
|
||||
|
||||
|
||||
## task-detail.html
|
||||
近期服务记录 时间和小时 是课程的时间和持续时长。
|
||||
备注:点击弹出备注输入窗口,让客户输入。提交按钮文案“提交”。提交后进行记录。
|
||||
|
||||
|
||||
近期服务记录 时间和小时 是课程的时间和持续时长。
|
||||
|
||||
|
||||
|
||||
## customer-service-records.html
|
||||
服务记录 时间和小时 是课程的时间和持续时长。
|
||||
|
||||
|
||||
## chat.html
|
||||
展示进入的来源。(你帮我梳理下所有可能进入AI的入口,并帮我定义来源展示的title和基本信息)。
|
||||
与正常IM或AI对话交互一样的交互操作。AI回复支持流式展示。
|
||||
|
||||
## notes.html
|
||||
支持删除,需二次校验。
|
||||
|
||||
## chat-history.html
|
||||
|
||||
|
||||
|
||||
## 管理后台
|
||||
## Excel数据上传
|
||||
Reference in New Issue
Block a user