Launch transcripts deserve first-class operational status

Google changed its RCS for Business launch process on October 7 so an agent preview video is no longer strictly required for Google-managed carriers. A team can instead provide detailed, step-by-step text transcripts in the Agent experience section. Google still requires clear evidence for the trigger, interaction and opt-out flow, and warns that carrier-managed requirements vary. I think this is more than a documentation convenience. A precise launch transcript should be treated as a first-class operational record.

Video is useful for showing a complete experience, but it is difficult to diff, search and review line by line. A transcript can state the exact event that triggers a message, the message and action sequence a customer sees, and the keywords plus confirmation that stop future messages. That structure makes ownership, approval and later comparison easier—provided teams write the transcript from the actual configured journey rather than from marketing intent.

The transcript is a release contract

A release contract describes what the system is allowed to do at a specific version. For RCS, that includes whether the first message is application-to-person or user-initiated, where consent is obtained, which backend event fires the communication, which branches and suggested actions appear, and what happens after STOP. Google asks submitters to align those descriptions with the declared use case. RevOps should preserve that alignment as an internal control even after approval.

Give every packet an agent identifier, use-case label, configuration version, owner and effective date. Reference the source workflow, templates and opt-out configuration used to produce the transcript. If one launch submission covers only part of a multi-use design, keep the stated boundary visible. This prevents a later promotional branch from inheriting the authority of an earlier transactional approval without review.

Text is only better when it is testable

A vague transcript is not safer than a video. Phrases such as 'the customer receives updates' hide the trigger, timing and message content. Google asks teams to identify the specific user action or backend event, show step-by-step interaction paths and provide the exact opt-out confirmation. Internally, the packet should also include test inputs, expected outputs and a pointer to the observed result for each primary and common alternative journey.

Run the transcript against a controlled test identity. Verify the entry event, customer match, message content, links, suggested actions, handoff behavior and STOP state. Capture exceptions when a field is missing, the user is not eligible, delivery fails or a downstream system is unavailable. The approved document should reflect the testable system, not an idealized happy path.

Retention matters after launch

Google's launch guide says the questionnaire cannot be edited after submission. That makes internal version retention more important. Store the submitted packet, approval evidence and deployed configuration together. When copy, triggers, rich elements, use case or opt-out behavior changes, record whether a new channel review is required and re-run the relevant acceptance tests.

Do not overwrite the original transcript with a current-state document. Keep an immutable approved version and a separate proposed revision. If an incident occurs, investigators need to know which journey was authorized and configured at that time. A continuously edited page cannot answer that question.

Evidence must travel across teams

Lifecycle Operations may assemble the journey, Product or Engineering may own the backend trigger, Legal or Privacy may review consent, Support may receive handoffs and RevOps may own identity or CRM fields. The transcript is valuable because it gives those teams one inspectable representation of the customer experience. The workflow should still link back to each authoritative system rather than copying every detail into one document.

Assign sign-off by responsibility. Engineering confirms the trigger and state changes; Lifecycle Operations confirms messages and paths; Privacy confirms consent and opt-out requirements; Support confirms handoff; the business owner confirms the declared use case. Approval should record the evidence reviewed, not just a name beside a date.

Use both formats when consequence is high

Google permits either video or transcript for Google-managed launches, but teams do not have to treat that as an exclusive internal choice. A transcript is better for review, diffing and control. A short recording can reveal timing, visual order and client behavior that prose misses. For a high-consequence journey, pair the controlled transcript with a targeted video and keep both under the same version.

Build the diff into release review

Before approval, compare the proposed transcript with the last approved version. Classify every change as copy, trigger, routing, data, action, consent or opt-out. A copy-only edit can still change a promise; a routing edit can change who sees customer context; a data edit can change what is revealed. The reviewer should see the changed line, the source-system change behind it and the acceptance test that covers it.

After deployment, run a production read-back using a permitted test identity. Confirm that the observed first message, branches, suggested actions and STOP response match the approved packet. Record the deployment identifier and test time. This closes the gap between what was submitted and what is actually live without treating channel approval as proof of correct implementation.

The important change is not that launch evidence became easier. It became possible to express the required customer experience in a form that can be reviewed like a specification. RevOps should take advantage of that. A launch transcript belongs beside the workflow definition, test result, consent evidence, approval and production read-back—not buried as temporary text in a submission form.