ChatGPT
Claude
Google AI
Copilot
A service director hears that the Fin acquisition has closed and schedules a weekend cutover. Every conversation, in every channel, will move onto Fin. The existing Service Cloud agent will stay on "as a safety net". The slide has a containment rate in the corner. Nobody has said which agent speaks when both are listening. That design fails in three ways at once. Fin is not automatically inside every Service Cloud org. Every conversation is the wrong scope. Two agents must not both own the conversation.
Should you migrate
Not every conversation, and not because the deal closed. Do not migrate every conversation onto Fin. A conversation is a thread with a customer, a channel, a history, and a person or an agent who is allowed to answer. Moving all of them in one weekend treats those differences as noise. They are the design. A billing dispute and a password reset do not have the same owner merely because both arrived in a chat window.
A narrower move can be honest. You name a queue, or a class of intent, that Fin may answer. You name the conversations that stay with the agent or the team you already run. You name the moment a human must be offered. You do that in a document that names one owner per conversation. If you cannot name the owner, you are not ready to move anything. Readiness is not a date on a cutover calendar. Readiness is the sentence "this conversation belongs to X, and not also to Y".
Check the org before you promise the move. Fin is not automatically inside every Service Cloud org. If you cannot find it, the absence can be consistent with the close. The completion says the company was bought. It does not say your tenant woke up with a new agent. Look at the contract. A weekend plan that assumes the feature is present will spend the weekend discovering that it is not.
The walkthrough people want is a channel-by-channel switch. The walkthrough this page allows is a list of conversation types, a single owner for each, and a rule for the handoff. A step that says "point all traffic at Fin and leave the old agent running" is the step you strike. That step is two owners. Two owners produce two replies, or a silence while each waits for the other, or a customer who is told two different things. Strike it even if the project plan calls the overlap temporary. Temporary overlap is still two owners.
What Fin is now
The sentence this page quotes from the investor release is: "Salesforce today announced it has completed its acquisition of Fin, formerly Intercom, an industry-leading customer agent company." "Today" in that sentence is the day of the release. The completion date is 10 September 2026. Fin, formerly Intercom, is the company named. The praise inside the quotation stays inside the quotation. This page does not repeat it as its own description.
Fin's customer-agent platform joined Salesforce. The release says Fin will keep serving its customers as part of AI Labs. Those are statements about the company and its existing customers. They are not a statement that a Service Cloud org which never bought Fin now includes it. Your contract, your invoice, and your admin login may still say Intercom, or Fin, or both. Follow the paper you signed. Do not follow a headline into a cutover you have not been offered.
Ask which company you are before you write a plan for everyone. A team that already runs Fin or Intercom still checks the contract. A team that only has Service Cloud may have nothing to switch on. There is no containment rate in the release this page uses. Do not migrate in order to chase a percentage. This page does not publish a purchase price, a licence fee, or a shutdown date. Owning the company is not your price list. An end date for Fin, or for the Intercom name, is not in this source. Do not invent one so the cutover feels like an escape from a dying tool. If you are an existing customer, your notice of change will be a notice, not a guess this guide made.
One owner for the conversation
Two agents must not both own the conversation. Ownership means one party is responsible for the next reply, for the record of what was promised, and for the decision to involve a human. When two agents both believe they own it, the customer gets a race. When neither believes they own it, the customer gets silence. The acquisition does not choose the winner between Fin and the Service Cloud agent you already configured. You choose, in writing, before traffic moves.
Write the rule as a partition, not as a priority. "Fin owns password resets on the web chat. The existing agent owns everything else. A human owns anything either agent flags." That partition can be tested. "Fin is primary and the other agent is backup on all channels" cannot. Backup, in production, answers anyway. Primary and backup are two owners with a story about deference. Deference fails when both have a confident answer.
The handoff is part of the partition. If Fin must stop and a person must start, the conversation has one owner at each moment, and the moment of transfer is explicit. The customer should not have to repeat the account number because a second agent began from an empty prompt. The record of the transfer sits on the case, if a case is your system of record. A chat transcript that never becomes a case is a poor place to discover, next month, who promised a refund.
Do not migrate history blindly. Past conversations are a retention question. Loading every old thread so an agent can learn a tone copies text you may not have a right to move. If you move history, name the date range, the channels, and the person who accepted the privacy review. "All of it" is not a date range. Do not run an old workspace and a new Fin path against the same queue to see which is better. That test is two owners.
Versus native features
Service Cloud already gives you cases, queues, a console, and the agent you may already have configured. Those are native to the org that has them. They answer, or they help a person answer, under the entitlements you bought. Fin, on this record, is a customer-agent platform that joined Salesforce and is not assumed present in every service org. Native service features do not become Fin because the companies share an owner. Fin does not become the console because the console is where agents sit.
A case has an owner field. A conversation needs the same clarity. One owner, a queue when nobody has it yet, a transfer that changes the field. Do not invent a vaguer rule for chat. This page does not rank Fin against the Service Cloud agent, or against a human team. Ranking would require a rate and a scope this source does not provide. Some queues should stay with people because the cost of a wrong answer is high. Some queues may suit an agent you already run. Some may suit Fin, if your contract includes it and you have named the queue. The table does not sort those choices. It stops the choice "all of them, to both agents".
| Job | What this record says about Fin | What native service features already do | What you still write |
|---|---|---|---|
| Answer a conversation | A customer-agent platform, not auto-included | The agent or the person you already staff | Whether this org even has Fin |
| Own the next reply | Not a reason to keep two agents live | A case has one owner | One owner per conversation type |
| Move every thread | Not in the release | History sits where you stored it | A named slice, or a refusal |
| Hit a containment rate | No rate is published here | Reports show the work you define | A definition, later, if you still need a number |
If the first cell of a row is "we have not checked the contract", you are not in a migration. You are in a rumour. Check the contract. Then come back to the owner column.
Alternatives, with no order
An AppExchange search for a Fin alternative expects a listing and a rank. This page does not name a listing, a publisher, or a rank. It will not name a chatbot package to install instead. The options are operating choices. They sit side by side.
Keep the Service Cloud agent or the human team you already run, and do not add Fin to the same queue. That option fits when your contract does not include Fin, and it also fits when it does but you have not written the owner rule. Staying is a decision. It is not a delay.
Move a named slice of conversations to Fin, with one owner, if the contract includes it. That option fits a queue you can describe in a sentence, with a handoff to a person. It is not every conversation. The rest stay where they are until you write the next sentence.
Keep Fin, if you are already a Fin or Intercom customer, and do not also route the same threads to a second agent because Salesforce now owns the company. That option fits existing customers. The close did not instruct you to dual-run. Your contract and your owner rule still govern.
Wait. Waiting is right when the slide is a rate and a weekend date, and the owner column is blank. Nothing in the release starts a clock on your queues. A later decision can still name a slice. An early decision that names every channel will be the one you undo in front of customers.
A partner who ranks these options, or who leads with a containment percentage, is selling a leaderboard. Ask for the owner rule on one queue you name. If they cannot write it without the percentage, they are not ready to touch the routing. This page will not order the options for you. Your channels are not their catalogue.
What the walkthrough contains
The walkthrough is a routing decision, not a content dump.
Confirm the contract. Is Fin, or Intercom, something you have bought. If the answer is no, stop. Do not open a migration to a product the org does not have. If the answer is yes, name the workspace and the admin.
List conversation types, not "all conversations". Each type has a channel, an example, and one owner. The owner is Fin, the existing agent, or a human queue. Not two of those.
Write the handoff. What the customer sees. What is written on the case. What the second party receives. If there is no second party, say that ownership does not transfer.
Write five types that must not move in the first change. Complaints. Refunds above a threshold you set. Anything already owned by a person. A channel you have not staffed for the failure mode. A type you cannot define. These are refusals, not a backlog.
Write the history rule. What, if anything, is copied, from which date, under whose privacy acceptance. Default to copying nothing until that sentence exists.
Strike the rate. If a later report is required, define the denominator first. Do not let the denominator be "every conversation we could find".
There is no fee on this page and no ranking of implementers. A quote that prices "full migration onto Fin" has priced the scope this page told you to refuse. Send it back for a price against one queue, or do not buy it.
Where the other pages fit
The implementation page holds the agent, the queue, and the refusal to invent a rate: Fin, formerly Intercom, after the acquisition closed. Go there when the owner rule exists and you are configuring the slice. Do not go there for a containment number.
What happened, the date, the missing price, and the missing end date are on what happened to Fin. Stay there when the question is the acquisition. Leave it when the question is which conversations move.
The integration page is the path from a channel to a single owner: integrating Fin with Salesforce. Read it when someone wants a connector diagram. The diagram still shows one owner. A second agent on the same arrow is a defect, not a phase.
| Question | Where it belongs |
|---|---|
| Should we migrate? | This page. Not every conversation. Not onto two agents. |
| What is the software now? | Fin, formerly Intercom. Not automatic in every Service Cloud org. |
| Versus native? | Cases already have one owner. Chat needs the same clarity. No winner. |
| Alternatives? | Stay, move a named slice, keep an existing Fin workspace, or wait. |
The cutover weekend can come off the calendar today. Replace it with a single queue, a single owner, and a check that the contract includes the product. If the check fails, the queue stays with the team you already have. That is a successful outcome. A successful outcome does not require a migration. It requires one voice answering the customer, and a record of who that voice is.
