编辑导语：在经历了一次补卡申请事件后，本文作者对钉钉存在的问题进行了思考。
从产品角度对于“补卡申请”功能进行了研究，并且提出了针对问题的相应解决方案，希望大家在遇到一些产品问题时也可以多多进行思考。
年前，笔者某天加班太晚没有打卡，第二天进行了补卡申请，但是管理员比较忙一直没进行审批。
几天后，笔者忘了之前已经提交过补卡申请（状态还在审批中），因此又操作了一次补卡申请，系统却提示“超出可补卡时间”。
重点来了：笔者想起前几天已经提交过申请，只不过审批的状态是审批中，为什么提示超时不能补卡呢？难道补卡申请被管理员拒绝了？笔者又在OA审批确认了下，补卡申请的审批状态依然还是“审批中”。
笔者就疑惑了：因此以产品角度重新对于“补卡申请”这个功能进行了研究：用户提交补卡申请后（审批中）再次操作补卡时，超出管理员设置的可补卡时间：提示超时不能补卡，没有跳转至补卡申请详情页。
一、问题是否成立因此笔者设置同样的前置条件：用于对比“月汇总统计”和“考勤日历统计”在相同条件下操作【补卡申请】的情况，看看问题是否成立。
选择缺卡日（28号）已提交过补卡申请（状态：审批中）操作的时间一致，已超出设置可补卡时间（2天）1. 考勤日历统计用户提交过补卡申请（审批中），再次操作【补卡申请】时已超过可补卡时间：页面跳转至笔者之前填写过的“补卡申请详情”页面（审批中），具体见下方录屏gif图：2. 月汇总统计从月汇总这个入口点击进去统计页面，点击缺卡（1次）会显示具体的缺卡信息：“2021-01-28（星期四）18：00 丨 去处理”。
用户提交过补卡申请（审批中），点击【去处理】选择【补卡申请】时已超过可补卡时间：没有跳转至笔者之前填写过的申请详情页面（审批中），而是提示：超出可补卡时间，具体见下方录屏gif图：大家看到这里，是否觉得这个是钉钉业务流程上不合理的地方呢？基于同样前置条件下：一个界面中两个统计功能，用户操作“补卡申请”后却有两种结果：在考勤日历，操作【补卡申请】系统判断用户已经申请补卡——跳转至补卡申请详情页。
月汇总统计，操作【补卡申请】系统未判断用户已申请补卡——提示超出补卡时间。
二、问题分析先看官方说明：下图是钉钉提供的补卡申请操作流程及说明：由图可知：钉钉提供了两种补卡的方式：并没有从“月汇总统计申请补卡”这种方式。
为什么“月汇总统计”有补卡申请选项，但是钉钉官方却没有把这个方式告知给用户呢？在未超时情况下，用户可以从“月汇总统计”进行补卡申请，并且流程也是走得通的。
如果用户超时了，从“月汇总统计”补卡申请的流程就不能走通。
具体场景如下：“用户已申请过补卡（状态审批中），在月汇总统计界面再次操作（超出管理员设置的时间）没有跳转至补卡申请详情页，而是提示：超时不能补卡。
”为什么在月汇总统计界面，用户操作“补卡申请”系统仅判断是否符合管理员设置的时间内？如果用户已经申请过补卡，即使操作的时候超时了，不也应该跳转申请详情页吗？问题本质：月汇总统计和考勤日历对于处理缺卡的底层逻辑不同造成的，虽然月汇总统计也可以进行补卡申请，但是不仅只是针对补卡申请，还有其他申请类型。
1. 考勤日历统计数据是按日进行查询，用户选择某天就查询这天的数据进行展示；展示当天的考勤数据，并包含缺卡信息的细节信息（上班时间、打卡地点等）；系统会对缺卡情况做判断，因此在日历下方出现【补卡申请】的按钮，而不是四种申请类型。
在考勤日历，如果用户所选日期是缺卡状态并且满足管理员设置的时间内，在日历下方就会出现【补卡申请】按钮，因此系统会根据补卡申请状态进行页面跳转。
备注：以下是几种用户申请状态，操作【补卡申请】对应的页面跳转情况：未申请补卡，点击【补卡申请】跳转——补卡申请填写页面；已申请补卡，点击【补卡申请】跳转——补卡申请详情页面（状态审批中）；申请已通过，点击【补卡申请】跳转——补卡申请详情页面（状态已通过）；申请未通过，点击【补卡申请】跳转——补卡申请详情页面（状态未通过）；备注：目前钉钉并没有设置超时状态，以最后一个审批结束为完成，因此不存在超时情况。
2. 月汇总统计数据展示是按月查询数据的；展示各项数据的总计，缺卡信息不包含具体细节；对于缺卡处理，系统不做判断用户是要进行哪种操作（补卡、请假、出差、外出）。
月汇总统计对于缺卡处理：有四种申请类型，不只有补卡申请。
所以系统需要先判断用户申请时是否在设置的时间内，再根据申请状态做判断（页面跳转）。
如果超时了，即使申请状态是已申请（审批中）也不会跳转至申请详情页。
而考勤日历，日历下方出现【补卡申请】按钮即表示：系统已经判断是符合条件的。
因此只需要判断补卡申请的状态做相应的页面跳转即可。
如果超时了是不会出现【补卡申请】按钮的。
也就说不会出现月汇总统计那样的情况，也因此钉钉官方推荐的“申请补卡”方式入口是考勤日历。
感谢观看。

以上是笔者在使用过程中遇到的问题，并以产品角度分析后得出问题答案的过程。
本文由 @老绵 原创发布于人人都是产品经理，未经许可，禁止转载题图来自 Unsplash，基于 CC0 协议

（图片来源网络，侵删）