One of the most common requests we got in the early days was: "Can your AI just answer questions from our help docs?"

We said no.

Every AI support company we know of started there. Embed the help center, wire up a chat widget, generate answers from documents. It ships fast. The demo looks good. Customers see an AI that "knows" their product. Investors see a company that can land deals in weeks.

We understood the appeal. We built prototypes that worked this way. And we watched what happened when real customers used them.

Why chatbots are the default

The economics make sense on paper. A company has hundreds of help articles. Customers keep asking the same questions. A chatbot that can surface the right article in conversational form saves the support team from repeating themselves.

The setup cost is low. You point the system at your knowledge base, it indexes everything, and within a day you have a bot that can answer "What are your business hours?" and "Do you ship internationally?" with high accuracy.

This is the product most AI support vendors sell. The pitch varies, the underlying architecture does not. Retrieve a document, generate a response, hope the customer goes away satisfied.

For informational questions, it works. The problem is that informational questions are not why customers contact support.

What customers actually need

Most customers who contact support are not asking informational questions. They are asking about their account, their eligibility, their specific situation. "Am I eligible for a refund?" "Why was I charged twice?" "Can I upgrade mid-cycle?" These queries require looking up real customer data, evaluating policy against that data, and often taking an action at the end.

A chatbot trained on help articles can answer "What is your refund policy?" It cannot answer "I bought this 45 days ago on my annual plan, can I still get a refund?" because that requires pulling the customer's purchase date, checking their plan type, evaluating the policy conditions, and calculating a prorated amount. The chatbot either guesses or gives a generic response that may not apply to their situation.

The gap between what chatbots handle well (informational queries) and what customers actually ask (account-specific, policy-dependent, action-oriented) is where most support volume lives. And it is exactly where document-based AI falls short.

The squeeze

Chatbots face pressure from two directions.

On the simple end, static help centers are getting better. Improved search, better content structure, AI-generated summaries at the top of articles. For purely informational queries, a well-organized help center with good search is often faster than a conversation with a chatbot. The chatbot adds a conversational layer to a problem that a search bar already solves.

On the complex end, customers need actions, not answers. They need refunds processed, accounts updated, subscriptions changed, billing errors corrected. A chatbot that can only generate text is stuck explaining what it cannot do. The customer reads a beautifully worded response about refund eligibility and then opens a ticket with a human agent to actually get the refund.

The middle ground where chatbots add clear value, questions too nuanced for a help center search but not complex enough to require system access, is narrower than it appears. And it is shrinking as help centers improve and customer expectations rise.

What we build instead

Fini is not a chatbot. It is an execution engine with a conversational interface.

When a customer asks "Am I eligible for a refund?", Fini does not search for a refund policy article. It pulls the customer's purchase history from the billing system, evaluates their eligibility against the refund policy encoded as executable logic, calculates the exact refund amount if eligible, and returns a specific answer: "Yes, you are eligible for a prorated refund of $47.30. Would you like me to process it?"

If the customer says yes, Fini calls the payment API and processes the refund. The customer receives confirmation with a real transaction ID.

The difference between generating a response and executing a resolution is the difference between a brochure and a service desk. One describes what could happen. The other makes it happen.

The tradeoff

We do not pretend this is easier to build or easier to deploy.

A chatbot can go live in a day. You point it at your docs and it starts answering. Fini requires encoding your business rules, connecting to your backend systems, mapping your policy surface area, and testing against real scenarios. That is real configuration work that takes days, not hours.

We also cannot handle every question from day one. A chatbot trained on your full help center has broad coverage immediately, even if shallow. Fini starts with the queries it can resolve end-to-end and expands from there. The coverage curve starts lower and grows steeper.

We think this tradeoff is correct. A chatbot that covers 100% of questions at 72% accuracy on the hard ones creates a specific kind of problem: customers who receive wrong answers and do not know it. An execution engine that covers 78% of tickets at 98% accuracy on policy questions creates a different outcome: customers whose problems are actually solved.

Why we think chatbots will compress

Two things are happening simultaneously.

Help centers are absorbing the informational layer. Zendesk, Intercom, and Freshdesk are all shipping AI-enhanced help center search. The simple question that a chatbot answers today will be answered by the help center directly tomorrow. The chatbot loses its easiest wins.

Customer expectations are moving toward action. Customers who interact with AI in banking, food delivery, and ride-sharing apps are getting used to AI that does things: cancels orders, reroutes packages, processes refunds. When those customers encounter a support chatbot that can only explain policy but cannot act on it, the experience feels broken.

The chatbot sits between two converging forces. Simple queries move to self-service. Complex queries demand execution. The remaining space for "conversational answer from documents" is real but small, and it does not justify the price most vendors charge for it.

Where we are going

We are building for a future where AI support means AI resolution. The customer describes a problem, the system diagnoses it against real data, applies the correct policy, and takes the appropriate action. The human agent handles exceptions, edge cases, and situations that require judgment the system does not yet have.

Our production deployments resolve 70-85% of tickets end-to-end. That number will grow as we encode more policies, connect more systems, and expand the action space. But it will grow by doing more, not by answering more.

We could have built another chatbot. It would have been faster to market, easier to sell, and simpler to deploy. We would also be competing with every other AI support vendor on the same axis: who generates better text from better documents.

We decided to compete on a different axis: who actually solves the customer's problem.