←back
Kissflow · AI assistant · 2024–2026

Kissflow’s first AI that talks back

Kissflow’s first AI assistant for workflow data. I pushed it from a report tool inside 1 workflow toward quick answers across workflows, and designed around real limits in cost, data and waiting.

Role
Senior Product Designer, the only designer on the team. I shared product scope and priorities with the PM
Team
1 PM, 1 backend engineer, 1 frontend engineer and me
Timeline
Design from July 2025. Customer release in June 2026
Status
Live for Kissflow's Enterprise customers
What I did
Designed it in Figma, prototyped the whole flow in the real app with AI and mock data, then built parts of the production frontend with Claude Code

Jump to the 5 decisions

Every AI feature in Kissflow worked one way: a prompt in, a result out. I designed the first one that talks back. My job was to turn how the system works into something business users could follow: the data it reads, the fields it picks, the query it writes and the wait while data syncs.

The engineers built what the AI does. I shaped how people see it, trust it and act on it, working closely with them and the PM.

The problem

Kissflow is a workflow platform. Companies run processes like purchase requests and approvals on it.

Admins could already build a report on 1 workflow themselves. Pick a chart type, drag in the fields, done. No query knowledge needed.

But most real work spans several connected workflows. Combining them meant Kissflow’s Analytics query editor, which needs SQL.

So those reports went to IT, and people waited. Some large customers exported their data to other tools and rebuilt the reports there.

Even a simple question, like the average purchase request value by department, meant going to Analytics and configuring a report.

“I know exactly what I want to see. I just can't build it myself. So I raise a request with IT and wait 2 days for a report I could've described in 2 sentences.”
Team manager, internal testing

We designed for business users. Think of an operations or process owner, the kind of person who works with the numbers most. Most admins are business users too.

What people needed

Internal testing made the main job clear. People wanted a quick number to read, decide on and share. Saving a report was for when someone needed the same view again with fresh numbers.

And the number had to be trustworthy. A data admin at a large customer put it plainly:

“It gave me a number. I don't know where it pulled it from. We've got a 'Location' field and a 'City' field. If it grabbed the wrong one, my report's off and I'd never catch it.”
Data admin, large customer

So the design had to answer now, let people save when they need to, and show the working.

From a Reports tab to a global assistant

Phase 1, from October to December 2025, lived inside the Reports page of a single workflow. Only our internal teams tested it.

I pushed for a global assistant from day 1. The PM preferred Reports, where people were already looking at their data. I made my case in business terms: an assistant in the global header gets seen, and people come back to it.

The move needed 2 things: the PM’s agreement, and a new data layer that could query across workflows. Both came together in Phase 2, January to March 2026, when the assistant moved to the global header and worked across several workflows.

An internal pilot ran from March to May 2026. Kissflow announced early access in April, customers were using it from June, and Kissflow announced it for Enterprise customers in July. Admins got it first; access then widened to people with permission to use workflow data in Analytics.

  1. 2024-25
    Concept
  2. Jul to Oct 2025
    First design in Figma
  3. Oct to Dec 2025
    Phase 1 inside Reports, 1 workflow, internal testing only
  4. Jan to Mar 2026
    Phase 2: global header, several workflows
  5. Mar to May 2026
    Internal pilot
  6. Jun 2026
    Customers start using it
  7. Jul 2026
    Announced for Enterprise customers

5 decisions

Decision 1

A conversation that asks back

Chose
A 2-way conversation
Instead of
A one-way generator, like Kissflow's other AI features
Why

People refine after they see a first answer: “just this month”, “make it a pie chart”. And when a question is unclear, the AI asks back before it builds anything.

It also sets up what comes next. Kissflow plans to bring more of its AI features into Ask, and a conversation gets people used to working that way now.

Trade-off

Some questions take an extra turn.

Principle
Ask instead of guessing
Grounded in
We designed for “scope services when in doubt”, from Microsoft's guidelines for human-AI interaction

Built by me with Claude CodeThe chat experience overhaul (January 2026) and editing the last question (February 2026)

Decision 2

Pick workflows before asking, for now

Chose
People pick up to 3 workflows as context before their first question
Instead of
An open question, with the system working out which workflows to use
Why

The open question was the ideal. People want the metric, and choosing workflows is work we’d rather do for them. But the system couldn’t yet work out workflows from a question.

So the input stays hidden until context is set, and the picker helps: tabs by type, search, and picking an app brings in its workflows.

Why 3? We tested different limits, and 3 gave the best balance of answer accuracy and speed.

Trade-off
An extra step before the first question. It's a stopgap, and removing it is next

Built by me with Claude CodeApp context and choosing several workflows in the picker (April 2026)

Decision 3

Show the working

Chose
'Show details' under answers that have sources or a query behind them. 'Sources' shows the workflow and the fields the AI used, plus a plain-English note on how it worked the answer out. 'Query' shows the actual SQL, for technical users
Instead of
Raw lists of the workflows, tables and fields the AI picked
Why

Business users need to see where a number came from, and that the AI took the right steps, before they trust it. Sources was my ask: the workflow and the fields, laid out so a business user can read them. The plain-English note on the steps was a joint decision.

The query is there for technical users who want to check it or reuse it. Adding it to answers was a joint call with the PM.

Trade-off
The plain-English note is written the first time someone opens it, so it takes a moment
Principle
Show the working
Grounded in
We designed for “make clear why the system did what it did”, from Microsoft's guidelines
Decision 4

Answer now, save if needed

Chose

Answers arrive in the chat, ready to read: usually a sentence for a single number, and a table, chart or pivot for breakdowns. Reports open in a large preview beside the conversation, and charts export as images. When someone needs the same view again, ‘Edit and save report’ turns it into a permanent report that picks up new data.

Instead of
Sending people to the Analytics query editor to change it, which needs SQL
Why

‘Edit and save report’ opens Kissflow’s easy Report Builder with the hard cross-workflow query already written. The AI does the hard part once. Adjusting the report afterwards happens where no query knowledge is needed.

Trade-off
Inside the chat, you change a report by asking. There are no filter or build controls there
Principle
Answer now, save if needed

Built by me with Claude CodeSaving and editing reports (February 2026)

Decision 5

Make the first wait worth it

Chose
A separate loader for the first data sync that says what the system is doing, an 'Ask' button that shows Working and Ready, and a toast when the answer lands. People can close the panel and carry on with their work
Instead of
The default AI loader, where people felt stuck
Why

To keep costs down, engineering syncs data for quiet workflows only when someone asks. So the first question on one can take minutes while the data catches up.

This one was my call. In B2B software, people judge a tool on trust and time. And they remember the most intense moment of an experience and how it ends (the peak-end rule).

I spotted that a long first wait could frustrate people, and that if the first try went wrong, they might never come back.

So the design gives live feedback on what the system is doing, with the aim that the answer at the end feels worth the wait.

Trade-off
The sync still takes as long as it takes. People can see it and walk away from it
Principle
Be honest about waiting
Grounded in
We designed for Nielsen's “visibility of system status”

Built by me with Claude CodeThe first-sync loader, the Working and Ready states and the toast (June 2026)

Testing before release

Before customers saw it, we tested accuracy on realistic mock data. We used AI to generate Kissflow-style data, a set of questions and scored test cases. The PM, the developers and I each ran it, and the answers met the accuracy bar we’d set.

Every answer still comes with a permanent reminder under the input: the results are AI-generated and need checking.

After release

Enterprise teams in operations, finance, HR and procurement use it, judging by the workflows people ask about.

What I learned

Start from the question. People arrive with a question on their mind. It's the product's job, technical and functional, to understand it and turn it into an answer. Required picking was a stopgap we accepted, and removing it is next.

Argue in business terms. The global move was won on an argument about visibility and people coming back to it. That's what moved the PM.

Learn the engineering first. I couldn't make the AI's working clear until I understood the data, the schema and the queries well enough to explain them simply.

Asking back works. People accept a clarifying question when it helps.

Design survives into code. I built parts of the frontend myself, so the interaction details shipped the way I designed them.

Designers can build. Working in code with AI changed what I could deliver on a product this interaction-heavy.

What’s next: Ask opens to all users. Required picking goes once the system can work out the workflows itself. And more of Kissflow’s AI features are planned to move into Ask, so the conversation becomes the place where that work happens.

What I owned

  • ·Pushed for a global assistant from day 1
  • ·Asked for Sources, so business users can check where a number came from
  • ·Designed the first-sync waiting experience (my call)
  • ·Designed the experience in Figma, and prototyped the whole flow in the real app with AI and mock data
  • ·Built with Claude Code, merged into the feature code: the chat experience overhaul, saving and editing reports, editing the last question, app context and multi-select in the picker, and the first-sync waiting states

Everything else was decided together with the PM and the 2 engineers.