Comment by aurareturn
8 hours ago
But it will fail the second it needs to take action or deliver personalized information based on client's account data.
And why would Fin be better here? It's very easy to give your agent context on the customer.
In 2026, every time I've tried to build a custom tool to replace a SaaS, I've succeeded. The biggest problem with SaaS is that they build a one size fits all. When you build a custom tool, you control everything from data to UI and it works for your business.
Many, many people do not have the capacity to build and maintain custom solutions (whether in-house skills, or simply bandwidth) and therefore outsource to vendors.
It's an incredibly common aspect of business. Enterprise level contracts often include the sort of white glove service to help fill in these sort of gaps. On simpler plans, having the tooling provided frees up just enough capacity to handle the exceptions to keep the process running smoothly (since one doesn't have to build and run simultaneously).
Sometimes people want to minimize the hassle with stuff. It's why car washes and oil change places and coffee shops exist.
For the last 15 years, I'm that person in the company who always said "let's not build it ourselves".
In the last 6 months, I'm that person in the company who always said "let's just build it in a few days".
I agree with you 100%. Fin and products like this simply do NOT solve the hard part of providing support in 2026. Basically, the hard parts are (1) coming up with the tools for agents to use, like searching for data, making updates, etc. (2) reviewing the logs of actual usage and adjusting prompts, docs, tools based on the real feedback. (3) tuning human escalation procedures.
This process is an ongoing effort, with an upfront engineering commitment which depends entirely on the product, but can be months of work. But if you have your own backend, I would argue this hard works is made HARDER by implementing something like Salesforce/Fin, because you have to now pipe a bunch of data and structure over to them, which is a pain.
LLM models capable of doing this are a commodity, the UI for customers and support teams is pretty trivial, the database/backend is trivial.
Outside of some cases, if you have your own app, and you have a given support volume, build your own.
1 reply →