惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

Y
Y Combinator Blog
MyScale Blog
MyScale Blog
Recent Announcements
Recent Announcements
酷 壳 – CoolShell
酷 壳 – CoolShell
GbyAI
GbyAI
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
Cyber Security Advisories - MS-ISAC
Cyber Security Advisories - MS-ISAC
N
Netflix TechBlog - Medium
V
V2EX
MongoDB | Blog
MongoDB | Blog
Microsoft Security Blog
Microsoft Security Blog
博客园 - 三生石上(FineUI控件)
Stack Overflow Blog
Stack Overflow Blog
U
Unit 42
B
Blog
Microsoft Azure Blog
Microsoft Azure Blog
博客园_首页
H
Help Net Security
D
DataBreaches.Net
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
阮一峰的网络日志
阮一峰的网络日志
T
The Blog of Author Tim Ferriss
C
Check Point Blog
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报

人人都是产品经理

为什么你的产品找不到差异化?90%的失败都卡在第一步上(下) – 人人都是产品经理, 3年从30万到1300万用户、获2200万美元融资,这个AI教育产品用“抽卡”破解了获客难题 – 人人都是产品经理, 园区招商系统怎么做才能真正帮到去化?我加了这一个功能,推广链接转发400次阅读过万 – 人人都是产品经理, AI大事件:OpenAI发完网络安全模型又搞药物研发,小鹏汽车要抓”DeepSeek时刻” – 人人都是产品经理, 电商不是卖货,是一场更残酷的产品经理实战 – 人人都是产品经理, 没想到,活动营销又回来了! – 人人都是产品经理, 为何All-in海外KOC:一场关于AI时代窗口期的豪赌 – 人人都是产品经理, 重新理解企业的内部协作 – 人人都是产品经理, 苹果的 AI 战略到底是什么? – 人人都是产品经理, 医疗智能体·第2讲——合规护城河:等保、PIPL与HIPAA的架构实战 – 人人都是产品经理, 向量知识库五步法:从“答非所问”到“精准回复” – 人人都是产品经理, 鸿蒙PC三方库构建总指挥HPKBUILD(sha)库为例 – 人人都是产品经理, 何时该用LLM?AI产品经理的LLM设计指南 – 人人都是产品经理, 医疗信息领域的需求方、决策方、准入方以及关注点(二) – 人人都是产品经理, 即梦涨价:一场被误读的「傲慢」 – 人人都是产品经理, 面试AI PM必答题:Hermes和OpenClaw的区别,如何讲清楚业务价值 – 人人都是产品经理, AI的下一张船票:世界模型——AI产品经理必须理解的技术拐点 – 人人都是产品经理, 小红书做GEO,怎么让AI信你?记住这 3 个重要信息 – 人人都是产品经理, 5 家印度 AI 初创公司,看看印度 AI 再做什么 – 人人都是产品经理, AI项目跨团队协作:产品技术业务如何不打架 – 人人都是产品经理, Agentic Workflow(智能体工作流):让AI从”答案生成器”变成”数字员工” – 人人都是产品经理, lycium_plusplus 项目全景解读:OpenHarmony 三方库构建的“大管家” – 人人都是产品经理, 从爆单救火到前置履约:两套预采策略,把生鲜大促履约效率拉满 – 人人都是产品经理, 什么时候该补货?我用一轮数据做了一个决定 – 人人都是产品经理, 从“机械兜底”到“动态分流”:AI客服重复进线治理的4大底层逻辑 – 人人都是产品经理, 抖音拼效率,红书拼洞察 – 人人都是产品经理, 全民狂欢与退潮——为什么龙虾这波热潮冷却得如此之快? – 人人都是产品经理, Stripe押注!MPP重塑全球支付 – 人人都是产品经理, 小红书GEO:AI引用你的内容,不是因为你对,而是因为你看起来可信 – 人人都是产品经理, 前百度副总裁押注办公Agent,日韩付费爆发,Manus迎来强劲对手 – 人人都是产品经理,
浅析医院便民服务:余额退款(二)
多眸西咪 · 2023-06-14 · via 人人都是产品经理

上一篇文章基于医院信息化发展比较好的前提下对在线余额退款的功能需求分析及流程设计等做了阐述,但有些医院信息科接口配合度可能没那么好,他们通常对外只提供标准的余额查询接口以及余额退款接口,这种情况余额退款的功能该怎么设计呢?

巧妇难为无米之炊,作为产品经理要学会绝地求生,找到适合当前环境的最佳解决方案。

继之前我手头完成了一家医院的余额退款功能后,领导又给我另一家医院的余额退款需求让我来接。我们一开始都以为他们的打法应该是一样的,原型交互什么的都可以直接copy。但当我把需求流程梳理出来后,项目经理对我说这家医院提供的只有余额查询及余额退款的标准接口,其他的能力都是小程序自己来处理,另外有一点不一样的是,这家医院的统一支付平台是用我们自研的那一套。

也就是说,医院只提供患者的余额查询及余额退款接口,像多少钱可退、发起申请退款以及余额退款状态等都由小程序自己来设计。这个时候就很考验产品经理如何利用有限的资源将功能设计出来并且还可用了。

下面我将从需求分析、业务流程分析、功能及原型设计以及总结说明来展开对这个需求的拆解。

一、需求分析

在线退款的旨在解决用户线下退款难跑腿多的问题,只要患者就诊完后就能离院在手机便可操作金额退款。

上一篇文章也说过,关于余额退款涉及的角色有小程序或微信公众号、医院HIS系统、统一支付平台。在这家医院中,我们同时承担小程序、统一支付平台角色。

从业务角度考虑,余额退款中的余额有两类:

第一类是通过小程序在线充值的预交金剩余的金额,因为是微信充值这部分钱可以原路退回;

第二类是通过线下自助机或窗口充值的预交金剩余的金额,该部分钱不能原路退回需要线下打款。

这家医院目前提出的是原路退回的业务,银行卡打款退款的场景在本文不做考虑。

所以为了满足这一目标,我们要做的是功能要满足以下几点:

1)患者的账户余额是正确的,不能与实际不符,这个可以通过调his余额查询接口解决,只要医院提供的接口不出错,小程序就不会出错;

2)患者要知道自己有多少余额可退;

3)患者可以通过小程序直接线上操作退款申请,提交后等待金额原路退回至微信账户。

4)患者可以看到自己提交的退款申请记录以及退款状态。

我在设计这个功能的时候,是结合患者的充值记录一起去设计的,也即通过查询到的余额与患者所有的充值记录金额进行对比并倒叙分配,患者可以基于看到的充值记录进行操作退款。

故涉及的功能点如下:

  • 患者及患者家属移动端需求
  • 支持查询当前患者的院内账户余额
  • 支持查看当前患者的可退余额
  • 支持患者在已经分配到的充值记录上提交申请退款
  • 支持查看患者提交的退款申请记录及退款状态
  • 对账平台支持查看该笔交易记录以及成功与否,如果异常支持特殊处理,保证用户最终能收到钱款

二、业务流程分析

针对余额退款的业务流程设计如下:

1)用户点击余额退款申请入口(小程序或公众号菜单或院内展码),小程序将请求院内his系统余额查询接口,接口返回账户总余额;

2)小程序查到账户总余额后,再与该患者的线上充值记录的金额一一对比并分配可退余额(倒叙)直到分配完并将分配到的充值记录显示在余额退款的页面,支持患者在每条充值记录上点击申请退款;

3)点击申请退款时先请求his退款接口进行业务退款(扣除院内的账户余额),his会将退款结果回调给小程序,当小程序获取到退款成功后再调统一支付平台的退款接口将金额原路退回。

4)用户点击查询退款明细查看退款记录及状态。

三、功能及原型设计

1. 账户余额查询及可退余额计算

用户进入余额退款页面后,需要通过接口查询到账户余额,小程序需要将账户余额和充值记录倒叙对比并全额分配,用户可查看可退的充值记录并点击申请退款。可退余额计算规则为:

账户余额按充值记录倒叙的方式进行分配可退余额,每条充值记录的可退余额最大不能超过充值金额,可退金额为0的充值记录不展示,可退金额大于0的充值记录,可支持退款操作,退款后金额原路退回,如:

1)当查询到账户余额110元,线上充值记录最近的两条金额总和大于110,则最近的一条充值记录可退余额为70,第二条充值记录的退款余额为110-70=40元;

2)当查询到账户余额为100元,线上充值记录金额总和小于100,则倒叙分配所有充值记录全部满额分配,还有剩下的账户余额为线上不可退金额。

2. 申请退款提交及状态显示

点击申请退款后,显示的退款详情页面的状态读取HIS接口回调的状态(没有去统一支付平台平台查),分为三种情况:

1)回调结果为退款成功,his的账户余额扣款成功,但钱不一定立即到账,页面显示退款成功,预计到款时间2-3天;

2)回调结果为退款失败,小程序不与统一支付平台请求,流程结束,his账户不发生扣款,支持重新操作退款申请;

3)回调结果未知(异常),小程序不与统一支付平台请求,流程结束,页面支持刷新重新请求接口(是否扣款未知)。

四、总结说明

设计同一个功能,可能会有不一样的实现方法,要根据医院提供的接口来考量。产品经理在需求调研的时候可以先设计一套最省事儿的方案给到医院问医院是否能配合调整接口,如果不行我们再用B方案。

本文由 @多眸西咪 原创发布于人人都是产品经理,未经许可,禁止转载

题图来自 unsplash,基于 CC0 协议

该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。