Start with one workflow that costs the most manual time. Prove value there before expanding.
There is a different approach. You connect your WordPress site directly to an AI API, build a small custom interface, and own the entire stack. The cost per conversation is typically a fraction of what subscription plugins charge for comparable usage, and the data stays in your control.
The technical path looks like this. You register with an AI API provider and get an API key. You create a small PHP function in your theme or a custom plugin that receives a visitor’s message via a WordPress AJAX endpoint, forwards it to the API, and returns the response. The chat interface on the front end is a few dozen lines of JavaScript. There is no third-party plugin involved.
The part that requires care is the system prompt, the instructions you give the AI model that define how it should behave on your site. A generic AI assistant that can talk about anything is not useful for a business website. You want a system prompt that tells the model what your business does, what questions it should answer, what it should decline to discuss, and when it should ask the visitor to contact your team directly. This takes more time to write well than the code does.
There are a few decisions worth making before you build. First, decide whether the chat should have memory within a conversation or treat every message as independent. Memory requires storing conversation history in the session and sending it with each API call, which increases cost and complexity but produces much more natural conversations. For most business use cases, within-session memory is worth the extra work. Second, decide what happens when the AI cannot answer a question confidently. Building in a fallback, a message that says “I am not sure about that, but you can reach our team here” with a link to your contact form, is more useful than letting the model guess.
The cost question depends entirely on usage. If your site gets low to moderate traffic and most visitors ask a few short questions, the API cost is negligible. If you are running a high-traffic site where every visitor engages with the chat, you need to estimate monthly costs before building.
This kind of integration is part of the API and integrations work we do most often for WordPress sites. The scope is usually smaller than clients expect, and the result is a chat layer that fits the site’s specific use case rather than a generic product.
What the integration actually looks like in code
The WordPress side is a REST endpoint or AJAX handler that accepts POST requests from the front end. It validates the input, constructs the API payload with the system prompt and conversation history, sends it to the AI provider, and returns the response. The front end polls or uses a streaming response to display the text as it arrives.
The system prompt is stored as a WordPress option, editable from the admin panel. This matters because you will want to update it as you learn what questions visitors actually ask. The first version of a system prompt is always wrong, you discover the gaps once real visitors start using it.
call, which increases cost and complexity but produces much more natural conversations.
Working on something similar?
Let's talk →What can go wrong
The most common problem is a system prompt that is too permissive. If you do not explicitly define the scope of what the AI should discuss, it will try to answer everything, and it will sometimes be wrong. Define scope before launch, not after.
The second common problem is rate limiting. AI API providers have rate limits on free and lower tiers. If your site has a traffic spike, the chat can fail silently. Build in an error state that shows a message and a contact link when the API is unavailable.
Want to build this for your site rather than pay for another subscription? Tell us what you need →
