I start a support-agent decision with your tickets. How many need an order lookup? How many need a policy answer? How many require a person to approve a return?
A headline price cannot answer those questions. Neither can an acquisition announcement. Salesforce agreed to acquire Fin, formerly Intercom, for approximately $3.6 billion in June and announced completion on 10 September 2026. That is relevant to procurement, but it does not decide whether the product fits your store.
The buy side: separate the outcome charge
Fin’s advertised starting rate is $0.99 per outcome. On Intercom plans, usage sits alongside seat charges. Fin with an existing helpdesk has a minimum monthly commitment; the pricing page gives 50 outcomes as an example, rather than a universal minimum. That option lists no seat, setup, integration or platform fees from Fin. Your existing helpdesk and any implementation work still need a budget.
Here is the arithmetic at $0.99, assuming that rate applies to every billed outcome:
Comparison table — scroll horizontally to see all columns
| Outcomes per month | Outcome charges per month | Outcome charges per year |
|---|---|---|
| 300 | $297 | $3,564 |
| 1,000 | $990 | $11,880 |
| 3,000 | $2,970 | $35,640 |
| 5,000 | $4,950 | $59,400 |
These are calculations, not quotes for the complete service. Fewer support requests can reduce the number of billed outcomes. A negotiated rate can change the calculation too.
I also check the billing definition against the workflow. A handoff can be billable. Silence after an answer is not proof that the customer was satisfied.
The build side: include the running costs
For a custom agent, I budget five things:
- The initial implementation and integrations.
- Hosting and model usage at the expected ticket volume.
- Monitoring, evaluation and maintenance.
- Changes to store systems, policies and access rules.
- Human review and escalations.
Traffic growth can increase model and infrastructure costs. A build is not a promise of an unchanged bill.
The reason to build is control over a specific workflow. I might need a particular approval step, a restricted data source or an audit record that the chosen product cannot provide. I establish that gap before quoting engineering.
Test both against the same tickets
Bought agents can read external systems and hand off to people. Those are not exclusive advantages of custom software.
I use the same ticket sample for both options. I check answer quality, permissions, escalation context, failure handling and total cost. The request-processing pattern with human review explains the approval boundary; the intake situation shows a related workflow.
There is no universal ticket-volume threshold where a build wins. A small store may have a difficult integration. A busy store may be well served by an existing product. A hybrid is another option, provided the handoff is clear and its costs are counted.
How I can help
I can compare the workflows and build the missing integration under API integrations and automation. If the task is clear, I can quote implementation directly. If we first need to inspect ticket types and data access, we agree a separate diagnostic engagement.
