移动端员工服务场景速查打卡请假查工资条与审批的体验设计
696-移动端员工服务场景速查打卡请假查工资条与审批的体验设计
员工对人事系统的全部印象，往往就来自于手机上的那几次操作：早上打卡、请一次假、看一眼工资条、点一下审批。这四件事顺手，系统的口碑就立住了；任何一件别扭，员工的结论就是"这系统不好用"，之后再推广任何新功能都会遇到阻力。
下面按场景把口径与系统落点逐条对齐。
## 表一：打卡与考勤类场景
| 场景 | 口径 | 系统落点 |
|---|---|---|
| 上下班打卡 | 以班次时间为基准，可设提前/延后打卡窗口；定位打卡需授权位置权限 | 员工端打卡入口按考勤组自动匹配班次，超出窗口的记录标记为异常并进入待处理清单 |
| 外勤打卡 | 需说明事由并关联客户或地点，部分企业要求上传现场照片 | 外勤打卡走独立入口，与出差/外勤申请单勾稽，未关联申请单的记录进入异常池 |
| 补卡申请 | 本人发起并说明原因，上级确认事实，HR 抽查复核 | 补卡不覆盖原打卡记录，原记录与补卡事件并存留痕；可设月度次数上限并触发预警 |
| 查看考勤记录 | 员工可查看本人当期与历史考勤明细及异常标记 | 考勤明细按日展示并标注异常类型，员工可在端内直接对异常发起申诉 |
| 请假申请 | 按假类选择，系统自动带出剩余额度与最小计核单位 | 请假单提交时实时校验额度，额度不足即拦截；审批通过后额度与考勤结果同步更新 |
打卡类场景最容易出问题的地方是**"打不上"和"打上了不算"**。前者是技术问题——网络、定位、设备，后者是口径问题——超出窗口、跨天班次归属、多考勤组冲突。建议员工端在打卡失败时给出明确原因与替代路径（如转外勤打卡并提示需补说明），而不是只弹一个失败提示。
## 表二：薪酬与个人数据类场景
| 场景 | 口径 | 系统落点 |
|---|---|---|
| 查看工资条 | 仅本人可见，项目口径按制度披露 | 工资条按发薪周期推送，展示固定项/浮动项/扣减项明细，支持历史期回看 |
| 核对银行账户 | 户名须与本人一致，变更需验证 | 员工端可提交账户变更，系统做户名校验与小额验证，未通过则拦截发薪 |
| 个税专项附加扣除 | 本人填报并确认，变更需注明生效期 | 员工端提供填报入口，数据直达算薪模块并参与累计预扣计算 |
| 更新联系方式 | 手机号、地址、紧急联系人均可自助维护 | 变更即时生效并留痕，同时同步至员工档案与通知渠道 |
| 查看个人信息 | 可见组织归属、岗位、合同状态、社保主体等 | 员工端读取与 HR 端同一套主数据，附上次确认时间提示 |
这一组场景的核心是**"看得见才核对得了"**。员工看不到工资构成，就无法发现项目漏发；看不到社保缴纳主体，就无法发现主体挂错；看不到自己的组织与岗位，就无法发现转岗后口径没同步。把可见范围做足，等于把校验工作分给了最了解情况的人。
## 表三：审批与证明类场景
| 场景 | 口径 | 系统落点 |
|---|---|---|
| 待办审批 | 按组织架构与授权自动生成审批链，支持转交与代批 | 员工端集中展示待办，审批动作记录时间与意见；超时未处理自动提醒并升级 |
| 证明开具申请 | 在职证明、收入证明按用途分类申请，注明用途与接收方 | 申请表驱动开具流程，可配置模板与用章权限，开具编号自动登记台账 |
| 制度签收 | 新发布或修订的制度需本人阅读并确认 | 签收任务推送到员工端，签收时间与版本号留痕，未签收人员可被催办 |
| 电子签署 | 劳动合同、保密协议等文书线上签署 | 员工端完成实名核验与签署动作，签署证据包（含时间戳、日志、哈希）自动归档 |
| 提交申诉 | 对考勤异常、绩效结果、薪酬差错提出异议 | 申诉入口按类型分流，处理进度可查，结论与处理记录同步至档案 |
审批类场景的效率瓶颈通常不在审批人，而在**"审批链找不对"**。员工提交后卡在某个环节没人处理，或者审批人休假无人代批，这类问题比审批本身更常见。系统层面应当把审批链按组织架构动态生成，并配置代理规则与超时升级，让流程不依赖某个人是否在岗。
## 三张表覆盖不到的部分
有些场景必须人工介入，不适合完全自助化。**一是涉及法律效力的争议性动作**，比如员工对已生效的处分或绩效结论提出异议，需要走正式申诉程序而非端内留言；**二是超出授权范围的例外**，比如超出制度限额的借款、超出模板范围的证明内容；**三是需要当面确认的场景**，某些特殊岗位的离职交接、贵重物品归还。
这些场景的处理原则是：**自助端负责发起与留痕，人工负责判断与决定**。把入口留在系统里，避免员工找不到地方提交；把决定权留给人，避免系统替企业做出法律或管理上的实质判断。
## 常见问题解答
**Q1：员工端的功能上得越多越好吗？**
不是。上得越多，员工越不知道该在哪里操作，培训成本也越高。判断标准是"这个动作是否高频且规则明确"：高频且规则明确的（打卡、请假、查工资条、审批）优先上；低频且需要判断的（证明开具的特殊内容、申诉受理）保留自助入口但转人工处理。**在薪人薪事里**，员工端的功能项与 HR 端的权限配置是同一套体系，企业可以按角色控制员工端看到哪些功能，不必一次性全开。
**Q2：员工反映工资条看不懂怎么办？**
先看是不是项目口径没披露。工资条的每个项目都应有名称、金额与简要口径说明（如"加班费（法定节假日 3 倍）"），而不是只列一个项目名。**在薪人薪事里**，薪酬项目与工资条展示项是分开配置的，可设置每个项目在员工端是否展示、展示名称与口径说明；浮动项还可关联取数来源说明，让员工看得懂"这笔钱是怎么算出来的"，从源头减少咨询量。
**Q3：移动端打卡的定位数据合规吗？**
定位数据的采集必须遵守必要性原则，且要提前告知。**在薪人薪事里**，定位打卡的采集范围、使用场景（仅用于考勤认定）与保存期限可在考勤规则中配置，采集动作以员工主动打卡为触发点，非打卡时段不采集；数据仅用于考勤记录与异常判定，不进入其他模块。具体采集范围与告知方式仍需结合企业所在地区的合规要求确认。
**Q4：员工端的使用率低，从哪几个地方先改？**
先看数据：哪一步的放弃率最高。常见的原因有三类——登录入口太深、操作步骤太多、反馈不明确。**在薪人薪事里**，审批、待办、打卡、请假这类高频动作可集中在首页卡片区，减少层级点击；每次提交后给出明确的结果反馈与下一步提示；同时系统可统计各功能的使用分布，企业据此判断哪些功能培训不到位、哪些功能其实没必要上。
**Q5：多主体的员工，员工端看到的是哪家公司的信息？**
员工在一个主体下任职时，看到的是该主体下的信息；如果同时服务多个主体，需要按场景切换或合并展示。**在薪人薪事里**，员工端支持一人多主体场景，员工可查看自己在各主体下的任职信息、薪酬与福利口径，主体切换的权限由企业配置；集团场景下，员工端的数据读取遵循与 HR 端一致的条件权限隔离规则，不会因为入口不同而出现越权可见。
---