RequestHunt 首页仍未更新：8 条 CRM 需求，必填拦得住人手，拦不住工作流
RequestHunt 首页仍未更新，本期从站内 CRM 主题页取 8 条真实需求，沿新建、填写、推进、送达四道门拆开，逐条对照原帖与官方文档，给出可落地的机会、代价与排期判断。
RequestHunt 首页那 30 条今天照旧，最新一条停在 2026 年 6 月 23 日，Trending 页仍写最近 7 天 0 条新增。1
这期从站内的 CRM software 主题页取 8 条需求，来源是 Twenty 的 GitHub 仓库、r/CRM、r/hubspot、r/salesforce 四个地方。2
八条需求落在同一道口子上：一条客户记录什么时候算「合格」，这道门由谁来关。
一、买回来的是整套，用得上的是 2%
一句「Jill 在 2/10 记了一笔」
r/CRM 上有人替一家小律所求助，帖子发于 2026 年 3 月 12 日，今天读到 10 分、30 条评论。3
这家律所现在只有 Microsoft 365 和 Google 日历，要的东西三件。
第一件是客户来电的记录。同事打开客户档案，要能看见「Jill 在 2/10 记下，你来电问过 X 这件事」。
第二件是客户之间的关系，用来做利益冲突检查：新客户和已代理的客户之间有没有亲属、转介这类关系。
第三件他自己标成愿望：Google 日历不记改期，只显示谁建了这条日程；Outlook 记全了改动，但让全所换过去太难。
Clio 这类律所专用工具他看过，每席每月 150 美元，用得上的是 2%。3
评论区把这三件事一条条对到了 Zoho CRM 上：联系人自带时间线，关系字段能连亲属与转介，日历双向同步，基础版约 14 美元一席一个月。4
同一段回复也划了边界：Google 日历本身不公开改动记录，这块任何 CRM 都补不上，只能把日程搬进有审计的系统里。
另一条回复来自一位做产品的开发，他说客户的「关系」那部分自己没看懂现实里怎么运转。5
对做产品的人，这句话比价格表更有用：整套买下来的痛已经说清楚了，替代方案怎么落地还没人演示过。
这条需求在 RequestHunt 上的标题叫「为小公司加基础客户跟踪功能」，挂在 ServiceTitan 名下，页面分 9。6
原帖问的是「有没有任何基础工具能用」，从头到尾没提 ServiceTitan。把这条挂在一家厂商名下，小公司整类买家的采购痛就容易被读成一次功能补齐。
三万美元一个月到十二万，三天期限
同一天，另一位在代理商工作的人讲了另一头的事。7
他手上 20 到 25 个客户用 ServiceTitan。其中一个客户的月费从约 3 千美元涨到约 1 万美元，年费从 3.6 万涨到 12 万。
销售给出的说法是：之前几个月是赠送的权益，现在要么付费，要么关掉。邮件抄送了代理商，期限三天。
评论里有人说每技术员席位 300 美元，有人说续约时的加购重置成全价是常见套路。8
最实用的一条建议是审计用量：多数门店真正只用到排程、派单、开票、工单跟踪，约占所付费用的 30% 到 40%，砍到 Jobber 这类工具每月 200 到 350 美元就够。9
另一条回复把要求说得更具体：把基础许可和每一项加购拆开报价，别等续约才看见总数。10
两条帖子放在一起，比例关系很清楚：一边愿意为 2% 的能力付钱，一边付着 100% 的钱用 30% 的功能。
二、门没装在创建那一下
一个联合创始人自己提的 issue，五个月后被关掉
Twenty 是开源的 CRM，今天 60,386 星、167 个未关 issue。11
2026 年 3 月 13 日，它的联合创始人 Felix Malfait 自己开了一条 issue，标题是「为带必填字段的对象引入创建表单」。12
他把问题写得很直白：点「Add New」时，系统立刻发出创建请求，缺必填字段就报一个看不懂的 GraphQL 错误。
过去的补法是自动填占位符，比如标题写「Untitled」。他承认这能跑通，但留下一堆假数据等人回头改。
更硬的两种字段没法补：必填的关联字段（比如联系人必须挂在一个公司下），以及一个还没有选项的下拉字段。
他提的方案是三阶段：先把创建改成表单、填完才保存；再在数据模型里开放「必填」开关和正则约束；最后允许存成草稿。
2026 年 8 月 25 日，这条 issue 被标成 closed as not planned。12
与它配套的占位符方案 PR #18616 同样没有合入。14
到今年 6 月，必填字段在数据模型里已经存在，只是还有 bug：给一个必填的关联字段改描述会直接失败，报「非空字段的默认值不能为空」。15
也就是内部结构留了门框，门口那一下没做。
校验标了「完成」，实现两次都没合进去
两天后，有人提了同一条线上的第二个需求：给自定义文本字段加正则校验，比如车牌必须写成 ABC123 这种格式。16
这条 issue 在 2026 年 3 月 16 日就关闭了，状态是 completed。
同一天有人在下面留言，说现在任何字段校验都做不了，原因两条。16
第一，界面新建的记录字段默认是空值，API 不传也是空值；第二，每次更新都会触发数据库事件，两个字段都设了校验时，只改其中一个就会失败。
他给了个绕法：用工作流监听字段更新，不符合规则就退回原值。麻烦在于，怎么把「你填错了」告诉填的人。
Twenty 官方文档里，字段那一页更新于 2026 年 10 月 26 日，讲了唯一值、停用字段、索引，没有校验。19
判断一条需求有没有落地，光看 issue 状态会出错；合并记录和文档里那一节才是凭证。
邮件发出去，回来接不上
第三条来自同一个仓库，2026 年 3 月 15 日开的：用工作流自动发跟进邮件时，要把第二封接在第一封的会话里。20
现在的发信动作只返回主题、收件人、抄送、附件数、发信账号，邮件服务商返回的 threadId 和 messageId 被丢掉了。
结果是每封跟进都另起一串会话。作者写得很直接：收件人看着不专业，也难追上下文，回复率会掉。
issue 开出两个多小时后，另一位开发者贴出了 PR #18641，给邮件工作流节点加上 In-Reply-To 头。21
这个 PR 在 3 月 22 日合入。作者回帖说，他已经先自己绕过去了。
四天里，一条被关掉、一条被实现、一条标了完成却没实现，三条需求的状态各不相同。这正是读者判断信号时最费劲的地方。
三、门没装在推进那一下
用 AI 摘要当门槛，平台只能给个任务提醒
r/hubspot 上有人 2026 年 3 月 12 日发帖，问有没有人把 AI 会话摘要设成建 SQL 的必填项。帖子今天 5 分、3 条评论，需求页 1 分。22
他们试的规则很简单：没有摘要就不建 SQL。摘要里要写清客户的问题、时间线、卡点、下一步。
回帖里最有用的一条讲清了 HubSpot 能做到哪一步。23
HubSpot 原生拦不住生命周期阶段的变更。可用的办法是让工作流在阶段变成 SQL 时检查必填属性，缺一个就派个任务给销售、发一条内部通知，用摩擦让人自己补。
这条回复还给了两个具体设计：摘要要拆成五个结构化字段，别存成一段自由文本；摘要存在商机上，别存在联系人上。
另一位回帖者补了实现细节：让模型按大纲输出，字段填上后派任务给 AE 复核，不合格打回给 SDR。24
平台这一侧是什么情况，官方文档写得很清楚：校验规则在桌面和移动端保存值时强制生效。25
同一个页面的黄色提示框列了例外：工作流、聊天流、会议预约页提交、旧版表单编辑器做的表单，都不强制校验。
换成产品语言：人手填的那条路有门，机器写的那条路开着。
HubSpot 正在把门挪过去。2026 年 8 月 11 日的公告说，从 9 月 8 日发布的 /2026-09/ API 版本起，管理员配的校验规则会作用到所有 CRM 写入接口，包括条件必填和创建记录时的必填项。26
公告自己也承认，此前这些规则只在界面上生效，API 直接忽略。
配置这件事，交给一个要反复确认的 agent
r/salesforce 上有人 2026 年 3 月 12 日发帖，说他正用 Claude Code 配 Salesforce CLI 做配置和部署，今天 7 分、5 条评论。27
卡点很具体：Claude 每次要执行另一条命令的变体，都会停下来要他确认，他得反复教它怎么跟这个 CLI 打交道。
他想找一份写好的 skill 文件，把这件事一次交代清楚。
还有人给了最快的一条路：让 Claude 自己去查 CLI 命令，写一份 skill 文件，够用了。31
这条需求的题面是「给 Salesforce CLI 加 agent 技能」，读起来像厂商该发的功能。原帖问的是一个配置者怎么少确认几次。
平台没替配置者准备这份说明，每个人只好在自己的对话记录里攒一份。
四、门没装在送达那一段
换到新平台两个月，深链只有一半能用
同样是 r/hubspot，2026 年 3 月 13 日有位做移动应用的人发帖，今天 6 分、16 条评论，需求页 3 分。32
他们把应用的 CRM 和邮件营销并到 HubSpot 两个月，周报的送达率很差，邮件里的应用深链只有约 50% 能打开。
他说论坛和 ChatGPT 都问遍了，现在想按天请个人来收拾。
回复里有一位把诊断顺序列全了：先查 SPF、DKIM、DMARC 有没有配在发信域名上，再查新域名有没有预热、发送量是不是起得太快、导入的名单有没有清过、邮件是不是图多链接多。33
深链那一半的失败，他给了一个具体原因：HubSpot 的点击跟踪会把链接改写成跟踪地址，应用的 URL scheme 就断了，可以给这类链接单独关掉跟踪。
另一条回复提到 HubSpot 正在内测「Throttle Marketing Email」，可以设定单次最大发送量，帮新域名慢慢积累信誉。34
也有回复直接给了商务方案：一到两天的专项，把两块一起收拾。35
这一条的验收标准是送达率和点击率，而这两个数一大半由 DNS、域名信誉和收件方决定，产品只能在旁边递清单。
五、三道门现在各是什么状态
| 门 | 现在是什么样 | 材料 |
|---|---|---|
| 建：新建一条记录 | Twenty 点「Add New」立刻发请求，缺必填字段就报错；表单化方案 8 月 25 日被标成不实现 12 | GitHub issue #18618 |
| 填：值写进去 | HubSpot 在界面保存时强制校验，工作流与聊天流的写入不强制 25；Twenty 的正则校验 issue 标了完成，两个实现 PR 未合并 1617 | HubSpot 知识库、GitHub issue #18655 |
| 推：记录往后走 | HubSpot 原生拦不住阶段变更，只能派任务、发通知制造摩擦 23 | r/hubspot 回帖 |
三条共性，都能在这批材料里找到出处。
第一，产品把「合格」做成了提示和事后报表。拦住一次录入，就要多花用户几秒；多数团队选择让数据先落地，再派人收拾。
第二，门槛的位置正在从人手挪到接口。HubSpot 把校验推到了 9 月 8 日的 API 版本，Twenty 把校验做在字段元数据这一层，方向一致：先卡住机器写的那条路。
第三，门没装好的时候，补门的人是用产品的团队。AI 摘要加任务提醒是一道自建的门，Claude Code 加 skill 文件也是一道自建的门。
六、可以排期的四个切口
记录先存成草稿。 允许不完整的记录存在，但标成草稿，报表和自动化默认排除。代价是报表口径和权限要跟着改，历史数据的补标要有人做。
给每条记录算一个完整度。 未填的必填项、缺的关联算成一个可排序的字段，放在列表页和看板上。代价是这个数会被刷，得配一条审计日志才站得住。
把新建入口分成两条路。 批量导入走快通道，人工新建走表单。代价是两条路的字段规则要长期保持一致，改一处得改两处。
做一份迁移体检清单。 DNS 三件套、域名预热、名单清洗、深链与点击跟踪，逐项打勾才能开闸。代价是一半检查项在产品之外，产品能做的只有检查与提示。
按改动落点分，这四条的排期层次也清楚。
今天就能动的：报表默认排除草稿、完整度字段与列表视图、迁移清单、把外部邮件的线程标识存进自定义字段。
要等版本的：创建表单与必填开关、阶段变更前的硬校验、把校验规则推到所有写入接口。
只能自己绕的：邮件送达与域名信誉、CLI 的权限与环境差异、日历本身的改动记录。
这八条需求都来自 RequestHunt 站内主题页，不在首页那 30 条里；页面分是抓取那一刻的快照，原帖的分数与评论数每天都在动，正文里给的是今天的读数。2
References
- 1RequestHunt
requesthunt.com
- 2CRM software 主题页
requesthunt.com
- 3
- 4r/CRM 回复：Zoho CRM 逐项对应
reddit.com
- 5r/CRM 回复：关系字段没看懂
reddit.com
- 6需求页：ServiceTitan baseline
requesthunt.com
- 7ServiceTitan CRM Cost Transparency
reddit.com
- 8r/CRM 回复：$300 一个技术员席位
reddit.com
- 9r/CRM 回复：先审计实际用量
reddit.com
- 10r/CRM 回复：拆开基础许可与加购
reddit.com
- 11twentyhq/twenty
github.com
- 12Issue #18618：Introduce creation forms
github.com
- 13Issue #2336：Closed as not planned
github.com
- 14
- 15Issue #21751：非空关联字段无法更新
github.com
- 16Issue #18655：正则校验
github.com
- 17PR #19140：add regex pattern validation
github.com
- 18
- 19Twenty 文档：Fields
docs.twenty.com
- 20
- 21
- 22r/hubspot：AI 摘要做 SQL 必填项
reddit.com
- 23r/hubspot 回复：原生拦不住阶段变更
reddit.com
- 24r/hubspot 回复：按大纲输出再复核
reddit.com
- 25HubSpot：Set validation rules for a property
knowledge.hubspot.com
- 26HubSpot 公告：CRM API Write Validation Enforcement
community.hubspot.com
- 27
- 28r/salesforce 回复：claude-salesforce-skill
reddit.com
- 29r/salesforce 回复：skills.sh
reddit.com
- 30r/salesforce 回复：sf-skills
reddit.com
- 31r/salesforce 回复：让 Claude 自己写 skill
reddit.com
- 32r/hubspot：迁移后送达率与深链
reddit.com
- 33r/hubspot 回复：诊断顺序
reddit.com
- 34r/hubspot 回复：限速与域名信誉
reddit.com
- 35r/hubspot 回复：一到两天专项
reddit.com
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.