Friends are useful for encouragement and terrible for proving that strangers will pay. AI moderated user interviews are built to get past polite praise by asking about behaviour, spending and real past decisions.
Example:
A student in Vijayawada wants to start a tiffin subscription for hostel students. She asks 20 classmates if they would use it, and 18 say yes.
Her old college group likes the idea. Her cousin promises to become the first customer. She spends her savings on containers and a two-wheeler.
Three months later, four people subscribe and two cancel.
The idea may not be the only problem. The questions were also weak.
“Yes, I would definitely use it” is the most expensive sentence a founder can hear, because it costs the other person nothing to say.
Many first-time Indian founders test an idea by asking friends, relatives and former classmates. Everyone wants to be supportive, so they praise the idea even when they have no intention of changing their current behaviour or spending money.
A useful interview asks different questions. Instead of “Would you subscribe to my tiffin service?”, it asks what the person eats today, how they get it, what they pay, what frustrates them and what made them last change providers. Those answers describe behaviour rather than imagined interest.
The system asks one open-ended question at a time. It reads the answer and chooses a sharper follow-up, continuing until there is nothing useful left to explore.
There is also less social awkwardness. A participant does not have to look at a friend and say the idea sounds weak. They can type what they really think from their phone.
The workflow does not decide if the business is good. It helps the founder collect better evidence before spending savings or months of work.
The participant opens an interview link on their phone.
The first page asks for their name. After submission, the workflow generates a unique session ID and creates a private session for that interview.
An AI researcher reads the interview topic and writes the first open-ended question.
Example topic:
Your experience ordering lunch near your college.
The first question could be:
How do you usually get lunch on weekdays?
The participant types an answer and taps the Next Question button. The workflow saves the answer before making another model call.
The AI researcher then reads the reply and decides what to ask next.
Example:
The useful detail begins to appear in the later question. A fixed form might stop after learning that the participant uses the canteen. The interview continues towards past behaviour, spending and the reason behind a choice.
This is what separates AI customer interviews from a normal questionnaire. The next question depends on the previous answer.
When the AI researcher decides there is nothing useful left to ask, it sets the interview to stop. The participant sees a thank-you page, the short-term AI memory is cleared and the complete conversation is copied to Google Sheets.
A founder can later open a transcript page using the session ID. If the Redis session has expired, that page displays a not found message.
| Stage | What the participant sees | What happens behind the screen |
|---|---|---|
| Start | A form asking for their name | Form Trigger fires and a unique session ID is generated |
| Question loop | One question per page and a Next Question button | AI Agent writes the question and Redis stores the answer |
| Finish | A completion screen | Memory is cleared and the transcript is copied to Google Sheets |
| Later | Nothing | The founder can open a transcript page using the session ID |
Example:
A participant can answer at 11 PM after class, after closing a shop or while travelling home. They do not need to arrange a call with the founder.

A Google Form collects answers. A customer interview AI tool collects reasons.
The tools in this walkthrough are one example of how an AI interview can be put together. If you already use a different automation platform, or want it custom built, my team will build it there as you ask.
The difference becomes visible when someone types a vague response such as “It is okay.” A fixed form accepts that answer and moves to the next prepared question, while the interview workflow can ask, “What do you mean by okay?”
| Point | Google Form | Interview workflow |
|---|---|---|
| Questions | Fixed before the participant begins | Written during the interview based on the last answer |
| Vague answers | Accepted as submitted | Followed by a clarifying question |
| Length | The same for every participant | Stops when there is nothing new to learn |
| Output | One row per participant | One row per question and answer, with timestamps |
| Running cost | Free | Free tiers exist for n8n self-hosting, Upstash and Groq; current provider limits must be checked |
A form is useful for registration, attendance, a head count or an RSVP. It works when you already know the exact questions that need answers.
Discovery is different because you are still trying to understand the problem. You need to learn what people do now, which workaround they use, what they already pay for and why they last switched.
If you already have an idea but cannot turn it into a narrow interview topic, send the topic through the contact page. My team can help frame the research question before anybody connects a node.
The AI Researcher is a AI Agent with three connected parts:
The original template instructs the researcher to behave like a research expert, stay on the interview topic and ask one open-ended question at a time.
Every model response must be JSON containing two keys:
questionstop_interview{
"stop_interview": false,
"question": "You said lunch near college is 'okay'. What would make it better?"
}
This small contract keeps the workflow predictable. The IF node does not need to interpret a paragraph from the model. It only checks whether stop_interview is true or false.
The original template uses a Groq Chat Model. I keep the Groq LLM for live interviews because the next question needs to appear quickly. If a participant waits five seconds after every answer on a phone, they may close the page.
The model can be replaced with another chat model supported by n8n. Check the current Groq model list before building because model names can change.
The Groq LLM does not hold the permanent interview record. Its memory helps it follow the current conversation, while Redis stores the actual questions and answers.
Every participant needs a separate memory and transcript.
Without that separation, one person’s answer could influence the next participant’s question. That would damage the interview and expose information between sessions.
The workflow generates a unique ID for each interview. Redis uses that ID inside a session key, which can look like session_ followed by the generated value.
Every question and answer is pushed into the list connected with that session.
The key has a time-to-live of one day. Abandoned sessions then remove themselves instead of remaining in the database.
I use Upstash Redis because it provides hosted Redis that the workflow can reach over the internet. The workflow does not require you to operate a Redis server yourself.
Storage happens before the answer goes to the AI Researcher. If the model call fails, the participant’s latest reply remains in Redis.
That sequence follows a useful rule: write first, think second.
The workflow below shows the exact order in which data moves.
| # | Node | Type | Job | Next node |
|---|---|---|---|---|
| 1 | Start Interview | Form Trigger | Publishes the interview link and asks for the participant’s name | UUID |
| 2 | UUID | Crypto (generate) | Creates a unique interview ID | Create Session |
| 3 | Create Session | Redis (set) | Creates the session with an empty list and a 24-hour expiry | Generate Row |
| 4 | Generate Row / Update Session | Set + Redis (push) | Writes a start interview row into the session | Set Interview Topic |
| 5 | Set Interview Topic | Set | Holds the topic the researcher must follow | AI Researcher |
| 6 | AI Researcher | AI Agent + Groq Chat Model + Window Buffer Memory | Writes the next question and decides when to stop | Parse Response |
| 7 | Parse Response | Set | Converts the JSON into question and stop_interview fields | Stop Interview? |
| 8 | Stop Interview? | IF | True ends the loop; false continues | Get Answer or finish path |
| 9 | Get Answer | Form (next page) | Shows the question and collects the answer | Update Session, then AI Researcher |
| 10 | Clear For Next Interview | Chat Memory Manager (delete) | Removes short-term AI memory | Completion screen |
| 11 | Redirect to Completion Screen | Form (ending) | Shows the thank-you page | Get Session |
| 12 | Get Session, Session to List, Save to Google Sheet | Redis (get) + Split Out + Google Sheets (append) | Copies the complete transcript to a sheet | End |
A second, smaller path provides transcript viewing.
A Webhook receives a session ID, retrieves the Redis session and displays the conversation as a web page. If the session has expired, it shows a not found page.
The workflow and credentials remain on the client’s accounts. You can read about UpcomingTools and the small team that designs these systems before deciding who should work inside your n8n workspace.
A workflow can contain every correct node and still lose data if the order is wrong.
Redis needs a unique key before it can create the session.
So UUID sits before Create Session. Trying to store the conversation first would leave Redis without a reliable way to separate one interview from another.
The workflow creates the session before generating the first question.
If the participant closes the page after answering once, the information submitted so far has already been stored. The system does not wait until the completion page to save everything.
The AI Researcher returns JSON, while the IF node needs a clean true or false value.
Parse Response converts the model output into the question and stop_interview fields before Stop Interview? reads them.
Without this step, the IF node may receive plain text and route the interview incorrectly.
Get Answer collects the participant’s reply. Update Session pushes it into Redis before sending the conversation back to the AI Researcher.
A failed model call does not erase the answer because storage already happened.
The Chat Memory Manager deletes the AI Agent’s short-term memory after the interview ends.
Redis and Window Buffer Memory do different jobs. Redis stores the transcript rows, while Window Buffer Memory gives the model temporary context for the current conversation.
One is the research record. The other helps the researcher remember what it just heard.

Each failure creates a different symptom.
| Failure | What the participant sees | Response |
|---|---|---|
| Upstash Redis credential expires or its URL changes | Interview stops after the name screen | Re-test the Redis credential and preserve the TTL |
| Groq rate limit is reached or the model name changes | A long wait followed by an error | Update the model or fall back to fixed questions |
| Parse Response receives plain text instead of JSON | Loop ends too early or repeats | Tighten the prompt so it returns only question and stop_interview |
| Google Sheets authentication expires | Participant still reaches the completion page | Reconnect Sheets while the transcript remains in Redis |
| Workflow is not activated | Production link displays not found | Activate the workflow and use its production URL |
The public Form Trigger URL works only after the workflow is activated. A test form can work while the production link remains unavailable.
A Google Sheets failure is less visible because the participant can finish the interview normally. The conversation stays in Redis for one day, giving you time to reconnect the sheet and run the save path again.
After the Redis key expires, that recovery option is no longer available. Testing these failure paths before sharing the interview prevents data loss later.
You do not need to be an engineer, but you should be comfortable opening nodes, adding credentials and running a complete test.
question and stop_interview.transcripts.Avoid a broad topic such as “Tell me about education.”
A coaching-centre topic could focus on why a student chose their current centre. A D2C interview could focus on the last time somebody bought that type of product online.
A narrow topic keeps the model close to the decision you need to make.
The first form screen should explain that answers will be saved, who will read them and that the participant can stop at any time.
India’s Digital Personal Data Protection rules apply to the personal data you collect. Ask only for information needed for the research.
For most interviews, a first name is enough. Skip phone numbers unless you need to contact the participant later.
Collecting more personal information gives you more data to protect without necessarily improving the research. The UpcomingTools privacy policy explains how information shared with my team during a workflow project is treated.
The consent wording, credentials and interview topic should all be ready before testing the transcript from start to finish.
The final branch retrieves the Redis session, splits the stored list into rows and appends those rows to Google Sheets.
Create a sheet named transcripts with these columns:
| Column | What it holds |
|---|---|
name | Name entered on the first page |
session_id | UUID for the interview |
timestamp | Time each row was written |
type | start_interview, next_question or stop_interview |
question | Question asked by the AI |
answer | Participant’s reply |
Every question and answer becomes a separate row. The session ID connects all rows belonging to the same participant.
This structure may look less polished than one long transcript, but it is easier to filter, sort and review. You can group rows by session, highlight repeated problems and copy exact participant language into a pitch deck.
The Webhook path offers a temporary transcript page. It accepts the session ID and retrieves the conversation while the one-day Redis session still exists.
Google Sheets becomes the longer-term record. Redis remains temporary working storage.

A clean sheet does not automatically produce a good decision. Founders are attached to their ideas, so it is easy to treat every positive sentence as validation and explain away every uncomfortable answer. The workflow organises interview transcripts, but I do not let the AI announce whether the business will work.
My team begins by reading the replies and tagging them by hand. My team marks pain in the participant’s own words, the workaround they use today, anything they already pay for and a useful quote kept exactly as written. These categories force us to stay close to what the participant actually described.
Interest is weaker than behaviour. “Yes, this sounds useful” tells you very little because the participant has not given anything up. A person describing how they currently message three tiffin providers every Sunday and pay one in advance has revealed an existing behaviour, workaround and spending pattern.
The source approach uses a working signal from early research: if 10 people describe the same pain and at least a few already spend money on a workaround, the idea may deserve another test. If everyone is merely interested, you may have a pleasant idea but not a business. AI customer interviews help you gather the evidence faster, but they should not make the decision for you.
For early founders, this manual reading is not wasted effort. It is the point where you separate what participants said from what you hoped they would say.

The workflow is useful when you need several honest conversations but cannot personally call every participant.
User research for startups can help students test side-hustle ideas before spending pocket money, zero warriors starting without capital and solo founders exploring a narrow customer problem. It can also help D2C sellers, coaching centres, clinics and local shops collect structured feedback without calling every person.
| Business | What changes | Example topic |
|---|---|---|
| Coaching centre | Separate wording for parents and students | Why you chose your current coaching centre |
| Clinic | Short, respectful questions without medical details | Your experience booking an appointment |
| D2C brand | Focus on the last purchase and switching moment | The last time you bought this product online |
| Kirana or local shop | Simple words and a phone-first layout | How you order groceries on busy days |
The interviews do not have to run only in English.
Participants can answer in Hindi, Telugu or Hinglish. The researcher can be instructed to respond in the participant’s language and keep each question short.
Test the language with a few real people before distributing the link widely. Model quality can vary by language, and mixed-language answers must remain easy to understand on a phone.
For early research, the source author’s working practice is to aim for 15 to 25 completed interviews on one narrow topic. This is not presented as a scientific rule.
Stop when new participants repeat what you have already heard. Twenty vague interviews can be less useful than 10 focused conversations about recent behaviour or a real decision.
A customer interview AI tool is not right for every research conversation.
Do not use it when a small number of enterprise buyers could decide the future of the business. If one customer could change the company’s direction, speak with them yourself.
Avoid it for sensitive subjects that need the judgement and care of a trained person. A form-led AI interview cannot replace that responsibility.
It is also a poor fit when personal trust is part of the product. Some participants will share useful information only after speaking directly with the founder or another person they trust.
The workflow works best when you need consistent follow-up questions across many ordinary conversations. You still own the topic, consent language, transcript review and final decision.
My team can build this workflow on your accounts or create a custom version for your industry, audience and research topic.
| Stage | What happens | What you receive |
|---|---|---|
| Research goal | My team identifies the decision the interviews must support | A written interview goal |
| Question design | My team writes the topic, opening question and stop rules | A draft for approval |
| Build | My team connects Redis, Groq, the form and Google Sheets | A working interview link |
| Test | My team runs test interviews and correct the wording | Sample transcripts |
| Handover | My team shows you how to edit the topic and review the sheet | Access, notes and a short recording |
The Upstash Redis database, Groq credential, workflow and Google Sheet stay on your accounts. You own the build and the collected data.
A first working version normally reaches you within 7 to 10 days of agreeing the scope, and a week is the shortest I would promise.
How long a bigger build takes depends on what you ask for, and we settle that on calls and emails. I walk you through the design on a phone call, then on Zoom with my screen shared so you can follow every step.
The refund policy explains the terms for paid work before the design begins.
Write the interview topic narrowly enough that a participant can answer from recent experience, not imagination.
Email upcomingtool@gmail.com with that topic in one sentence. I will tell you if AI moderated user interviews fit what you need to learn.