22
21 Comments

Before you build another feature, use this workflow

Feature requests are easy to collect and hard to judge.

One customer asks for something. Another asks for something else. Soon, your backlog is full of ideas, but you still don’t know what to build.

Here’s a simple, automated workflow to make prioritizing feedback easier.

What the workflow does

This workflow gives every customer request a simple process:

  • First, the request is collected through a form.
  • Then it is saved.
  • Then, AI summarizes it and tags it.
  • Next, you check if similar requests already exist.
  • Finally, you decide what action to take next.

The request then ends in one of these places:

  • Follow-up question
  • Backlog
  • Customer interview
  • Founder follow-up
  • Sales follow-up
  • Small build

This keeps you from building unnecessary things.

Tools

You only need a few tools for this workflow:

  • Jotform: collect feature requests
  • Airtable: store and review requests
  • Zapier: connect the tools
  • ChatGPT/OpenAI in Zapier: summarize and tag requests
  • Gmail: send follow-up emails
  • Slack: send alerts for important requests

Keep the system simple. One form. One Airtable base. One Zap. One weekly review.

Step 1 — Build the public request form in Jotform

Start by creating a form in Jotform.
Go to Jotform:

  • Click Create Form → Start From Scratch
  • Call the form: Feature Request Form

Add these fields (or something similar):

  • What feature do you want?
    • Use short text.
    • Make it required.
    • Add helper text: “Example: I want scheduled PDF reports.”
  • What problem are you trying to solve?
    • Use long text.
    • Make it required.
    • Add helper text: “Example: I send client reports every Monday, and I build them by hand right now.”
  • How urgent is this?
    • Use a dropdown.
    • Make it required.
    • Add these options:
      • Nice to have
      • Important
      • Blocking my work
      • We may cancel if this is not solved
  • What are you doing today instead?
    • Use a dropdown.
    • Make it required.
    • Add these options:
      • Doing it manually
      • Using a spreadsheet
      • Using another tool
      • Paying someone to do it
      • Not solving it today
      • Other
  • Tell us more about the workaround
    • Use long text.
    • Make it optional.
    • Add helper text: “Example: I spend 45 minutes every week copying data into a document.”
  • What is your email address?
    • Use an email field.
    • Make it required

The customer can now send a request with enough detail.

Step 2 — Create the Airtable base

Next, create the place where the requests will be saved.

Go to Airtable:

  • Create a base called ‘Feature Requests’.
  • Create a table called ‘Requests’.

This table has three kinds of fields.

First, add the fields that come from the customer form:

  • Customer email
  • Feature request
  • Problem
  • Urgency
  • Workaround
  • Workaround details

Next, add the fields that AI will fill:

  • AI summary
  • Category
  • Request group
  • Revenue signal
  • Decision
  • Decision reason

Last, add the fields that you will fill yourself:

  • Customer plan
  • Account value
  • Customer ID
  • Revenue score

Use simple field types:

  • Use email for Customer email.
  • Use long text for Feature request, Problem, Workaround details, AI summary, and Decision reason.
  • Use single select for Urgency, Workaround, Category, Revenue signal, Decision, and Customer plan.
  • Use short text for Request group and Customer ID.
  • Use currency or number for Account value.
  • Use number for Revenue score.

For Category, add these choices: Reporting, Integrations, Automation, Permissions, Billing, Import, Export, AI, Admin, Other

For Revenue signal, add these choices: Low, Medium, High, Expansion, Churn risk, Unclear

For Decision, add these choices: Backlog, Ask follow-up, Customer interview, Founder follow-up, Sales follow-up, Small build

Every request now has one place to live.

Step 3 — Create the Zapier trigger

Go to Zapier.

Click: Create → Zap

Set the trigger:

  • App: Jotform
  • Event: New Submission
  • Form: Feature Request Form

Click: Test trigger

If Zapier does not find a request, submit a test request in Jotform.

Step 4 — Add the AI cleanup step

Next, add AI to the Zap.

  • In Zapier, click the plus button.
  • Choose ChatGPT by OpenAI.
  • Choose a prompt or structured data action.

Paste this prompt (or something similar):

You are helping a small SaaS founder review a feature request.
Use only the information provided. Don’t make anything up._
Return:
*   AI summary: One short sentence that explains the request.   
*   Category: The closest request category.
*   Request group: A short lowercase label with hyphens. Example: scheduled-pdf-reports  
*   Revenue signal: The possible revenue impact.  
*   Decision: The best next step.  
*   Decision reason: A short sentence explaining the decision.
    

Rules:
*   Expansion = may lead to an upgrade, more seats, a higher plan, or a paid add-on.
*   Churn risk = customer may cancel or cannot keep using the product without it.    
*   High = clear pain, urgent pain, paid workaround, or high-value account._    
*   Medium = real problem, but money impact is unclear.  
*   _Low = nice-to-have.    
*   Unclear = not enough information.
Request details:
*   Feature: [map Jotform feature request]    
*   Problem: [map Jotform problem]    
*   Urgency: [map Jotform urgency]   
*   Workaround: [map Jotform workaround]   
*   Workaround details: [map Jotform workaround details]_    
*   Customer plan: leave blank for now    
*   Account value: leave blank for now_ 

Click: Test step

Step 5 — Create the Airtable record

Add another Zapier step.

Choose: Airtable → Create Record

Select:

  • Base: Feature Requests
  • Table: Requests

Map the fields from Jotform. Then, map the fields from the AI step ( Leave Customer plan, Account value, Customer ID, and Revenue score blank for now. You will fill them in during your weekly review.)

Click: Test step

Then open Airtable and check the new row. Each new request should now be saved with the customer details and the AI cleanup.

Step 6 — Create Airtable views for each next step

Now, create a few Airtable views.

Instead of one giant list, create one view for each action. These views should help you answer one question: “What should I do next?”

Create these four:
View 1: Founder Review
This is for requests that may matter to revenue or churn.
Create a new view called: Founder Review
Filters:

  • Decision is Founder follow-up
  • OR Decision is Sales follow-up
  • OR Revenue signal is Expansion
  • OR Revenue signal is Churn risk

View 2: Backlog
This is for requests you are not acting on yet.

  • Create a new view called: Backlog
  • Filter: Decision is Backlog

View 3: Customer Interviews
This is for requests where you need to talk to the customer.

  • Create a new view called: Customer Interviews
  • Filter: Decision is Customer interview

View 4: Small Build Candidates
This is for requests that may be worth building soon.

  • Create a new view called: Small Build Candidates
  • Filter: Decision is Small build

These views make the review faster and easier.

Step 7 — Group similar requests

In Airtable, open the Requests table:

  • Click: Group
  • Select: Request group

Airtable will now group similar requests. Review these groups weekly. Look for:

  • Requests that come up again and again
  • Paid users asking for the same thing
  • High-value accounts asking for the same thing
  • Manual workarounds
  • Customers who may cancel
  • Requests that could lead to an upgrade

AI may not group everything perfectly. For example, these may all mean the same thing:

  • Scheduled-reports
  • Scheduled-pdf-reports
  • Weekly-client-reports

If they are the same request, give them one shared name during your weekly review.

Step 8 — Score the request yourself

Do this part by hand at first. Score at least the first 20 to 30 requests yourself.

Open the request in Airtable. Review:

  • Customer plan
  • Account value
  • Urgency
  • Workaround
  • Request group
  • Revenue signal

Use this scoring (or something similar):

  • Paid user: +1
  • High-value account: +2
  • Blocking their work: +2
  • May cancel if not solved: +3
  • Manual workaround: +1
  • Paying for another tool or person: +2
  • Three or more similar requests: +2
  • Could become a higher-plan feature: +2

Once you have the final score, use it to choose the next action. Here’s an example:

  • 0 to 2: Backlog
  • 3 to 4: Follow-up question
  • 5 to 6: Customer interview
  • 7 to 8: Founder follow-up
  • 9 to 10: Smaller build or test pricing

Update these Airtable fields:

  • Revenue score
  • Decision
  • Decision reason

You now have a simple way to compare requests.

Step 9 — Send the right reply

Use the Decision field to choose the reply.

  • If Decision is Ask follow-up, send this (or something similar): Thanks for sharing this. Quick question: what are you trying to do that you cannot do today?
  • If Decision is Customer interview, send this (or something similar): Thanks for the request. This sounds like a real workflow problem. Would you be open to a quick 20-minute call so I can understand how you handle this today?
  • If the decision is Founder follow-up, send this (or something similar): Thanks for sending this. If we solved this well, would it help you upgrade, add more users, or replace another tool?
  • If Decision is Backlog, this (or something similar): Thanks for sharing this. We’ve saved your request and will review it with similar requests from other customers. I can’t promise it will be built, but it helps us make better product decisions.

Users now get the right response based on the value of the request.

Step 10 — Add a Slack alert for important requests

In Zapier, add a filter or path.

  • Use this rule: Continue only if Revenue signal is Expansion or Churn risk.
  • Then add this step: Slack → Send Channel Message

Send this message (or something similar):

Feature request needs review:
*  Customer: [Customer email]
*  Plan: [Customer plan]
*  Account value: [Account value]
*  Request: [Feature request]
*  Problem: [Problem]
*  AI summary: [AI summary]
*  Revenue signal: [Revenue signal]
*  Decision: [Decision]

Next step: Reply personally before adding this to the roadmap.

Now, important requests do not get buried.

Step 11 — Test money before building

Before you build a big feature, email the users who asked for it.

Send this (or something similar):

Hi [First Name],

Thanks again for sharing more about this.

We are considering a small version of this feature.

Before we build it, I want to understand how important it is to you.

If we solved this well, would it help you do one of these?
*   Upgrade to a higher plan    
*   Add more users    
*   Replace another tool    
*   Pay for it as an add-on    
*   Stay with us instead of switching
    

No pressure either way.

I’m asking so we make the right product decision.

Thanks,

[Your Name]

This way, you learn whether the request is connected to revenue.

Step 12 — Build the smallest useful version

If the signal is strong, build an MVP of the feature first.

on July 1, 2026
  1. 2

    Good points! Backlog management and scoring are two very important challenges.

  2. 1

    Most founders drown in feedback because they try to listen to everyone at once. Your workflow solves this by forcing a decision on every input. If you don't have a system to sort requests, you end up building things nobody actually needs. Keep the process fast so you spend your time building, not managing lists.

    1. 1

      I think the transparency is the real innovation here. Once scope changes are documented objectively, the conversation shifts from "I feel like this is extra work" to "Here's exactly what changed." That removes a lot of unnecessary friction for both sides.

  3. 1

    The revenue signal field is smart. The other thing that's easy to lose is the user's exact wording. The phrase they use to describe the pain often tells you more than the feature request itself, because you can hear whether it's annoyance, a workaround or real churn risk. I built DictaFlow, and some of our best decisions came from reading the raw "I keep fighting this in Gmail, Citrix, or notes" language before we ever turned it into a neat backlog card.

  4. 1

    The "revenue signal" step is the most important part. I built a small AI pipeline that checks for real money signals in feature requests (like "I'm paying $X for a workaround"). It prevented me from building 2 features that "felt" important but had no actual paying users waiting for them.

    How do you handle the gap between "sounds urgent" and "actually generates revenue" in your scoring?

  5. 1

    Step-11 is game changer

  6. 1

    Steps 1 through 10 are optional. Step 11 is the whole game. We once killed a feature three loud users begged for, then not one of them would pre-pay when asked. Willingness to pull out a card tells you more than any AI tag or score ever will.

  7. 1

    Thank you! This is very helpful. I can definitely use this as a reference for designing broader workflow systems.

  8. 1

    This is basically the n8n equivalent of what I'd build with Zapier here —
    solid workflow. One thing I've run into building similar pipelines (I do a
    lot of n8n + GPT-4o automation, including a tool that turns SOWs into
    project plans): the AI categorization step is usually reliable for clean
    requests, but breaks down on vague or multi-intent submissions ("can it
    also do X" buried inside a request about Y). Ended up adding a "confidence"
    field to the AI output so anything ambiguous gets flagged for manual review
    instead of silently mis-tagged. Might be worth adding a similar guardrail
    here before the scoring step, since a bad Category/Revenue signal call
    quietly skews your weekly review.

  9. 1

    The revenue signal taxonomy is what I've been missing. I've been
    treating all feedback equally — a "nice to have" from a free user
    gets the same attention as a "we might cancel" from a paying customer.
    That's a prioritization failure, not a product one.

    The Step 11 waitlist tweak is underrated. I'm currently validating
    a job board for bootstrapped startups and doing exactly this —
    Instead of building the full product, I launched a landing page
    with a "Post a Job" form and an email signup. The form submissions
    are my revenue signal. No submissions = wrong audience or wrong
    messaging. A handful = worth building.

    One thing I'd add to the scoring framework: weight recency. A
    request from 6 months ago from a churned user, and the same request
    from a new paying user this week, the signals aren't equal, even if the
    words are identical. Timestamp + current plan status together tell
    a cleaner story than either alone.

  10. 1

    A clean workflow — this is exactly the kind of system that keeps feature requests from turning into chaos.

    A simple way to think about it is that the goal isn’t to collect more feedback, it’s to separate signal from noise.
    When every request gets tagged, summarized, and routed, you stop guessing and start seeing patterns.
    Have you noticed how often the real product priority only becomes obvious after similar requests start clustering?

  11. 1

    One thing I've started realizing while building is that feature requests rarely tell you what to build—they tell you where people are struggling.

    For example, I originally thought I was building "portfolio tracking." But after talking to traders, I realized the real problem wasn't tracking prices—it was making better decisions after opening the app.

    That completely changed my roadmap. Now I spend much more time asking "what decision is the user trying to make?" than "what feature do they want?"

    Curious if you've ever had a customer request lead you to a completely different product direction than expected.

  12. 1

    The "before you build" discipline is the hardest thing to actually hold to my whole team's instinct is to open the design tool the second an idea sounds good. One thing that's helped us more than any workflow: we force the research to end in a decision ("build / don't / not yet"), not a document. A doc lets you keep deferring; a decision forces the call. Curious where your workflow lands does it output a checklist, or an actual go/no-go?

  13. 1

    the sleeper field here is "what are you doing today instead?" — a paid or manual workaround is the strongest build signal there is. customers describe solutions ("add this button"), but the workaround reveals the actual job. worth grouping by problem, not by requested feature — ten scattered requests often collapse into one missing capability.

  14. 1

    Really solid workflow. This is the kind of system I wish I had set up from day one instead of drowning in scattered requests.
    The most underrated field in this whole system is “What are you doing today instead?” Urgency is self-reported and inflated. Everyone says their request is important. But workarounds are behavioral evidence. Someone who says “I spend 45 minutes every Monday copying data by hand” has already proven the pain with their time. Someone paying for another tool has proven it with money. I’d almost weight the workaround answer higher than the urgency dropdown when scoring. Stated urgency lies. Revealed behavior doesn’t.

  15. 1

    I build an open source wiki tool (~500 GitHub stars). The most useful signal I got wasn't any single request — it was stepping back and noticing that the newest issues were all about file compatibility with Obsidian vaults and AI agent workflows. Nobody filed a ticket saying "make this more like an agent-readable knowledge base." But together, the requests told me something I hadn't expected about who was actually using the tool.

    The harder problem I'm still working through: I'm planning a hosted offering, and I know the waitlist validation only works if the right people land on the page. My current audience is mostly self-hosters. The person who'd actually pay for convenience hasn't found the tool yet.

    Still figuring that part out.

  16. 1

    Step 11 hits hard. I'm building FamiStream, a parental control app for IPTV. and I've been guilty of building features based on assumptions rather than testing willingness to pay first.
    The waitlist approach you mentioned in the comments is exactly what I'm doing now, but I never thought to use it for individual features too. Going to start asking waitlist signups which feature matters most to them before I build anything else.
    The revenue signal taxonomy is the part I'm taking away from this. Right now I treat all feedback equally. This changes that.

  17. 1

    The revenue signal taxonomy is the part that actually changes behavior. Most founders collect requests but have no framework for separating 'nice to have' from 'losing a customer if we don't ship this' — and those require completely different responses.

    The scoring weights feel right. Paying for a manual workaround (+2) might even deserve more weight — if someone is paying a third-party tool or a VA to compensate for your missing feature, that's almost always a high-intent signal and worth a direct founder call, not just a backlog entry.

    Step 11 (test money before building) is where a lot of teams skip and regret it later. One tweak: combine it with a waitlist for the feature. 'We're considering building this — if you'd pay for it, drop your email here.' Filters the politely enthusiastic from the genuinely blocked, fast.

    Great system overall — stealing the Airtable view structure.

  18. 1

    slowing the urge to build build build is the advice i needed when i launched my first startup!

    1. 1

      Ideation and building is a serious addiction which can only be cured by a strict dose of marketing reality.

Trending on Indie Hackers
I sold $6,773 in 2 weeks, with almost no existing community. User Avatar 52 comments Ferguson is LIVE on ProductHunt today... so I audited their homepage first! User Avatar 37 comments The hardest part isn't building anymore User Avatar 34 comments Why Remote Teams Stop Talking (And Don't Even Notice It) User Avatar 33 comments Built a local-first Amazon profit-by-SKU + QuickBooks/Xero journal tool. Looking for founding users. User Avatar 27 comments From Fractional CTO to Micro-SaaS: How 15 Unbilled Hours Inspired an AI Shield (And What the Data Says About V2) User Avatar 22 comments