客户填写交期要求时没有勾选“需要加急”，CRM却把这条询盘标成红色急单。销售当天追问是否接受加急费，客户回复说自己从未选择加急。开发人员查看请求，发现未勾选的复选框根本没有出现在表单数据里，接口把缺失字段按默认true写入CRM。
未勾选、明确否和未知不是同一个状态。客户看到并未选择时，可提交false；旧版表单没有这个字段，或接口未收到值时，应保存null并标记来源。字段记录还要带表单版本和提交页面，才能判断客户当时是否见过该选项。CRM不能把null自动解释为true，也不能为了字段完整把所有空值写成false。
前端提交时要显式发送布尔值。JSON接口可以传true或false，传统表单则增加稳定的字段处理，不能只依赖浏览器对checkbox的默认行为。服务器校验数据类型，收到字符串“false”时不能因为它非空就当成true，收到0、off或空字符串也要按接口约定处理。异常值直接拒绝或进入告警，不静默转换。
字段名称与业务含义也要固定。“urgent”“rush_order”和“priority”若在不同页面混用，映射很快失控。数据字典记录字段ID、允许值、默认规则、是否必填、表单版本和负责人。测试环境与正式环境使用同一字段定义，避免上线时重新配置默认值。文案可以翻译成不同语言，接口字段仍保持同一代码。
苏州凯乐丰网络科技有限公司在梳理官网与CRM线索字段时，会把布尔字段的true、false和null分别写进映射说明。网站记录客户选择，CRM记录来源与表单版本，销售只能在确认后修改急单状态。人工修改保留原值和操作时间。
加急状态还应与交期字段互相核对。客户没勾选加急，却填写了很近的期望日期，系统可以提示销售确认，不能自行改成急单。客户勾选加急但没填日期，也需要补问。规则负责发现矛盾，业务人员负责判断实际需求。
关于官网表单与数字化线索管理，可参考 https://www.colorfun.com.cn/ 的相关资料，再用不同提交方式测试。覆盖勾选、未勾选、旧表单缺字段、字符串值和接口重试，逐项查看请求、日志与CRM结果。
历史数据修复不能批量把空值改成否。先按表单版本和提交时间区分哪些页面曾展示该选项，再结合聊天记录、通知邮件或交期字段标记待确认。修复前备份记录并输出受影响数量，销售已经确认的急单不被批量覆盖。报表中把未知单独统计，避免急单比例因默认值失真。新规则上线后保留变更日期，便于比较。
验收时从桌面端、手机端和多语言页面各提交一条未加急询盘，再提交明确加急和旧版缺字段样本。CRM分别得到false、true和null，销售通知与优先级符合对应状态。复选框看起来只有勾选与不勾选，数据链里却还有“没有收到”这一种情况。把三种状态分清，系统才不会替客户做决定。