很多公司在钉钉里待久了都会冒出同一个问题：人都在钉钉打卡、审批、聊项目，那工时是不是也该在钉钉里自然算出来？
听上去顺理成章，做起来是另一回事。钉钉打卡知道某人今天几点上下班、加了几小时班，但不知道这一天他给哪个项目干了多少活；审批能让员工填「工时申请」，但导出的 Excel 拉不出像样的横向对比；项目群里聊得火热，工时却躺在每个人脑子里。
真正想用工时数据做事的公司——算项目成本、定外包结算、看团队负载、按客户算毛利这 4 件事——都绕不开同一个动作：在钉钉之外再补一层。而这一层用什么搭，直接决定你要花多少钱、拿到的数据有多准——便宜的几乎不花钱，贵的要砸十几万元做钉钉二开，整条成本曲线横跨从 0 元到十几万元这 1 个量级。
这篇文章把市面上能落地的 4 套钉钉工时方案、各自的真实成本和适用团队规模，一次给你拆清楚（文中所有费用均为行业公开区间，不针对任何具体厂商报价）。看完你就知道自己该选哪套、不用花冤枉钱。
一、钉钉自带的工时统计为什么不够用？
钉钉打卡数据无法直接换算成项目工时，原因只有一个：它算的是「考勤工时」而非「项目工时」，两者分属 2 个完全不同的数据维度，经常被混在一起讲。先把这个前提说清楚，后面 4 套方案的取舍才有判断依据。
考勤工时回答的是 3 个问题：员工今天在岗多久、加了几小时班、有没有迟到早退。这部分钉钉做得很扎实，HR 算工资 1 套数据就够用。
项目工时回答的是另一组问题：A 项目这个月烧了多少人天、张三本周花了多少时间在客户 B 上、这个交付包的实际人力成本是多少、外包工时按哪个口径结算。这 4 类问题钉钉自带的考勤模块都没法回答，因为它根本不知道「项目」这个维度。
管理者第一次想拉项目工时，会去翻钉钉审批的工时申请，发现每张单子是独立的：没法按项目聚合、没法跨月对比、没法和云效或 ERP 的项目编号对上，至少 3 个分析动作直接卡死。问题不是钉钉做得不好，而是要先分清自己要的是哪种工时。判断要不要在钉钉之外再补一层，先看这 2 类口径分别归谁用：
- 考勤工时口径：给 HR 算工资、算社保基数用，钉钉自带模块够用，不必额外花钱。
- 项目工时口径：给项目经理算成本、老板看人均产出、财务和客户对账用，这一层钉钉算不出来，下面 4 套方案才是真正要选的对象。
二、方案 A：钉钉审批表单做工时统计真的 0 元吗？
方案 A 的许可费确实是 0 元，但隐性成本是 HR 和项目经理每月清洗 Excel 的工时，团队过了 30 人这条线就会反超低代码许可费。具体做法很朴素：在钉钉里建一个「项目工时填报」自定义审批，员工每天或每周提交 1 张单子，字段是日期、项目、工作内容、投入小时数；流转给项目经理审批通过，数据沉淀在钉钉审批后台。
优势就一个字：零。零额外许可、零开发、零运维这 3 个零叠加，加上员工已经习惯在钉钉点同意，培训成本几乎可以忽略。
天花板卡在 3 个地方，逐条拆开：
- 导出只有 Excel：按项目、按人、按月做交叉分析得自己写公式，每月手工出 1 次报表就是一笔固定人力。
- 项目名称是手输文本：今天「客户 A 二期」明天「A 客户二期项目」，同一个项目可能裂成 3、4 种写法，分析前要花大力气清洗。
- 审批通过≠数据准确：自报告没有任何系统校验，导出表里一周填 60 小时、某项目一个月突然冒出 200 工时的异常值，全靠人工肉眼抓。
谁适合？同时满足 3 个条件的公司——团队 30 人以内、项目数量两位数以内、对工时只有「大概知道谁在忙什么」这种粗粒度需求。再大一点，边际成本会突然飙起来：飙的不是钉钉的钱，是 HR 和项目经理每月清洗 Excel 的那几个工时。
三、氚云 / 简道云低代码搭工时一年多少钱？
氚云、简道云这类低代码搭工时，50 人左右团队纯工时模块一年通常在几千元量级，扩成轻量 PMS 大概在万元上下（以下费用为行业公开区间，不针对任何具体报价）。它俩本质都是「在钉钉里嵌一个能自己设计表单和报表的轻量数据库」，是从方案 A 往上的第 2 档。
工时这个场景对低代码来说是教科书级别的甜区。建 1 张工时表单，把字段做成下拉（项目从主表关联、人员从钉钉通讯录同步、客户从客户主表关联），员工不再是手输文本——仅这 1 步就解决了方案 A 最大的脏数据问题。再配 1 张仪表盘按项目、按人、按月做透视，Excel 导出不再是分析起点，而是给老板和财务看的最终产物。
费用上分 2 档来算：50 人左右的团队纯工时模块一年几千元量级；顺便把项目立项、合同、客户也搬上去做成轻量 PMS，一年大概在万元上下。
边界有 2 个，到了规模就会撞上：
- 数据规模有上限：低代码报表引擎在几万行以内跑得飞快，到几十万行（三五年累积的工时明细）开始卡，复杂透视会超时。
- 外部系统双向打通弱：往钉钉推消息很顺，但要让工时自动同步进 ERP 做成本核算、按客户合同算分成，往往半接不接最难受。
某连锁餐饮总部就是这个画像（案例为开沿项目沉淀的脱敏体感，规模数字均为约数）：几十人的总部团队加几百号门店督导，工时主要算总部职能的项目投入和督导的巡店时长。上 1 个低代码表单加仪表盘，几千块一年，省下来的是 HR 主管每月底加班对工时的那两个晚上。
四、什么情况下值得花十几万做钉钉工时二开？
当工时要从「记录」升级成「经营数据」时，才值得花十几万元一次性开发加每年一两万元服务器维护去做钉钉工时二开（费用为行业公开区间）。这一层是基于钉钉 OpenAPI 自己搭 1 套工时中台：把钉钉当成「人和组织的数据源 + 用户入口」，工时业务逻辑放在自研系统里，整条链路拆成 4 步——通讯录通过 OpenAPI 同步过来；填报做成钉钉里的 H5 应用，员工点开就用；数据落到自己数据库，按项目、客户、合同、成本中心做多维建模；催报通过钉钉机器人推回去。这类自研工时中台正是开沿在做的企业管理软件定制开发的一种典型形态。
为什么有公司愿意花十几万元做这件事？因为到了某个规模，工时不再是「记录」，而是经营数据。判断要不要上方案 C，看是否命中下面这 5 个「工时即成本」的硬场景：
- 按项目实际人时反算客户毛利：哪个客户赚钱、哪个赔本要精确到人天。
- 和差旅、采购成本合并出项目利润表：财务要的是 1 张完整的项目损益。
- 给外包做月结对账：按统一工时口径结算，避免每月扯皮。
- 按工时驱动绩效奖金：产能直接挂钩分配，数据必须准。
- 实时同步给 ERP 项目模块：工时要进经营分析链路，不能停在填报。
这 5 类场景都涉及和其他系统的深度耦合，对数据准确性有硬要求，低代码的报表性能和外部双向打通会力不从心。
开沿自己就在这么用工时，以下是基于内部累计交付沉淀的真实做法。内部跑双轨：研发在云效里关任务，工时跟着任务自动沉淀；交付和定制开发在自研的 azeroth 项目工时里按客户编号、合同号填报，月底直接出客户毛利表和员工产能表。两套数据每周对 1 次，差异超过阈值自动报到企业群里。作为一家做软件定制开发的公司，我们必须知道每一个客户、每一个合同到底烧了多少人，否则报价和续费完全靠拍脑袋。[^1]
成本上，方案 C 常见区间是十几万元一次性开发 + 每年一两万元服务器和维护，分摊到 3 年的 TCO（总拥有成本）月均也就几千块。但前提是公司里有人愿意长期运营——组织变了、项目类型变了、计费规则变了，它都得跟着改。没有持续运营，3 个月后填的人变少、数据准确率掉下来，再贵的中台也是摆设。
五、方案 D：云效 / PingCode 让项目工时自动产生，适合谁？
方案 D 最适合研发型团队，费用按用户数收，50 人团队一年大致在几千到一两万元区间（行业公开区间）。它的思路是不在钉钉侧做工时，而是直接用专业项目管理工具自带的工时模块——阿里云效、PingCode、Worktile、Teambition、Jira 这 5 类工具都属于这一档。
逻辑和前 3 套很不一样：不是「员工去填 1 张工时单」，而是「员工把任务做了，工时自然就有了」。任务关联人员、关联工时预算、关联实际投入这 3 个动作做完，工时就是任务管理的副产品。
这套方案在研发型团队里特别突出。工程师每天的工作本来就是开任务、推进度、关任务，多花 10 秒记一下投入，比每周末专门花半小时填工时单省得多——单次记录的时间成本相差近百倍。费用按用户数收：云效国内版有免费额度，PingCode 和 Worktile 大致每月每人几十到上百块，50 人团队一年几千到一两万元都有可能。
短板也明显，可以归到 2 点：
- 对非研发同学不友好：销售、行政、市场这些岗位的日常不是「关任务」的形态，硬塞进去最后大概率退化成方案 A。
- 覆盖面有边界：硬追求 1 套工具大一统反而填报率掉。
所以更现实的做法，是把方案 D 限定在研发、产品、设计这 3 类「天然按任务工作」的团队里，其他职能用 A 或 B 兜底。
六、4 套钉钉工时方案的真实成本怎么对比？
4 套钉钉工时方案的真实成本跨度从 0 元到十几万元：方案 A 许可 0 元、方案 B 一年几千到万元量级、方案 D 一年几千到两万元量级、方案 C 十几万元一次性加每年一两万元维护（以下区间均为行业公开口径，不针对任何具体报价）。下面这张表把 4 套方案的一次性投入、年度许可、二开集成、长期维护、适合规模 5 个维度并排放好，对照着看更清楚。
| 方案 | 一次性投入 | 年度许可 | 二开/集成 | 长期维护 | 适合规模 |
|---|---|---|---|---|---|
| A：钉钉审批 + 导出 | 0 | 0 | 0 | HR 每月几小时清洗 | 30 人以下 |
| B：氚云/简道云 | 1-2 人周搭建 | 几千到万元量级 | 基础接口够用 | 半人月/年 | 30-150 人 |
| C：OpenAPI + 自研中台 | 几万到十几万元 | 服务器一两万元/年 | 视集成深度 | 建议有专岗 | 100 人以上、工时即成本 |
| D：云效/PingCode | 0-1 人周接入 | 几千到两万元量级 | 视报表需求 | 工具自有团队 | 研发型团队优先 |
这张表外还有 3 笔容易被忽略的隐性成本，往往才是真正拉开总账的地方：
- 方案 A 的「免费」是拿时间换的：用 HR 和项目经理每月几小时的清洗时间折算，团队大了之后会反超 B 的几千到万元许可费。
- 方案 C 的开发费分摊后没那么吓人：十几万元摊到 3 到 5 年，月均也就几千块，关键变量是有没有人长期维护。
- 方案 D 的许可费按人头跳档：单价看着便宜，一旦给非研发部门也开账号，单价乘以人数会让账单跳 1 档。
七、钉钉工时方案到底怎么选？3 个问题问完就定
钉钉工时方案的选型只需问 3 个问题，问完基本就能锁定 A、B、C、D 中的 1 套，不必逐个试错。这 3 个问题按下面的判断顺序走：
- 第一，工时数据的下游是谁在用？ 只是 HR 看个大概、老板偶尔关心，方案 A 够；项目经理每周复盘、财务月底算成本、销售给客户出对账单，至少要走 B；工时要进 ERP、进经营分析、要驱动绩效和客户毛利核算，基本就是 C。
- 第二，团队是研发型还是混合型？ 纯研发主导，方案 D 几乎是天选；混合型团队（研发+交付+销售+职能 4 类岗位）就老老实实承认分层——研发走 D、交付和项目走 B 或 C、职能岗用 A 兜底，不要追求 1 套大一统。[^2]
- 第三，公司有没有人愿意长期养这套系统？ 这是方案 C 唯一的硬门槛。十几万元的开发费不可怕，可怕的是上线半年没人维护，新业务全部塞进「其他项目」这个垃圾桶。找不到 1 个愿意把工时中台当作分内事的人，宁可不上 C，先用 B 顶住。
工时这件事最大的误区，是把它当成工具问题。工具只是承载，真正决定这份数据值不值钱的，是公司有没有想清楚「我们到底要拿工时干嘛」这 1 个问题。想清楚了，方案 A 也能跑出洞察；没想清楚，方案 C 也只是 1 个更贵的填报系统。开沿在帮客户落地工时方案时，第一件事不是问要用哪个工具，而是先问 1 句：你打算拿这份数据做哪个决策？把这个问题答清楚，4 套方案的选择会自己浮出来。
数据口径理顺之后，再往上一步就是让它自己跑起来——比如用 AI Agent 自动盯异常工时、月底自动汇成经营报表，工时就从「填了存着」变成真能驱动决策的经营数据。想看不同规模的公司怎么把工时和经营数据打通，可以翻翻我们的客户案例。
[^1]: 开沿内部目前在跑「云效 + azeroth 自研项目工时」双轨：研发在云效里关任务自然出工时，交付和定制开发在 azeroth 里按客户和合同填报，每周对账。这套做法不是一开始就有的，是踩了几次「让所有人填同一张表」的坑之后才妥协出来的分层方案。
[^2]: 某 80 人左右的项目交付型公司，最初想一刀切上自研工时中台，跑了三个月发现销售和行政的填报率不到三成，最后回退到「交付和研发走自研、销售和职能走简道云」的混合架构，整体填报率回到九成以上。承认不同工种工作形态不一样，比强行统一省心得多。
