向印度用户发送商业短信时，数据和触达是两条不能脱节的链路。CRM里存储着客户的手机号、姓名、订单状态和购买历史，而短信API负责将这些信息转化为实际的消息触达。两者如果孤立运作，就会陷入“数据在CRM里、触达在另一个平台”的分裂状态。
CRM或ERP系统触发一个事件(如订单创建、工单状态变更)后，通过API请求到达短信平台，平台立即进行同意检查和DLT合规校验，随后运营商网关完成消息路由，最终手机端收到消息并返回送达确认。如果投递失败，API内置的故障转移规则会自动重试或切换到备用路由。
在印度市场，这套数据流还多了一层约束：**DLT合规校验必须在API层完成**，而不是在消息发出后才补检查。每条消息的模板ID、Sender ID、Entity ID都必须与CRM中记录的客户数据类型匹配，否则短信会被运营商在清洗阶段直接拦截。
CRM与短信API之间的数据同步，需要三层架构协同工作：
**第一层：事件触发层**。CRM中的业务事件(线索创建、订单状态变更、工单更新、支付提醒)作为触发器。当这些事件发生时，CRM通过Webhook或原生插件向中间件发送通知。
**第二层：中间件与映射层**。中间件负责接收CRM事件、提取客户数据字段、映射到短信API的请求参数格式。映射的核心字段包括：**手机号**(需标准化为印度10位格式，不含国家代码或前导0)、**客户姓名**(用于个性化)、**模板ID**(与DLT备案模板关联)、**消息类型**(Transactional/Service Implicit/Promotional)。
**第三层：短信API与DLR回写层**。短信API向运营商网关发送请求后，通过Webhook接收DLR(送达报告)，并将状态回写到CRM中的对应客户记录或活动日志。
以HubSpot为例，一个典型的同步流程是：CRM工作流触发 → 发送Webhook到短信API端点(携带`to`、`message`、`senderId`、`templateId`、`type`参数)→ 短信平台校验DLT参数并发送 → DLR回写到CRM活动日志。Salesforce则通过Apex Callout或Flow中的HTTP调用实现类似流程，同时要求`SmsMessageRegulatoryAuthorityTemplateId`字段携带DLT模板ID。
| 同步层级 | 核心职责 | 关键组件 |
|---|---|---|
| 事件触发层 | 捕获CRM业务事件，发起同步请求 | CRM工作流、Webhook、原生插件 |
| 中间件映射层 | 数据字段提取、格式标准化、DLT参数注入 | Node.js/Python中间件、字段映射表 |
| 短信API与回写层 | 调用短信API发送、接收DLR并回写CRM | REST API、Webhook接收端点、CRM活动日志API |
CRM中的客户数据字段并非全部需要同步到短信API。核心映射字段分为三类：
**必填字段**：手机号(标准化为10位印度号码)、DLT模板ID、DLT Entity ID、Sender ID。缺少任何一项，印度运营商网关会直接拦截。
**个性化字段**：客户姓名、订单号、金额、预约时间等。这些字段映射到DLT模板中的变量占位符(如`{#alphanumeric#}`、`{#numeric#}`)，发送时由CRM数据动态填充。
**跟踪字段**：CRM中的客户ID或消息参考ID，用于将DLR回写到正确的客户记录。
| 字段类别 | CRM字段示例 | 短信API参数 | 同步要求 |
|---|---|---|---|
| 必填（合规） | 客户手机号 | mobile | 标准化为10位格式 |
| 模板ID（来自DLT） | templateId | 与消息内容匹配 | |
| Entity ID（来自DLT） | entityId | 企业级参数 | |
| Sender ID（6位Header） | senderId | 与模板类型匹配 | |
| 个性化 | 姓名 | message中的{#alphanumeric#} | 动态填充 |
| 订单金额 | message中的{#numeric#} | 动态填充 | |
| 跟踪 | CRM记录ID | custRef | 用于DLR回写 |
对于印度市场，**DLT模板ID和Entity ID必须从CRM字段中自动读取**，而不是手动填入代码。这意味着CRM中需要存储每个客户或业务场景对应的模板ID，并在触发短信时自动匹配。
CRM与短信API的同步不是单向的。完整的双向同步包含两个方向：
**出站(CRM→短信API)** ：CRM事件触发消息发送。例如，当订单状态变为“已发货”时，CRM自动调用短信API发送包含追踪链接的通知短信。消息内容、模板ID和变量值全部来自CRM字段。
**入站(短信API→CRM)** ：用户回复短信后，短信平台通过Webhook将回复内容推送到中间件，中间件根据手机号匹配CRM中的客户记录，将回复内容写入活动日志或触发新的CRM工作流。例如，用户回复“R”表示改期预约，CRM自动创建一个跟进任务。
在印度DLT体系下，入站短信还需要注意：**双向短信仅支持部分运营商和号码类型**。8x8的印度短信指南明确指出，T-Mobile和Ufone等运营商对双向短信的支持有限，部分流量可能无法接收用户回复。因此，双向同步方案需要根据目标运营商的覆盖情况，设计降级策略——如果入站通道不可用，改用IVR或WhatsApp作为回复渠道。
CRM与短信API对接最大的技术挑战，是**确保每一条消息都携带正确的DLT参数**。手动在代码中填入模板ID和Entity ID既不可扩展，也容易出错。推荐的方式是在中间件层建立DLT参数映射表：
| CRM字段/事件 | 自动匹配的DLT参数 | 匹配逻辑 |
|---|---|---|
| 订单发货事件 | Service Implicit模板ID | 根据事件类型匹配 |
| 支付提醒事件 | Service Implicit模板ID | 根据事件类型匹配 |
| 营销活动事件 | Promotional模板ID + Consent | 需检查DND和同意状态 |
| OTP验证事件 | Transactional模板ID | 仅RBI批准实体可用 |
中间件在收到CRM事件后，首先根据事件类型查询映射表，自动注入对应的`templateId`、`entityId`和`senderId`。如果CRM中存储了多个模板ID(如不同业务线使用不同模板)，中间件根据业务规则选择正确的模板。
**手机号标准化**：印度号码必须以10位格式发送(如`9876543210`)，不带国家代码`91`或前导`0`。CRM中的数据往往格式不统一，中间件必须包含标准化逻辑。
**幂等去重**：CRM事件可能因重试而重复触发。中间件应使用CRM事件ID或消息参考ID作为幂等键，防止同一条短信被发送多次。
**DLR回写映射**：短信API返回的DLR中包含`messageId`和状态。中间件需要将这个状态回写到CRM中对应客户的活动日志或自定义字段，确保销售团队能看到每条短信的送达结果。
**发送时段控制**：Promotional短信只能在印度标准时间上午10点至晚上9点之间发送。中间件应在调用短信API前检查当前时间，超出时段的请求应排队到次日窗口。
**失败降级**：如果短信因DLT清洗失败或DND拦截而失败，中间件应触发降级通道——如WhatsApp消息或语音OTP——而不是简单地重试短信。
1. **完成DLT注册**：Entity ID、Sender ID(6位Header)、Content Template全部在DLT平台注册通过
2. **在CRM中存储DLT参数**：将模板ID和Entity ID作为CRM字段或业务规则映射表的一部分
3. **标准化手机号格式**：确保CRM中的手机号经过清洗，统一为10位印度号码
4. **建立中间件映射层**：实现CRM事件到短信API参数的自动转换，注入DLT参数
5. **配置Webhook回写**：将DLR状态和入站回复写入CRM活动日志
6. **设置发送时段控制**：Promotional短信仅在10:00-21:00之间发送
7. **实现降级策略**：短信失败时自动切换WhatsApp或语音通道
8. **监控同步日志**：记录每次同步的请求、响应和DLR状态，用于排查和审计
对于向印度市场发送短信的企业而言，**CRM与短信API的对接不仅仅是技术集成，更是合规和效率的双重工程**。正确的同步方案让销售团队在CRM中就能看到每条短信的送达状态，让合规参数自动注入而无需人工干预，最终将消息触达的可靠性转化为可衡量的业务结果。
