How Can I Add Custom Business Workflows to My Chatbot?

Through custom instructions, no code required. This is the no-code way to shape how AeroChat behaves for your specific business: which route a conversation takes, what tone it uses, and when it should hand off to a person instead of continuing on its own. It’s a different mechanism from building an entirely new custom action, and it’s the one most stores actually need.

Custom instructions vs. custom actions: not the same thing

It’s easy to conflate these, so it’s worth being precise. Custom instructions shape behaviour: how AeroChat talks, what it prioritises, and which path a conversation follows based on what’s said. They don’t give the chatbot a new capability it didn’t already have. Building an entirely new action, something AeroChat can’t already do, requires the API and, usually, a developer. That side of things is covered in can I build my own custom actions for an AI chatbot. This article is about the no-code side: shaping the workflow logic within what AeroChat already supports.

What “a workflow” actually looks like in custom instructions

A workflow, in this context, is a rule: when this happens, do that. A few real examples worth building:

• “If a customer asks about a wholesale or bulk order, don’t quote a price, ask for their business name and hand off to the sales team directly.”
• “If someone mentions a damaged item, ask for a photo and order number before offering a resolution, don’t offer a refund automatically.”
• “If a conversation goes past two unanswered questions about the same topic, hand over to a human rather than continuing to guess.”
• “For first-time visitors asking about sizing, always recommend checking the size guide before suggesting a specific size.”

None of these need a developer. They need a clearly written rule, which is exactly what custom instructions are built to take.

Writing instructions that actually hold up in a real conversation

Vague instructions produce inconsistent behaviour. “Be helpful with wholesale enquiries” leaves too much to interpretation. “If a customer asks about a wholesale or bulk order, don’t quote a price, ask for their business name and hand off to the sales team” gives the chatbot an actual decision to make and a specific action to take. Write instructions the way you’d brief a new hire on their first day, specific trigger, specific action, not a vague principle.

Building this in AeroChat, step by step

1. List the two or three situations where your business needs the chatbot to behave differently from its default, not everything at once.
2. Write each as a trigger and action, “if X, then Y,” using the examples above as a template.
3. Add them under AeroChat’s custom instructions and test each one with a real conversation matching the trigger.
4. Watch the first week of matching conversations closely, and tighten the wording of any instruction that gets interpreted differently than you intended.

When instructions aren’t enough

If what you actually need is a genuinely new capability, checking a system AeroChat doesn’t already connect to, or taking an action beyond what’s currently supported, that’s a custom action problem, not a workflow problem, and it needs the API rather than custom instructions. Trying to force a real system integration into a written instruction won’t work; the chatbot can only act within what it’s actually connected to.

Your next step

Pick the one situation where your chatbot’s default behaviour has caused a real problem, a wrong answer, an awkward handoff, a customer who should have been routed to sales but wasn’t. Write that single instruction first, test it for a few days, then move on to the next one. Building three well-tested instructions beats writing ten untested ones on day one.

Frequently asked questions

Is there a limit to how many custom instructions I can add?

Check your specific AeroChat plan for any limits. Regardless of the ceiling, a small number of well-written, well-tested instructions works better in practice than a large number of vague or overlapping ones.

Can two custom instructions conflict with each other?

Yes, if they’re written broadly enough to overlap on the same situation. Keep each instruction scoped to a specific trigger, and review them together periodically rather than adding new ones without checking against what’s already there.

Do I need to rewrite these often?

Only when your actual business rules change, a new policy, a new product line, a new escalation path. Treat them the way you’d treat a written support process: update it when reality changes, not on a fixed schedule.