Support desk, chatbot builder, agency build or Helm: which one your inbox needs
Four ways to deal with an inbox that's grown past the team answering it. What each one does, what each one leaves to you, and when Helm is the wrong answer.
The short answer. A support desk organises work for your people to do. A chatbot builder gives you a tool to configure an assistant yourself. An agency builds something custom and usually hands it over. Helm builds, governs and runs one agreed workflow that finishes the job in your systems. Pick by asking who will still own the result six months from now.
The four options
A support desk
A shared inbox with tickets, assignment, macros, and increasingly an AI layer that drafts or suggests replies. Products such as Zendesk, Freshdesk or Intercom fit here.
Good for: a team that already answers well and needs order: queues, SLAs, reporting. Leaves to you: doing the work. The desk routes a booking request to a person. It doesn't hold the slot.
A chatbot builder
A self-serve tool. You upload your FAQ or connect your site, design flows, and put an assistant on your website, Instagram or WhatsApp. Chatbase, ManyChat and Botpress are examples.
Good for: a business with someone who has time to build and maintain flows, and questions that end with an answer rather than an action. Leaves to you: connecting the calendar, the payment link and the CRM, deciding what the assistant may never say, and noticing when it starts getting things wrong.
An agency build
A studio scopes and builds a custom assistant or automation, often on one of the platforms above, and hands it over.
Good for: a one-off, well-specified integration that your own team will maintain. Leaves to you: everything after launch. Prompts drift, templates get rejected, Meta's rules change. Our post on 1 October 2026 pricing covers the latest change.
Helm
Helm agrees one recurring workflow with you: what starts it, what counts as finished, and what the agent may decide alone. Helm then builds it, runs it in your channels, writes the result into your calendar, CRM or payment system, and reports one number agreed before the build. A named engineer stays on it after launch.
Good for: high-volume, repeatable work that ends in a transaction, such as a booking, a deposit, a qualified lead or a filed claim, where a wrong answer has a cost. Leaves to you: a named owner on your side for exceptions, and the inputs we ask for: the price list, the appointment book, the launch calendar.
The questions that decide it
- Does the conversation end in an answer or in an action? If it ends in an answer, a builder may be enough. If it ends in an action in a system of record, you need the action built and maintained.
- What must it never say? If you can't write that list down, nothing should be talking to your customers yet. Helm's pilot starts by writing it.
- Who notices when it goes wrong? A tool doesn't notice. Someone has to be accountable for the workflow.
- Which language does your customer write in? In Egypt and the Gulf, that means Egyptian or Gulf Arabic, often in Latin script, mixed with English in one message. Test any option on your own customers' messages, not on a demo script.
When Helm is the wrong answer
- Low volume. If a person can answer everything within the hour, a support desk and good habits are cheaper.
- Nothing to finish. If every question ends with «here is our website», a builder answering from your FAQ will do.
- No owner. If nobody on your side can own the exceptions, any automation will fail quietly. Fix that first.
- You want to build it yourself. That's a reasonable choice. A builder fits it better than we do.
If none of these apply, the first conversation with Helm is a diagnosis of one workflow, not a demo. Describe it here.
Helm builds the workflow that does this work in production, in your channels and your systems.
Start a workflow ↗All posts ↗