rcs-agent-onboarding
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
Chinese<!--
Verified against Sent sources:
- https://docs.sent.dm/start/quickstart/channel-setup
- https://docs.sent.dm/start/quickstart/first-message
- https://docs.sent.dm/start/quickstart/dashboard-walkthrough
- Sent v3 OpenAPI: POST /v3/messages, GET /v3/messages/{id}, GET /v3/messages/{id}/activities, /v3/profiles, /v3/profiles/{profileId}/complete
Review notes:
- Sent docs say RCS setup is not self-service, requires one-time carrier approval, and should be initiated by contacting Sent.
- Sent docs verify automatic SMS fallback when RCS is unavailable and explicit fallback/broadcast using channel arrays such as ["rcs", "sms"].
- Treat Google RBM launch states, capability endpoints, and per-carrier rollout fields as external platform context unless Sent exposes them in the customer’s account or docs.
-->
<!--
已对照Sent来源验证:
- https://docs.sent.dm/start/quickstart/channel-setup
- https://docs.sent.dm/start/quickstart/first-message
- https://docs.sent.dm/start/quickstart/dashboard-walkthrough
- Sent v3 OpenAPI: POST /v3/messages, GET /v3/messages/{id}, GET /v3/messages/{id}/activities, /v3/profiles, /v3/profiles/{profileId}/complete
审核说明:
- Sent文档指出RCS设置不支持自助服务,需一次性运营商审批,且需联系Sent发起。
- Sent文档验证了当RCS不可用时会自动触发SMS回退,也可通过["rcs", "sms"]这类渠道数组实现显式回退/广播。
- 除非Sent在客户账户或文档中公开相关内容,否则将Google RBM上线状态、能力端点及分运营商部署字段视为外部平台上下文。
-->
RCS agent onboarding
RCS Agent入职指南
Overview
概述
Use this skill to prepare a Sent customer for RCS launch without inventing a self-service provisioning flow. Sent’s public channel setup guidance says RCS setup is initiated through Sent, requires one-time carrier approval, and is not self-service. The agent’s job is to collect clean launch evidence, design fallback behavior, confirm profile/channel readiness, and create a verification plan for the first production sends.
RCS onboarding touches three separate layers. Sent owns the unified messaging API and fallback behavior. Google RBM and carriers own brand/agent review and launch approval. The customer owns brand assets, use-case clarity, consent, and support readiness. Keep those boundaries explicit.
使用本技能为Sent客户准备RCS上线工作,无需自行构建自助式配置流程。Sent公开的渠道设置指南指出,RCS设置需通过Sent发起,需一次性运营商审批,且不支持自助操作。Agent的职责是收集规范的上线证据、设计回退行为、确认资料/渠道就绪状态,并为首次生产环境发送制定验证计划。
RCS入职涉及三个独立层面:Sent负责统一消息API及回退行为;Google RBM和运营商负责品牌/Agent审核及上线审批;客户负责品牌资产、用例明确性、用户同意及支持就绪状态。需明确区分这些边界。
When to use
使用场景
Use this skill when the request mentions RCS, RBM, RCS agent, carrier launch, branded messaging, rich card, carousel, SMS fallback from RCS, or RCS approval. Use it for launch preparation, evidence gathering, fallback decisions, and post-launch smoke tests.
Do not use this skill for live delivery-rate analysis after launch; use . Do not use it to register US SMS compliance; use . Do not promise direct Graph/RBM API provisioning unless the user confirms they operate the external RBM account outside Sent.
messaging-performance-analyzersms-10dlc-registration当请求中提及RCS、RBM、RCS Agent、运营商上线、品牌消息、富卡片、轮播、RCS转SMS回退或RCS审批时,可使用本技能。适用于上线准备、证据收集、回退决策及上线后冒烟测试。
上线后的实时送达率分析请勿使用本技能,请使用;美国SMS合规注册请勿使用本技能,请使用;除非用户确认其在Sent之外运营外部RBM账户,否则请勿承诺直接提供Graph/RBM API配置服务。
messaging-performance-analyzersms-10dlc-registrationSource-of-truth boundaries
事实来源边界
| Topic | Treat as | Action |
|---|---|---|
| Sent API sending | Sent API fact | Use |
| RCS setup path | Sent documentation fact | Tell the user RCS setup is initiated by contacting Sent and requires approval. |
| SMS fallback | Sent documentation fact | Use Sent’s fallback behavior and explicit |
| Google RBM agent fields | External platform context | Collect assets and evidence, but do not claim Sent exposes those fields. |
| Per-carrier launch states | External platform context | Track approval evidence from Sent/Google/carriers; do not invent Sent status fields. |
| Rich-card rendering | Runtime evidence | Verify with test sends and message activities after setup is active. |
| 主题 | 归类为 | 操作 |
|---|---|---|
| Sent API发送 | Sent API事实 | 使用带模板和渠道数组的 |
| RCS设置路径 | Sent文档事实 | 告知用户RCS设置需联系Sent发起并等待审批。 |
| SMS回退 | Sent文档事实 | 利用Sent的回退行为,在合适场景下使用显式的 |
| Google RBM Agent字段 | 外部平台上下文 | 收集资产和证据,但请勿声称Sent会暴露这些字段。 |
| 分运营商上线状态 | 外部平台上下文 | 跟踪来自Sent/Google/运营商的审批证据;请勿虚构Sent状态字段。 |
| 富卡片渲染 | 运行时证据 | 设置生效后,通过测试发送和消息活动验证渲染效果。 |
Process
流程
1. Classify the requested launch
1. 分类请求的上线类型
Start by asking what the RCS agent will do, who receives the messages, and whether SMS fallback is required. The use case should be concrete enough for carrier review and template design.
A good launch statement names the brand, audience, consent source, message types, support contact, and fallback behavior. A weak launch statement says only “we want RCS for marketing” or “we need branded SMS.”
Example. “Acme Logistics wants RCS order updates for US consumers who opted in at checkout. Messages include shipment confirmation, delivery window changes, and support links. If RCS is unavailable, send the SMS version through the same Sent profile.”
首先询问用户RCS Agent的用途、消息接收对象及是否需要SMS回退。用例需足够具体,以满足运营商审核和模板设计要求。
优质的上线说明应包含品牌名称、受众群体、用户同意来源、消息类型、支持联系方式及回退行为。模糊的上线说明仅会提及“我们想用于营销的RCS”或“我们需要品牌化SMS”。
示例:“Acme Logistics希望为在结账时选择同意的美国消费者发送RCS订单更新消息,内容包括发货确认、配送窗口变更及支持链接。若RCS不可用,则通过同一Sent资料发送SMS版本。”
2. Build the RCS evidence packet
2. 构建RCS证据包
Collect review-ready evidence before involving Sent. This reduces approval loops and prevents the agent from submitting vague brand claims.
| Evidence | What to collect | Why it matters |
|---|---|---|
| Brand identity | Legal name, public brand name, website, logo, brand color, description | Reviewers compare the agent identity to the live business. |
| Contact and support | Support email, support phone, help URL, privacy policy | RCS users need visible ways to identify and contact the sender. |
| Use case | Transactional, OTP, marketing, customer care, or mixed use | Approval and fallback design depend on intent and consent. |
| Consent | Opt-in path, screenshot/URL, privacy policy, opt-out wording | Carriers need proof that recipients expect the messages. |
| Message examples | Representative plain-text and rich examples | Rich content must match the declared use case and brand. |
| SMS fallback | Equivalent SMS copy and approved SMS sender/compliance status | Fallback fails if SMS compliance is not ready. |
在联系Sent前收集符合审核要求的证据,以此减少审批循环,避免Agent提交模糊的品牌声明。
| 证据类型 | 收集内容 | 重要性 |
|---|---|---|
| 品牌身份 | 法定名称、公开品牌名、官网、Logo、品牌色、品牌描述 | 审核人员会将Agent身份与实际业务进行比对。 |
| 联系与支持信息 | 支持邮箱、支持电话、帮助中心URL、隐私政策 | RCS用户需要明确的方式识别并联系发送方。 |
| 用例类型 | 交易通知、一次性验证码(OTP)、营销、客户服务或混合用例 | 审批和回退设计取决于用例意图和用户同意情况。 |
| 用户同意证明 | 选择同意的路径、截图/URL、隐私政策、退订说明 | 运营商需要证明接收方期望收到此类消息。 |
| 消息示例 | 具有代表性的纯文本和富内容示例 | 富内容需与声明的用例及品牌匹配。 |
| SMS回退内容 | 对应的SMS文案及已获批的SMS发送方/合规状态 | 若SMS合规未就绪,回退将失败。 |
3. Check Sent profile and SMS fallback readiness
3. 检查Sent资料及SMS回退就绪状态
Confirm that the customer has a Sender Profile in the Sent dashboard or through . The dashboard walkthrough shows Sender Profiles with a display name, brand description, , and SMS/WhatsApp configuration status. The OpenAPI confirms profile creation, retrieval, update, and completion endpoints.
/v3/profilesx-sender-idIf the launch requires US SMS fallback, verify that the SMS side is compliant before RCS goes live. Sent’s channel setup guide recommends using the same phone number across SMS, WhatsApp, and RCS where possible, but fallback must still have a valid SMS route and compliance posture.
Example fallback request. After Sent confirms RCS is configured, a customer can request an RCS-first send with SMS fallback/broadcast semantics using a channel array such as:
json
{
"to": ["+15551234567"],
"channel": ["rcs", "sms"],
"template": { "id": "template_uuid" }
}Explain that Sent may create separate messages for each recipient/channel pair when multiple channels are specified. Analyze RCS and SMS attempts separately after sending.
确认客户已在Sent控制台或通过接口创建Sender Profile。控制台指南显示Sender Profile包含显示名称、品牌描述、及SMS/WhatsApp配置状态。OpenAPI确认了资料创建、检索、更新及完成的端点。
/v3/profilesx-sender-id若上线需要美国SMS回退,请在RCS上线前验证SMS侧已合规。Sent渠道设置指南建议尽可能在SMS、WhatsApp和RCS间使用同一电话号码,但回退仍需具备有效的SMS路由和合规状态。
回退请求示例:Sent确认RCS配置完成后,客户可通过渠道数组发起优先RCS发送、SMS回退/广播的请求,示例如下:
json
{
"to": ["+15551234567"],
"channel": ["rcs", "sms"],
"template": { "id": "template_uuid" }
}需说明,当指定多个渠道时,Sent可能会为每个接收方/渠道对创建独立消息。发送完成后需分别分析RCS和SMS的发送尝试情况。
4. Route the launch through Sent
4. 通过Sent发起上线流程
Because Sent states that production RCS setup is not self-service, prepare a handoff note for Sent rather than pretending to click through an RBM console. Include the evidence packet, the Sender Profile identifier, the target countries/carriers if known, fallback requirements, and the requested go-live timeline.
A clean handoff reads like this:
“Please initiate RCS setup for Sender Profile/support-usx-sender-id. Brand is Acme Logistics, website..., use case shipment notifications and customer-care replies. Opt-in occurs at checkout. SMS fallback is required through the existing US SMS route. Attached are logo, brand color, support contacts, privacy policy, and five message examples.”https://acme.example
由于Sent明确指出生产环境RCS设置不支持自助服务,请为Sent准备交接说明,而非模拟操作RBM控制台。交接说明需包含证据包、Sender Profile标识符(若已知)、目标国家/运营商、回退要求及期望的上线时间线。
规范的交接说明示例:
“请为Sender Profile/support-usx-sender-id发起RCS设置。品牌为Acme Logistics,官网...,用例为发货通知和客户服务回复。用户在结账时选择同意。需通过现有美国SMS路由实现SMS回退。附件包含Logo、品牌色、支持联系方式、隐私政策及5条消息示例。”https://acme.example
5. Define the test plan before launch
5. 上线前制定测试计划
Write the first-send test plan before approval arrives. Include a small set of internal numbers, target devices/carriers when available, template IDs, expected channel behavior, and rollback criteria.
| Test | Expected result | Evidence to collect |
|---|---|---|
| RCS-capable internal device | RCS message reaches | Sent message status and activities. |
| Non-RCS-capable recipient | SMS fallback path succeeds where fallback is requested. | Separate RCS and SMS message IDs/statuses. |
| Rich content render | Cards/buttons render as designed on target devices. | Screenshots and message activities. |
| Webhook callback | Customer endpoint receives delivery/read events. | Sent webhook event history and customer logs. |
在获得审批前制定首次发送测试计划,包含少量内部测试号码、目标设备/运营商(若可用)、模板ID、预期渠道行为及回滚标准。
| 测试项 | 预期结果 | 需收集的证据 |
|---|---|---|
| 支持RCS的内部设备 | RCS消息状态变为 | Sent消息状态及活动记录。 |
| 不支持RCS的接收方 | 若请求了回退,则SMS回退路径执行成功。 | 独立的RCS和SMS消息ID/状态。 |
| 富内容渲染 | 卡片/按钮在目标设备上按设计显示。 | 截图及消息活动记录。 |
| Webhook回调 | 客户端点接收到送达/已读事件。 | Sent Webhook事件历史及客户日志。 |
6. Verify launch with Sent message evidence
6. 利用Sent消息证据验证上线结果
After Sent confirms the RCS setup is active, send a controlled batch using . For every Sent , retrieve and . Confirm that RCS messages progress through the documented lifecycle and that SMS fallback behaves as expected.
POST /v3/messagesmessage_idGET /v3/messages/{id}GET /v3/messages/{id}/activitiesIf the first batch fails, do not guess. Separate setup failures from fallback failures, template/payload failures, and webhook ingestion failures. Use for deeper funnel analysis once the launch is producing enough evidence.
messaging-performance-analyzerSent确认RCS设置生效后,使用接口发送受控批量消息。针对每个Sent ,调用和接口。确认RCS消息按文档记录的生命周期推进,且SMS回退行为符合预期。
POST /v3/messagesmessage_idGET /v3/messages/{id}GET /v3/messages/{id}/activities若首批发送失败,请勿猜测原因。需区分设置失败、回退失败、模板/负载失败及Webhook接收失败。当上线产生足够证据后,可使用进行更深入的漏斗分析。
messaging-performance-analyzerCommon rationalizations to avoid
需避免的常见误区
Do not tell the user RCS is self-service in Sent. Sent’s channel setup guide says to contact Sent and wait for carrier approval.
Do not create a fake field in Sent requests. Use documented channel arrays and account-level fallback behavior unless a verified account-specific API field exists.
fallback_policyDo not assume SMS fallback is safe because RCS is approved. SMS fallback needs a compliant sender, especially for US A2P traffic.
Do not conflate brand approval with template quality. An approved RCS agent can still fail if the message payload, media, or fallback copy is wrong.
请勿告知用户Sent支持RCS自助服务。Sent渠道设置指南明确要求联系Sent并等待运营商审批。
请勿在Sent请求中虚构字段。除非存在已验证的账户专属API字段,否则请使用文档中规定的渠道数组及账户级回退行为。
fallback_policy请勿因RCS已获批就默认SMS回退是安全的。SMS回退需要合规的发送方,尤其是针对美国A2P流量。
请勿将品牌审批与模板质量混淆。即使RCS Agent已获批,若消息负载、媒体或回退文案存在问题,仍可能发送失败。
Verification checklist
验证清单
- The user’s RCS use case is specific enough for review and not just “send rich messages.”
- Brand identity, support contact, privacy policy, opt-in evidence, and sample messages are collected.
- The Sent Sender Profile or is identified.
x-sender-id - SMS fallback requirements are documented and routed to SMS compliance checks where needed.
- The handoff explicitly says Sent must initiate RCS setup and carrier approval.
- The first-send test plan includes RCS-capable, non-RCS-capable, rich-rendering, and webhook checks.
- Post-launch verification uses Sent , status, and activities.
message_id - External RBM facts are labeled as external context, not Sent API guarantees.
- 用户的RCS用例足够具体,可用于审核,而非仅提及“发送富消息”。
- 已收集品牌身份、支持联系方式、隐私政策、用户同意证明及消息样本。
- 已确定Sent Sender Profile或。
x-sender-id - 已记录SMS回退要求,并在必要时提交至SMS合规检查。
- 交接说明明确指出需由Sent发起RCS设置及运营商审批。
- 首次发送测试计划包含支持RCS设备、不支持RCS设备、富内容渲染及Webhook检查项。
- 上线后验证使用了Sent 、状态及活动记录。
message_id - 外部RBM事实被标记为外部上下文,而非Sent API的保证内容。
Related skills
相关技能
Use before launch when SMS fallback touches US A2P traffic, opt-in evidence, 10DLC campaigns, or brand vetting.
sms-10dlc-registrationUse when the customer has multiple brands, tenants, departments, or profiles and needs a durable sender architecture.
sender-profile-architectUse when the RCS launch needs reusable templates, rich component validation, or a template-creation workflow.
template-builder-uiUse after launch when the user has message IDs, webhook events, failed sends, or delivery-rate symptoms.
messaging-performance-analyzerUse the skill for shared Sent terminology and routing.
sent当SMS回退涉及美国A2P流量、用户同意证明、10DLC活动或品牌审核时,请在上线前使用。
sms-10dlc-registration当客户拥有多个品牌、租户、部门或资料,且需要持久化的发送方架构时,请使用。
sender-profile-architect当RCS上线需要可复用模板、富组件验证或模板创建流程时,请使用。
template-builder-ui当用户拥有消息ID、Webhook事件、发送失败记录或送达率问题时,请在上线后使用。
messaging-performance-analyzer共享Sent术语及路由请使用技能。
sentSuggested bundled references and scripts
建议的捆绑参考资料及脚本
| File | Type | Purpose |
|---|---|---|
| Payload/schema reference | Keep Google RBM identity fields, asset requirements, and review vocabulary outside the skill body. |
| Worked example | Provide a complete filled-in launch packet for a realistic transactional RCS launch. |
| Decision matrix | Compare RCS-only, RCS-first with SMS fallback, and multi-channel broadcast patterns. |
| 文件 | 类型 | 用途 |
|---|---|---|
| 负载/架构参考 | 将Google RBM身份字段、资产要求及审核术语保留在技能主体之外。 |
| 示例模板 | 提供一个完整的、已填写的真实交易类RCS上线证据包示例。 |
| 决策矩阵 | 对比仅RCS、优先RCS加SMS回退及多渠道广播模式。 |
Unverified claims to confirm or remove
待确认或移除的未验证声明
- Google RBM lifecycle states such as ,
pending_verification, or per-carrier launched states were not verified in Sent docs (these are Google-side, not exposed by Sent v3).launch_review - Sent does not expose RCS rollout-status or capability-check endpoints in v3; use Activities + webhook events to observe behavior.
- Exact rich-card capability differences by carrier/device require external RBM evidence or live testing, not Sent docs alone.
- Google RBM生命周期状态(如、
pending_verification)及分运营商上线状态未在Sent文档中验证(这些属于Google侧内容,Sent v3未暴露)。launch_review - Sent v3未暴露RCS部署状态或能力检查端点;请使用活动记录+Webhook事件观察行为。
- 不同运营商/设备间的富卡片能力差异需要外部RBM证据或实时测试,仅靠Sent文档无法确认。",