EzyConn

The indexing is quick. Point it at a website address or a help centre and it crawls what is there and builds its own index without anybody writing an answer bank first. What actually sets the date is the decision nobody thinks of as work: where the line sits between an answer it sends and a conversation it hands to a person. Teams that pick a threshold on day one and read the handover queue for a fortnight get somewhere useful faster than teams that spend that fortnight refining prompts, because the queue tells you what the documentation is missing and no amount of prompt work will.

It goes to a person, with the full conversation attached, rather than being guessed at. That handover is the part of the product worth caring about most: an assistant that answers everything confidently is not better than one that stops, it is worse, because the wrong answers arrive at customers with the same certainty as the right ones. Below the confidence threshold you set, the conversation moves to the shared inbox with what it found and why it hesitated, so the person picking it up is not starting from a blank screen and the customer is not asked to explain themselves twice.

No, and a product sold on that promise is one to be careful with. What it removes is the same twenty questions arriving in four different places with no record of which were dealt with. What it does not remove is judgement, an angry customer, a refund decision, or anything where being wrong is expensive. In practice teams find the volume drops and the difficulty of what remains goes up, which is a real change worth planning for: the queue your team is left with is harder than the one they had, and the people answering it deserve to know that in advance.

Only if the index is stale, which is why re-crawling matters more than it sounds. The answer comes from what you published, so a policy you changed last week is the policy the customer hears about once the crawl has caught up. The failure worth guarding against is the opposite: a page you deleted still sitting in the index and being quoted back at a customer as current. Set the crawl frequency against how often your material actually changes, and treat a content change and a re-crawl as one task rather than two.

Yes, and the shared inbox is the reason it is worth doing. Website chat is a script tag in your page. Teams and Slack connect rather than embed, so staff answer from the app they already have open all day instead of learning another one. WhatsApp, Messenger, email and SMS arrive in the same place. The value is not the number of channels, it is that a customer who asked on WhatsApp on Monday and emailed on Wednesday is one conversation rather than two strangers, which is the thing that stops people being asked the same question twice.

There is a free tier, so you can put it in front of real questions before anybody signs anything, and unlimited teammates on every plan, which means the bill does not grow every time you hire. Beyond that the running cost of this kind of product moves with how much text goes in and out rather than with headcount, so the controls are the ones you would expect: keep the retrieved context tight, cache the repeated questions, and watch the number from the first week rather than discovering it at the end of a month.

Your customer data is not used to retrain models, and the rest of the arrangement is on the page above rather than buried in a policy: encryption at rest and in transit, row level tenant isolation so one company's records cannot be reached from another company's session, automatic masking of card numbers and personal identifiers, audit logging so there is a record of who looked at what, and a retention window you choose. Support conversations carry home addresses, card details and complaints, which is exactly why this is stated plainly rather than summarised as enterprise grade.

That is what the visual workflow builder is for. You drag the path a conversation takes, and there is no code to write and no ticket to raise with us to change it. This matters more than it looks: routing rules are the thing that changes most often, usually because somebody left, a team was reorganised, or a product launched, and a product where that requires a developer is a product where routing quietly stops matching how the company actually works. The people who understand the routing should be able to edit it.