Design an AI assistant that helps people get things done

From answer to action

A lot of AI assistants in business software are support chatbots repackaged. They can answer questions, sometimes well. But the person still has to leave the conversation, find the right screen and do the work themselves.

The opportunity is bigger than that. A well-designed assistant understands where someone is in their work, pulls in the right information and helps them take the next step without switching context. That’s harder to design, because it touches permissions, trust and error handling, not just tone of voice.

Our founder worked on exactly this problem for a major international bank building a new corporate-banking platform. The conversational banking case study covers it in detail. Here are the lessons that apply more broadly.

Start with one task you understand well

“Ask me anything” is a weak first release. It sets expectations you can’t meet and makes it impossible to judge whether the assistant is any good.

The team chose one first use case: tracking a payment. It was common, well understood and high value, with a clear finish line. The team mapped it end to end: what the customer wants, what the assistant needs to find out, which data it retrieves, what permissions apply, how it responds and what the customer can do next. That one journey taught the team more about the system it needed than any amount of brainstorming.

It also helps to agree a maturity model early. That project’s model had three stages: answering queries, then offering guidance and actions in context, then eventually proposing a plan for the customer to review and approve. Everyone could see where day one sat and where it was heading.

Mix conversation with structure

Text is a poor format for a lot of business information. A payment status shouldn’t be buried in a paragraph. The assistant that came out of that work combined natural language with structured interface elements: status, key facts, tables, selections, forms and cards, all from a reusable component library.

A useful response pattern is: a short answer, the key facts that support it, then the actions available. The person can scan, trust and act, without reading an essay.

Design for every kind of response

The happy path is the least interesting part. That project designed response logic for five situations:

• Successful: the assistant has the answer and the action.
• Partial: it can help with some of the request but not all.
• Ambiguous: it needs to ask which payment, account or date the person means.
• Restricted: the person isn’t allowed to see or do this.
• Failed: something went wrong, and it says so honestly.

Each needs its own wording, its own next step and, often, a route to a human.

Respect permissions and control

In a high-trust setting like banking, an assistant must never become a way around permissions. It should only show what the person could see elsewhere in the product, and it should make clear what it’s about to do before doing it. For anything with consequences, the person reviews and confirms. They can always edit or say no.

Be explicit about what the assistant is. If it’s AI, say so. If it can’t help, say that clearly and hand over to a person with the context already attached, so the customer doesn’t have to start again.

Measure the right thing

Conversation counts and satisfaction scores are easy to collect and easy to misread. The more useful measure is whether people completed the task they came for, and whether they needed to contact someone afterwards. Plan that measurement before launch, not after.

If you’re adding AI to a complex product and want it to do more than answer FAQs, Complex Workflow Design can take one use case from journey map to prototype, including the failure states most teams leave until later.