This guide separates the two, shows the published prices as of the date above, and works an example so you can estimate your own running cost. It does not quote HeliumSol's build prices, because those are set after a discovery conversation about your project, not in a blog post.

What are the two costs of an AI chatbot?

The build is everything it takes to put a chatbot in front of customers that answers correctly: collecting your content into a knowledge base, writing the rules it follows, connecting lead capture and human handoff, setting usage caps, adding the widget to your site, and testing it against the questions people really ask. This is paid once, like a website.

The running cost is what it takes to keep it answering: the AI provider's API usage, any hosting, and the time someone spends reviewing transcripts and updating the knowledge base. The API usage is the part people worry about, and it is the part that is easiest to calculate, because every major provider publishes it.

How are AI models priced?

Models are priced per token, in and out. A token is roughly three-quarters of an English word. "Input" is everything sent to the model for a reply: the rules, the relevant parts of your knowledge base, and the conversation so far. "Output" is what the model writes back. Output tokens cost more than input tokens on every model.

These are the standard per-million-token prices published by OpenAI and Anthropic on the date this was written. Both pages are linked; check them for current figures, because prices change.

The spread matters. The cheapest and the most expensive models on this list differ by a factor of one hundred on input and output. For a chatbot that answers questions about your business from your own content, the small models are usually the right choice, and the difference in cost is the difference between a bill you never notice and one you do.

How much does one conversation cost?

Here is a worked example. The assumptions are ours, stated so you can change them.

Assume a conversation of six exchanges. Each time the model replies, it is sent the rules, a few relevant passages from your knowledge base, and the conversation so far. Say that adds up to 10,000 input tokens across the whole conversation, and the model writes 1,500 output tokens in total.

• Claude Haiku 5.5: 10,000 input tokens at $0.10 per million is $0.001. 1,500 output tokens at $0.50 per million is $0.00075. About $0.002 per conversation.
• gpt-5.4-nano: $0.002 for input plus about $0.0019 for output. About $0.004 per conversation.
• Claude Sonnet 5.5: $0.02 for input plus $0.015 for output. About $0.035 per conversation.
• gpt-6-astra: $0.10 for input plus $0.075 for output. About $0.18 per conversation.

At 1,000 conversations a month, that is roughly $2 on Haiku 5.5, $4 on gpt-5.4-nano, $35 on Sonnet 5.5, and $180 on gpt-6-astra. Most small business sites see far fewer than 1,000 chatbot conversations a month, and long conversations cost more than short ones because the whole exchange is re-sent each turn.

Two things lower these numbers further. Anthropic's pricing page lists a Batch API with "a 50% discount on both input and output tokens", which suits background work rather than live chat, and reduced prices for cached prompt content: on Claude Opus 5.5 and Sonnet 5.5, "cache hits and refreshes" are priced at 0.05 times the base input price. OpenAI's pricing page lists a separate "cached input" rate for most models, for example $0.02 per million for gpt-5.4-nano against $0.20 for standard input. A chatbot's rules and knowledge base are exactly the kind of repeated content caching is designed for.

What does the build cost depend on?

No published figure here, because an honest one does not exist without knowing the project. What moves the price:

• How much of your knowledge is written down. A site with clear service pages and an FAQ is fast to prepare. A business where the answers live in the owner's head needs a writing phase first, which is the most valuable part of the work and the slowest.
• Where it runs. A website widget is standard. Other channels add integration work.
• What it connects to. Sending a lead to an inbox is simple. Creating a CRM record, checking a calendar, or looking up an order means building and permissioning tools, which moves the project toward an AI assistant solution.
• Handoff. A join link or email to the team is included in a typical build; routing into a ticketing system is extra.
• Consent and compliance. If the chatbot collects phone numbers for SMS follow-up, consent wording and record-keeping are part of the scope.

HeliumSol's AI chatbot development page lists what a build includes. The price for yours comes after a short discovery call.

What are the hidden costs?

• Hosting. Close to nothing, if the chatbot runs on the same server as your website. It is a small service, not a separate platform.
• Knowledge upkeep. Someone has to update the content when your hours, services or policies change. This is minutes of work, but it is not zero, and a chatbot with stale content does damage.
• Human time on handoffs. A good chatbot sends you conversations it could not finish. That is the point, but the people receiving them need to respond.
• Review. In the first weeks, reading transcripts and fixing weak answers is where most of the quality comes from. Budget an hour a week, then less.

How do you keep the running cost predictable?

Three controls, all of which HeliumSol builds into every chatbot:

1. A monthly token cap. The chatbot stops calling the model when the cap is reached and falls back to a contact form, so a surprise bill is impossible.
2. A per-visitor rate limit. One person, or one script, cannot run hundreds of conversations in an hour.
3. A small model by default. Routine questions about your business do not need a flagship model. The chatbot on this site uses a small model and a strict set of rules; the rules are what make it safe, not the size of the model.

Upgrading to a larger model is a configuration change, not a rebuild, so you can start cheap and move up if transcripts show the answers need it.

Is an AI chatbot worth the cost?

That depends on what it replaces. If the same twenty questions arrive by phone and email every week, a chatbot that answers them around the clock and captures the details of people who want to go further is doing work someone currently does by hand, or that currently goes unanswered after hours. If your enquiries are rare and unique, a chatbot adds little, and the honest advice is to skip it.

HeliumSol does not promise a number of leads or a saving, because nobody can. What it can show is the transcript log: how many conversations happened, what people asked, how many left their details, and how many asked for a person. That is the evidence to judge the cost against.

If you want to see the running cost in practice before committing to a build, the free website and chatbot offer includes a knowledge-base chatbot with API usage covered for the first month; what the free chatbot includes lists its limits. For what a chatbot can and cannot do for a small team, read AI chatbot for small business, and for the support side, AI customer support chatbot.

Sources

• OpenAI, API pricing: developers.openai.com/api/docs/pricing
• Anthropic, Pricing: platform.claude.com/docs/en/about-claude/pricing

Prices quoted are the standard per-million-token rates shown on those pages on the publication date of this article.

This guide defines both, explains how "tool use" works using the providers' own documentation, and gives a way to decide which one you need.

What is a chatbot?

A chatbot is a conversation interface in front of a language model. The useful kind for a business is grounded: it is given your content (pages, documents, FAQs, policies) and a set of written rules, and it answers from that material rather than from general knowledge. It can collect a visitor's details and hand the conversation to a person. It cannot change anything in your systems.

That limitation is a feature. A grounded chatbot can be put in front of customers with little risk, because the worst it can do is give an answer that is wrong, and good rules make it say "I don't know, let me get a person" instead. HeliumSol's AI chatbot development page describes what goes into one; the assistant on this site is an example.

What is an AI assistant?

An AI assistant is a chatbot that has been given tools. The model is told, in plain language, what each tool does and what it needs, and it can ask your application to run one as part of answering.

The providers describe the mechanism directly. Anthropic's documentation says: "Tool use (also called function calling) lets Claude call functions that you define or that Anthropic provides. Claude determines when to call a tool based on the user's request and the tool's description. It then returns a structured call that your application executes." (Tool use with Claude)

OpenAI's guide puts it as: function calling "provides a powerful and flexible way for OpenAI models to interface with external systems", and lists examples of what tools can do: "Get today's weather for a location", "Access account details for a given user ID", "Issue refunds for a lost order". (Function calling)

Those three examples cover the whole range: a harmless lookup, a lookup of private data, and an action with financial consequences. The engineering of an assistant is deciding which of those it may do, and under what supervision.

How does tool use actually work?

The round trip is the same across providers, and it matters because it shows where control sits.

1. Your application sends the model the conversation plus a list of tools, each with a name, a description and the fields it needs.
2. The model decides whether a tool is needed. If so, instead of a plain answer it returns a structured request: the tool's name and the values to call it with.
3. Your code runs the tool. The model never touches your database or your calendar. It asks; your application decides whether to act, acts, and sends back the result.
4. The model uses the result to write the reply.

Anthropic's documentation describes exactly this for client tools: the model "responds with stop_reason: "tool_use" and one or more tool_use blocks. Your code executes the operation and sends back a tool_result." Step three is where permissions, approval steps and logging live. An assistant is only as safe as what your application does at that step.

Chatbot or assistant: the comparison

Which one does your business need?

Ask what the conversation needs to end with.

You need a chatbot if the job is answering: hours, services, process, policies, what is included, how to get started, and collecting the details of someone who wants to go further. This covers most service businesses, most practices and most small shops. See AI chatbot for small business for what that looks like day to day.

You need an assistant if the conversation regularly stalls on something only your systems know, or ends with a task a person currently does by hand: "where is my order", "is Thursday at 3 available", "cancel my appointment", "send me the invoice again". Each of those is a tool: a lookup or an action with a clear rule. HeliumSol's AI assistant solutions page describes how they are scoped.

You need people, not either, if the conversation needs judgement, empathy or negotiation: complaints, disputes, bespoke pricing. A chatbot or assistant can collect the facts and hand off well, and that is the most it should do.

What are the risks with an assistant, and how are they managed?

Giving a model the ability to act creates three risks: it acts when it should not, it acts with the wrong values, or it is tricked into acting by a visitor's message. The controls are not exotic.

• Narrow tools. A tool that reads one customer's own bookings is safer than one that queries all bookings. Scope each tool to the minimum.
• Read before write. Lookups can run automatically. Actions that change something, especially with money attached, wait for a person until trust is earned. Workflow tools support this pattern directly; n8n's documentation, for example, describes a workflow that lets you "require human approval before an AI Agent runs a tool" and another that triggers "a human answer when the AI can't help" (n8n AI examples).
• Logging. Every tool call is recorded with its inputs and result, so what the assistant did is never a mystery.
• Rules that treat visitor text as data. A visitor may paste instructions trying to override the assistant. The rules say such text is to be read, not obeyed.
• A route to a person in every conversation. Not as a last resort, but as a designed path.

What does each one cost?

Running cost for both is mostly the model's per-token price, which is published and small per conversation; what does an AI chatbot cost works through it with current prices. An assistant adds whatever your own systems charge for API access, which is usually nothing for tools you already pay for.

Build cost is where they differ. A chatbot is knowledge, rules, a widget and a handoff route. An assistant is all of that plus each tool: built, permissioned, tested with bad inputs, and logged. HeliumSol prices both after discovery, and will say if the honest answer is that you do not need tools yet.

What is the practical path?

Start with the chatbot. Get the knowledge base right, watch the transcripts, and note where conversations stall because the assistant cannot see your systems. Those stalls are your list of tools, in priority order, with evidence. Add the first one or two, with approval steps, and expand as the log shows they behave.

That is the order HeliumSol follows, and it is the order the free website and chatbot offer is built around: a grounded chatbot first, with API usage included for the first month, and tools when the answers have earned them. For the support use case specifically, see AI customer support chatbot; for the automation behind the tools, what can you automate with n8n.

Sources

• Anthropic, Tool use with Claude: platform.claude.com/docs/en/agents-and-tools/tool-use/overview
• OpenAI, Function calling: developers.openai.com/api/docs/guides/function-calling
• n8n, AI examples (human-in-the-loop and human fallback): docs.n8n.io/build/integrate-ai/ai-examples/

This guide explains the three metrics in plain language, quotes Google's own documentation for the thresholds and the ranking relationship, and ends with the questions to ask whoever builds your website.

What are the three Core Web Vitals?

Google's web.dev documentation names three stable metrics and a threshold for each (Web Vitals):

Largest Contentful Paint (LCP) "measures loading performance." In practice it is the moment the biggest thing in the visible part of the page appears: the hero image, the headline, the first block of text. Google's guidance: "LCP should occur within 2.5 seconds of when the page first starts loading." The LCP article adds that "poor values are greater than 4.0 seconds," and "anything in between needs improvement." (LCP)

Interaction to Next Paint (INP) "measures interactivity." It watches every tap, click and key press during a visit and reports how long the page took to respond visibly. "An INP below or at 200 milliseconds means a page has good responsiveness"; above 500 milliseconds is poor. INP is "the successor metric to First Input Delay (FID)", which it replaced. (INP)

Cumulative Layout Shift (CLS) "measures visual stability." It scores how much visible content moves unexpectedly while the page loads: the button that jumps just as you tap it. "Good CLS values are 0.1 or less. Poor values are greater than 0.25." (CLS)

Which visitors count? The 75th percentile

The thresholds are not applied to your fastest visit or your average visit. Google's guidance is that "a good threshold to measure is the 75th percentile of page loads," segmented by mobile and desktop (Web Vitals). In other words, three out of four real visits must be under the threshold. A page that is fast on the developer's laptop on office Wi-Fi and slow on a customer's phone in a car park is a slow page.

Do Core Web Vitals affect Google rankings?

Google's Search Central documentation answers this carefully, and it is worth quoting rather than paraphrasing: "We highly recommend site owners achieve good Core Web Vitals for success with Search," and good Core Web Vitals, "along with other page experience aspects, aligns with what our core ranking systems seek to reward." (Understanding Core Web Vitals and Google search results)

So they are not a switch that moves a page from position ten to position one, and Google does not describe them that way. They are one part of page experience, which Google's ranking systems try to reward. A business should treat them as a hygiene standard: a reason not to lose ground, rather than a trick to gain it.

Why do they matter for enquiries, not just rankings?

Rankings bring a visitor to the page. The Vitals describe what happens next. A hero that takes four seconds to appear on a phone is four seconds of a blank or half-drawn screen, during which the visitor decides whether to wait. A "Call now" button that shifts down as an image loads above it is a mis-tap. A form that pauses half a second after each keystroke feels broken.

None of that needs a statistic to understand. The thresholds Google publishes are a reasonable description of the point at which a page starts feeling slow or unreliable to a person, and the visitor who gives up at that point is an enquiry you paid for, through ads or content, and did not receive.

How do you measure your own site?

Google's Search Central page points to "the Core Web Vitals report in Search Console," which shows how real visitors experience your pages, grouped as good, needs improvement or poor (Core Web Vitals). It requires that your site is verified in Search Console and has enough traffic to report on. For a single page, Google's PageSpeed Insights tool reports both field data from real visitors, where available, and a lab test.

Two habits make the numbers useful. Look at mobile, because that is where the thresholds are hardest to meet and where most local-business visitors are. And look at the 75th percentile, not the lab score alone; a lab test is one run on one machine.

What makes LCP slow, and how is it fixed?

Google's guide to optimising LCP (Optimize LCP) breaks the problem into parts. The ones that matter most for a business site:

• The server is slow to respond. "A high TTFB can make achieving a 2.5 second LCP challenging, or even impossible." TTFB is time to first byte: how long before the server starts sending anything. Static, prerendered pages served from a fast host fix this; pages assembled on every request by a heavy platform do not.
• The main image is discovered late. The guide says "your LCP resource should be discoverable from the HTML source." If the hero image is only referenced inside JavaScript or a stylesheet, the browser cannot start fetching it until it has processed those. Put it in the HTML, and the guide suggests "set fetchpriority="high" on an <img> element if you think it's likely to be your page's LCP element."
• Scripts block rendering. The guide notes that "It is almost never necessary to add synchronous scripts" to the head of the page. Tag managers, chat widgets and fonts loaded synchronously all delay the first paint.

What makes the layout shift?

The CLS article lists the usual suspects: "images or videos with unknown dimensions," "fonts that render larger or smaller than its initial fallback," and "third-party ads or widgets that dynamically resize themselves" (CLS). The fixes are correspondingly plain: every image gets a width and height so the browser reserves its space; fonts are loaded in a way that avoids a jarring swap; anything injected late, such as a cookie banner or a chat launcher, is positioned so it does not push content.

What makes INP poor?

INP is about what the browser is doing when a visitor interacts. If it is busy running JavaScript, the tap waits. The pattern on business sites is too much script: several analytics tags, a heavy framework loading everything on every page, animations that run on the main thread. The fix is to ship less JavaScript, load what is needed when it is needed, and keep interaction handlers light.

What about websites that only work with JavaScript?

A related issue, outside the three Vitals but important to search: many modern sites render their content with JavaScript in the browser. Google can process this, but not instantly. Its documentation says Google "processes JavaScript web apps in three main phases": crawling, rendering and indexing, and that "Googlebot queues pages for both crawling and rendering." On the wait: "The page may stay on this queue for a few seconds, but it can take longer than that." (JavaScript SEO basics)

The robust approach is to prerender: generate the full HTML of every page at build time so crawlers, AI search tools and visitors on slow connections get the content immediately, and JavaScript only enhances it. This site is built that way, and HeliumSol's full-stack development service builds client sites the same way.

What should you ask your web developer?

You do not need to understand the engineering to hold a build to this standard. Ask:

1. What are the LCP, INP and CLS values for our key pages on mobile, at the 75th percentile, and where can I see them?
2. Is every page delivered as complete HTML, or does the content depend on JavaScript running first?
3. Do all images have explicit dimensions and modern formats, and are they lazy-loaded below the fold?
4. Are fonts self-hosted and preloaded, or fetched from a third party on every visit?
5. What third-party scripts load on each page, and which ones are actually used?
6. Is there an automated check that fails the build when a page loses its heading, its canonical URL or its structured data?

A good answer to each is specific. "It's fast" is not an answer; a number, a tool and a page are.

Where to go from here

If your current site cannot answer those questions, a performance review is a small project and often the most useful first engagement. If you are starting fresh, the free website and chatbot offer builds a site to these standards from the start; what the free website includes lists them. Either way, HeliumSol's full-stack development page explains what is included, and the case studies page shows the kinds of builds involved.

Sources

• Google, Web Vitals: web.dev/articles/vitals
• Google, Largest Contentful Paint: web.dev/articles/lcp
• Google, Interaction to Next Paint: web.dev/articles/inp
• Google, Cumulative Layout Shift: web.dev/articles/cls
• Google, Optimize Largest Contentful Paint: web.dev/articles/optimize-lcp
• Google Search Central, Understanding Core Web Vitals and Google search results: developers.google.com/search/docs/appearance/core-web-vitals
• Google Search Central, JavaScript SEO basics: developers.google.com/search/docs/crawling-indexing/javascript/javascript-seo-basics

This guide explains what each approach is, quoting the frameworks' own documentation, lays out the trade-offs, and gives the questions that decide it in practice.

What does "native" mean?

A native app is built with the language and user-interface toolkit the platform owner provides.

On Apple devices that is Swift. Apple describes it as "a powerful and intuitive programming language for all Apple platforms" and says "Swift code is safe by design and produces software that runs lightning fast" (Apple, Swift). On Android it is Kotlin. Google says Kotlin is "a modern statically typed programming language used by over 60% of professional Android developers," and that "Android's modern UI toolkit is built on Kotlin" (Android Developers, Kotlin). Google also states on that page that "Android apps that use Kotlin are 20% less likely to crash"; that is Google's figure, from its own page.

The consequence of native is simple: two apps, two codebases, two sets of skills, each with full and immediate access to everything the platform offers.

What does "cross-platform" mean?

A cross-platform framework lets one codebase produce apps for both stores. The two most used are React Native and Flutter, and they work differently.

React Native, maintained by Meta since 2015, is "written in JavaScript, rendered with native code." Its documentation explains that "React primitives render to native platform UI, meaning your app uses the same native platform APIs other apps do," and that it "provides a core set of platform agnostic native components like View, Text, and Image that map directly to the platform's native UI building blocks." The same page recommends starting with a framework on top: "To build a new app with React Native, we recommend a framework like Expo." It lists apps that use React Native, including Microsoft Office, Outlook and Teams, Amazon Shopping, Shopify, Discord and Coinbase (React Native).

Flutter, from Google, takes the other route. Its FAQ describes it as "Google's open source framework for crafting beautiful, natively compiled applications for mobile (iOS, Android), web, desktop (macOS, Windows, Linux), and embedded devices from a single codebase." Rather than using the platform's own widgets, "Flutter renders its UI using its own high-performance rendering engine," Impeller, and "provides implementations of Material Design and Cupertino (iOS-style) widgets." Apps are written in Dart, and "Flutter apps compile directly to native machine code or WebAssembly" (Flutter FAQ).

The difference in rendering matters for how an app feels. React Native draws with the platform's real buttons, lists and text fields, so an iOS app looks like iOS without effort. Flutter draws every pixel itself, which gives identical appearance on both platforms and full control, at the cost of re-implementing platform conventions.

How do the approaches compare?

When is native the right choice?

• The app is the hardware. Camera pipelines, audio processing, augmented reality, Bluetooth peripherals, background location at scale. Cross-platform frameworks reach these through bridges, and when an app is mostly bridge, native is simpler.
• Graphics or performance are the product. Games and animation-heavy interfaces where every frame matters.
• One platform is enough. If your customers are overwhelmingly on one platform, a single native app is the smallest thing to build and maintain, and nothing is lost.
• Deep platform integration is the point. Widgets, watch apps, App Clips, Android app shortcuts: features that are first-class on one platform and absent on the other.

When is cross-platform the right choice?

• Both stores, one team. Most business apps: bookings, customer portals, field tools, loyalty, ordering, support. The screens are forms, lists and detail pages, which every framework handles well.
• You already have a web app or a React team. React Native shares logic, skills and often components with a React web app, which is why it is HeliumSol's default when a client also has a web product; see full-stack development.
• Time to the first release matters more than the last few per cent of polish. One codebase ships both platforms at once and keeps them in step.
• The budget favours maintenance. Operating system updates, store policy changes and new features happen once instead of twice.

What about a web app instead of either?

Before choosing between native and cross-platform, ask whether an app is needed at all. If your users arrive from search, do not need push notifications, the camera or offline use, and would not install anything, a responsive web application reaches more people with less to maintain, and it is indexed by Google. An app earns its place when the product lives in the phone: notifications that bring people back, hardware features, offline work, or a store presence customers expect.

What should you expect from the build?

Whichever route you choose, the app is the visible half. The server behind it, with accounts, data, notifications and integrations, is the other half, and it is the same work regardless of framework. Store submission is its own task: developer accounts in your name, privacy declarations, review questions. HeliumSol's mobile app development service covers all three parts, and the first conversation is about the smallest release that is useful to a real user, which is the biggest lever on both cost and time. An app that answers questions or takes bookings usually wants the same grounded assistant as a website; AI customer support chatbot describes how that works inside a product.

How does HeliumSol decide?

Four questions, in discovery:

1. Does the app depend on platform-specific hardware or graphics? If yes, native, at least for that part.
2. Are users split across iOS and Android? If yes, cross-platform, unless question one overrides it.
3. Is there a web app or a React team already? If yes, React Native, to share code and skills.
4. Does the design need pixel-identical screens on both platforms? If yes, Flutter is worth weighing.

The answers are written into the scope with the reasoning, so the choice is a decision you can read, not a habit.

Sources

• Apple, Swift: developer.apple.com/swift
• Android Developers, Kotlin: developer.android.com/kotlin
• React Native: reactnative.dev
• Flutter FAQ: docs.flutter.dev/resources/faq
• Expo documentation: docs.expo.dev

What is n8n?

n8n's documentation describes it as "a fair-code licensed workflow automation tool that combines AI features with business process automation" (n8n docs). A workflow is built visually from nodes. The documentation puts the roles plainly: a node is "an entry point for retrieving data, a function to process data, or an exit for sending data" (Integrations). A trigger starts the workflow (a form submitted, an email received, a schedule), steps in the middle transform or branch, and action nodes do things in your apps.

Three facts from the documentation shape how a business should think about it:

• Coverage. n8n "supplies hundreds of nodes to create workflows that link multiple products," and for anything without a node, "you can still use the HTTP Request node" to call its API (Integrations).
• Where it runs. "n8n offers two primary deployment options: n8n Cloud (fully-managed) and Self-hosted (deploy on your own infrastructure)." The self-hosted Community edition is free and "includes almost the complete feature set of n8n" (Choose how to use n8n, Compare editions). n8n's own pricing page lists its Starter cloud plan at 20€ per month billed annually (n8n pricing).
• AI inside workflows. n8n lets you "build AI-powered workflows in n8n with LLM providers, agents, tools, memory, and MCP servers," connecting providers such as OpenAI, Anthropic and Google (Integrate AI).

Twelve workflows worth building first

Each is written as trigger, steps, outcome, so you can picture it against your own tools.

1. Lead intake

Trigger: a website form, a chatbot capture, or a new email to sales. Steps: create or update the contact in the CRM, send an acknowledgement, post a summary to the team's chat channel, create a follow-up task due within your response standard. Outcome: no lead sits unseen, and nobody copies details between tools. This is the workflow behind HeliumSol's lead generation chatbot.

2. Booking sync

Trigger: a new appointment in your scheduling tool. Steps: add it to the shared calendar, update the customer record, send a confirmation, schedule reminders at the intervals you choose. Outcome: one booking, every system updated, reminders without a person remembering to send them.

3. Quote and invoice generation

Trigger: a deal moves to "won", or a job is marked complete. Steps: fill a document template with the deal's details, create the invoice in your accounting tool, email it, file a copy in the right folder. Outcome: invoices go out the day the work finishes.

4. Inbox triage

Trigger: a new email in a shared inbox. Steps: an AI step classifies it (enquiry, support, invoice, spam), extracts the key fields, routes it to the right person or queue, and flags anything urgent in chat. Outcome: the shared inbox stops being a shared burden. The AI step is a single node; n8n's documentation covers connecting model providers under Integrate AI.

5. The morning report

Trigger: a schedule, every weekday at 7 a.m. Steps: pull yesterday's numbers from the CRM, the website analytics, the payment provider and the support tool, write them into one sheet or message. Outcome: one glance instead of five logins.

6. Review and mention monitoring

Trigger: a new review on your profile, or a new mention. Steps: post it to chat with a link, create a task to reply, and for a low rating, alert the owner directly. Outcome: reviews answered promptly, bad ones never missed.

7. Customer onboarding sequence

Trigger: a new customer record. Steps: send the welcome email, create their folder and shared documents, schedule the kickoff, add them to the right list, notify the account owner. Outcome: every customer gets the same first week.

8. Data cleanup and de-duplication

Trigger: a schedule, weekly. Steps: find duplicate contacts, normalise phone numbers and addresses, flag records missing required fields for a person to fix. Outcome: a CRM you can trust for reporting.

9. Publishing to every channel

Trigger: a new product, post or announcement in one source. Steps: format it for each destination and publish or queue it. Outcome: write once, appear everywhere, consistently.

10. Stock and threshold alerts

Trigger: a schedule, or a change in inventory. Steps: compare against thresholds, alert the buyer, optionally draft the purchase order. Outcome: you hear about low stock before a customer does.

11. Document extraction

Trigger: a file lands in a folder or inbox: a supplier invoice, a signed form, a delivery note. Steps: an AI step extracts the fields, a person approves anything uncertain, the data lands in the right system. Outcome: no retyping, and a review step where it matters.

12. Chatbot to CRM, with a human fallback

Trigger: a conversation in your website chatbot reaches a point of interest: a lead captured, a request for a person, or a question the bot could not answer. Steps: create the record, attach the transcript, alert a person, and if the AI could not help, route to a human queue. Outcome: the chatbot and the team work as one system. n8n's own examples include a workflow to "trigger a human answer when the AI can't help" (AI examples).

What can AI do inside an n8n workflow?

n8n's AI examples page lists the patterns in its own words: "use the n8n workflow tool to load data from Google Sheets into your AI workflow"; "load data from an API using the HTTP Request node"; "scrape a website, load the data into Pinecone, then query it in a chat workflow"; "require human approval before an AI Agent runs a tool"; "trigger a human answer when the AI can't help"; and use $fromAI() to "dynamically populate parameters for AI app tools" (AI examples).

For a business, that translates to four jobs AI does well inside a workflow: classify (which kind of email is this), extract (pull the fields out of this document), summarise (what did this thread decide) and draft (write a first reply for a person to edit). The last two examples on n8n's list, human approval and human fallback, are the ones to copy: they keep a person in the loop where the model is unsure or the action matters. The same principle runs through HeliumSol's AI assistant solutions.

What should you not automate?

• Anything you do not do consistently by hand yet. Automation fixes repetition, not confusion. Agree the manual process first.
• Decisions with judgement or policy weight. Refunds beyond a small amount, contract terms, anything a regulator would ask about. Automate the gathering of facts; keep the decision.
• Irreversible actions without an approval step. Deleting records, sending to a whole list, charging a card. Put a person between the workflow and the action until it has earned trust.
• Processes that change weekly. A workflow is a commitment to a process. If the process is still being invented, wait.

How do you keep automations safe?

Four habits, all cheap:

1. Test with test data first. Run every workflow against a copy or a sandbox before it touches live systems.
2. Handle errors loudly. Every workflow gets an error path that alerts a person. A silently failing automation is worse than none, because you stop checking.
3. Approve the irreversible. Add an approval step before any action that cannot be undone.
4. Log every run. n8n keeps execution history; make sure someone looks at it when something seems off.

Cloud or self-hosted?

n8n Cloud suits teams that want nothing to maintain; you pay a monthly plan and n8n runs it. Self-hosting suits businesses that want their data and automations on their own server, or that already run one, and the Community edition is free. HeliumSol sets up either, and for clients who already have a website server, often installs n8n alongside it. The trade-offs and the setup are part of the workflow automation service.

Where to start

Pick the workflow from the list that matches the task someone on your team complains about most, and build only that one. A single reliable automation changes how a team thinks about the rest; a dozen half-finished ones does the opposite. If you would like help mapping which one that is, HeliumSol's contact page is the place, and the free website and chatbot offer is where many automation projects begin, with a lead capture that needs somewhere to go.

Sources

• n8n documentation home: docs.n8n.io
• n8n, Integrations: docs.n8n.io/integrations/
• n8n, Choose how to use n8n: docs.n8n.io/choose-n8n/
• n8n, Compare editions: docs.n8n.io/deploy/host-n8n/community-edition-features/
• n8n, Pricing: n8n.io/pricing/
• n8n, Integrate AI: docs.n8n.io/build/integrate-ai/
• n8n, AI examples: docs.n8n.io/build/integrate-ai/ai-examples/