招聘是很多企业的第一处"数据孤岛"：简历在招聘网站，面试安排在企业微信，入职资料在 HR 的个人文件夹里。一件事散在三个地方，谁也不知道进度卡在哪一环。
Inkwell AI 构建器能做的，是把"招聘到入职"这条线建成一个业务模块：一个候选人一条记录，从投递到入职的每一步都挂在这条记录下面——PC 上看整体进度，手机上做各自手上的动作。
痛点：招聘进度靠问，入职资料靠催
先说几个常见场景：
- 重复联系：同一个候选人被两位 HR 各加了一次微信，因为简历分散在两个人手里。
- 面试断线：约了面试，面试官的评价事后口头说一下，没人记录，下次复盘没有依据。
- 入职拖沓：录用通知发出去了，资料靠一遍遍催，证件照片、银行卡号散在聊天记录里。
- 到岗没数：明天到底几个人来报到、分到哪个部门，HR 前一天还在打电话确认。
这些问题的共同点不是"HR 不努力"，而是缺少一个以候选人为单位的记录载体。下面讲这个载体怎么建。## 数据怎么建：五张表，一条主线
把"招聘到入职"拆成五张表，一张主表加四张从表：
| 表 | 存什么 | 关键字段 |
|---|---|---|
| 岗位需求 | 用人部门要招什么人 | 岗位名称、招聘人数、期望到岗时间、状态 |
| 候选人 | 每个应聘者一行 | 姓名、手机号、来源渠道、应聘岗位、当前阶段 |
| 面试记录 | 每场面试一行 | 面试轮次、面试官、面试时间、评价、结果 |
| 录用通知 | 每条录用一行 | 候选人、拟聘岗位、发出日期、状态 |
| 入职登记 | 每人一份入职资料 | 证件、银行卡、紧急联系人、入职日期、所属部门 |
几个值得花心思的设计：
- 候选人表是主线：面试记录、录用通知、入职登记都通过"候选人"字段挂上去，一对多。打开一个候选人，就能拉出他的完整过程。
- 应聘岗位用"引用"：录候选人时从岗位需求里选，不手打岗位名——否则"销售""销售代表""销售岗"会变成三个不同岗位，后面统计就废了。
- 阶段用数据字典管：待筛选 / 已约面 / 面试中 / 待录用 / 已录用 / 已入职 / 已淘汰。枚举集中维护，看板和筛选都读它，改一处全局生效。
- 敏感字段单独收口：证件号、银行卡号设为敏感字段，只有 HR 角色可见；用人部门只能看到应聘信息与面试结论。
- 部门用部门树引用：入职时从组织架构里选，而不是手写部门名称。
命名从第一天就要统一：全表统一用"手机号"，不要一会儿"电话"、一会儿"联系方式"。字段口径不一致，后面每张报表都要做一次数据清洗。## 页面怎么用：PC 上看全局，表单里做事
1. 招聘看板页
按阶段分组显示候选人，一眼看出"卡在面试环节的有几个、待录用的有几个"。支持按岗位、部门、来源渠道筛选；更新阶段后卡片自动归到新的分组，不用手动搬家。
2. 候选人详情页
一个页面放全部信息：基本信息、简历附件、面试记录列表、录用通知、入职登记。HR 不必在几张表之间来回跳。
3. 面试评价表单
面试官选面试轮次、填结论与评语后提交，候选人的阶段可配置为自动推进一格。评价一经提交，普通角色只能补充、不能改写，保证面评的真实性。
4. 入职登记表单
从待入职名单里选人，系统自动带出应聘岗位与拟入部门，HR 再补证件、银行卡、紧急联系人。提交后生成员工档案记录，与后续的转正、调岗共用同一份档案。
5. 我的待办
面试官看到"待评价"，HR 看到"待审核资料"，用人部门看到"待确认录用"——每个人打开只看到属于自己的那几条。
移动端怎么配合：谁在现场，谁用手机
招聘这条线上的动作分散在不同角色手里，手机是主要入口：
- 面试官：手机上看当天面试安排，翻简历附件、填面试评价，面试完当场提交，不必回工位补录。
- HR：手机上审核入职资料、跟进待入职名单，录用审批在手机上也批得动。
- 用人部门主管：录用确认、转正申请在手机上点通过或退回。
- 新人：到岗当天用手机填入职登记，证件照片直接拍照上传，不用打印纸表。
PC 上搭好的页面会同步到移动端，数据是同一套——手机提交的面试评价，PC 看板上立刻能看到，不需要为手机单独做一版。## 审批与提醒怎么接上
- 录用审批：录用通知提交后进入审批流（用人部门负责人 → HR → 分管领导），全部通过才把候选人置为"已录用"；任一环节退回，都能改后重提。
- 入职资料复核：新人提交的资料由 HR 复核，有问题退回补充。
- 待办与到期提醒：入职日提醒、面试后待评价提醒、资料待复核提醒，用定时任务每天扫一遍，通过站内信推给对应的人。
- 操作留痕：谁改过候选人阶段、谁批的录用、谁看过敏感字段，操作日志里都留痕，招聘出现争议时能倒查。
上线前查什么
上线前按这六条自查一遍，能省掉大部分返工：
- 阶段枚举是否齐全、顺序对不对——少一个"待录用"，看板就会卡在上一步。
- 引用是否通——录候选人时能不能选到岗位需求，入职时能不能带出部门。
- 敏感字段权限——证件号、银行卡号是否只有 HR 可见，用人部门看不到。
- 审批是否有出口——被退回的单子能不能改后重提，别造成卡死的单据。
- 移动端实测——面试名单、面试评价、入职登记在手机上打开与提交都正常。
- 基础数据先建——部门树、岗位类别、来源渠道字典先录好，再录第一条候选人。
之后怎么延伸
这条线建好之后，顺着同一份数据往下走很自然：
- 渠道效果：按来源渠道统计到面与录用情况，看招聘投入花在哪个渠道更值。
- 人才库：淘汰的候选人转进人才库，下次招同类岗位时一键捞回。
- 员工全周期：入职之后的转正、调岗、调薪、离职，接着用同一份员工档案。
- 培训与证书：入职培训、岗位资格证到期，纳入同一套提醒体系。
招聘模块从来不是"要不要上系统"的问题，而是"这件事有没有一条能被看见的线"。Inkwell AI 构建器的作用，是让业务人员把这条线描述清楚，模块就能建出来——之后要做的，只是记录和跟进。