A support bot’s answer can depend on several pieces of material maintained by different people. A client may own the policy, a provider may maintain the help content and a supervisor may decide when a conversation should reach a person. A change to one piece can leave the others out of step.
Intercom’s November 5, 2026 announcement introduces Releases for Fin. It describes bundling content, guidance, escalation guidance and procedures in a separate preparation space, previewing and testing the bundle, and choosing a rollout audience or conversation share. The announcement also describes A/B comparison against Main Fin. These are vendor-described capabilities, with actual availability and configuration to be checked in the team’s workspace. Intercom’s Fin Releases announcement
Agree on the change as a complete service decision
Imagine a fictional equipment-rental company changing how customers report a missing accessory. The new process asks for the rental reference and a description before sending the case to a depot. The client approves the information to request. Its outsourced support provider updates the instructions and tests the conversations.
The release review should consider the help article, the bot’s questions and the depot handoff together. A revised article may be accurate while the conversation still follows an older route. Ask the reviewer to trace the customer’s path through the complete proposed change.
Name the person who accepts that path for the client and the person responsible for preparing it at the provider. If approval depends on a depot manager’s decision, record that dependency before the team chooses a launch time.
Test the ordinary request and the awkward one
For the rental example, test a customer with a valid reference and one who cannot find it. Include a case where the item was returned already and the customer is asking about a charge. The team can then see whether the same wording sends different needs to an appropriate next step.
Keep a small set of previously accepted conversations as well. A new procedure may affect a nearby topic that the builder did not intend to change. Review the actual answer and handoff, including any information the receiving person needs.
When a test reveals a problem, update the bundle and test the changed path again. The acceptance record should identify the version reviewed so the approval refers to the material that will actually be released.
Choose what the rollout will establish
A limited audience can give the team a manageable set of live conversations to examine. Decide who reviews those conversations, what evidence supports expanding the rollout and which findings require a repair.
For the equipment-rental change, the review might examine whether the depot receives enough information to continue and whether customers with a different problem reach the right team. Use measures that reflect the intended service outcome, alongside any platform metrics the parties already trust.
Close the loop between client and provider
After release, record what went live, who accepted it and what the first review found. If the provider maintains the instructions, give the client a clear way to request a correction and understand its status.
Releases provides a current product example of grouping support changes. The operating agreement supplies the shared decision about when that group of changes is ready for customers.
AI-generated conceptual editorial image; fictional service-team review, not actual Fin customers or a product interface.