Build a Feature Request Form → CRM Note + PM Slack + Sheets Log Workflow with n8n
Feature requests are where product momentum quietly dies. A customer takes the time to tell you exactly what they need, and that gold gets buried in a shared inbox, a Slack DM someone forgot to star,
Feature requests are where product momentum quietly dies. A customer takes the time to tell you exactly what they need, and that gold gets buried in a shared inbox, a Slack DM someone forgot to star, or a support ticket that closes before anyone in product ever reads it. Multiply that by every request across every channel and you get the same outcome most teams live with: no single source of truth, no visibility for your PM, and no way to spot the pattern when five customers ask for the same thing in the same week. This article shows you how to wire a single Typeform submission to do four jobs at once — log to your CRM, alert your product team, archive to a spreadsheet, and confirm to the customer — using one n8n workflow you can install in an afternoon.
The Problem: Feature Requests Leak Out of Every Channel
The core issue isn't that customers don't tell you what they want. It's that the signal arrives fragmented and never gets consolidated. Support handles some, sales forwards others, founders field a few personally, and each one lands in a different system with a different owner. By the time you sit down to plan a roadmap, you're reconstructing demand from memory instead of reading it off a ledger.
The downstream costs are concrete. Your PM has no live queue, so prioritization becomes a guessing game. Your CRM has no record that a paying account asked for something, so you can't tie feature demand to revenue or churn risk. And the customer who took two minutes to write a thoughtful request hears nothing back — which trains them to stop bothering. Manual triage doesn't scale past a handful of requests a week, and hiring someone to copy-paste between Slack, HubSpot, and Sheets is exactly the kind of glue work automation exists to kill.
The Solution: One Form, Four Automated Destinations
This workflow treats the feature request as a structured event and fans it out to every system that needs it, instantly and without a human in the loop. A customer submits a Typeform. n8n catches the submission and, in parallel, does four things:
- Writes a note to HubSpot against the matching contact, so the request lives inside your CRM next to the account's deal and history.
- Posts to your PM channel in Slack with the request, the customer, and a clean summary the product team can triage immediately.
- Appends a row to Google Sheets, building a permanent, sortable log you can pivot, tag, and count for roadmap planning.
- Sends a confirmation to the customer, closing the loop so they know a human — or at least a very organized machine — received it.
Nothing is retyped. Nothing depends on someone remembering to forward an email. The moment the form is submitted, the request exists in your CRM, your team's chat, and your data warehouse simultaneously.
Step-by-Step: Building It in n8n
The whole workflow is six nodes. Here's how each one is configured.
1. Typeform Trigger. Add the Typeform Trigger node and connect your Typeform account via OAuth2. Select your feature-request form from the dropdown. n8n registers a webhook with Typeform automatically, so submissions arrive in real time with no polling. Each answer comes through keyed by field, so map your form fields deliberately: a short "What do you want?" text field, a longer "Why?" field, and — critically — an email field so you can match the request to a CRM contact later.
2. Set / Edit Fields node. Drop a Set node right after the trigger to normalize the payload. Typeform's raw output uses field references and nested answer arrays that are painful to reference downstream. Map them once here into clean variables: {{ $json.email }}, {{ $json.request }}, {{ $json.reason }}, and a timestamp with {{ $now.toISO() }}. Every node after this reads from stable names instead of Typeform's structure.
3. HubSpot node. Set the resource to Contact and operation to Create or Update (upsert), using the customer email as the unique key — this ensures you attach the note to the right person whether or not they already exist. Then chain a second HubSpot node with resource Engagement (or a Note) and paste the request text into the body, associating it with the contact ID returned by the first node. Authenticate with a HubSpot Private App token rather than a legacy API key.
4. Slack node. Set operation to Send a Message, pick your product channel (e.g. #product-requests), and build a readable message with Block Kit or simple markdown: *New feature request* from {{ $json.email }}\n>{{ $json.request }}\n_Reason:_ {{ $json.reason }}. Use a Slack bot token with chat:write scope. Adding the customer's plan or MRR here — if you pass it from HubSpot — turns the message into an instant prioritization signal.
5. Google Sheets node. Operation Append Row, pointed at a "Feature Requests" spreadsheet. Map columns for timestamp, email, request, reason, and a blank status column your PM can update to reviewing or shipped. This sheet becomes your master log — the one place you can count how many times a request repeats.
6. Send confirmation. Finish with an email node (Gmail, SMTP, or your ESP) or a second Typeform-style thank-you, addressed to {{ $json.email }}, confirming the request landed and setting expectations on follow-up. Wire the HubSpot, Slack, Sheets, and email nodes to run off the same Set node so they execute in parallel — the confirmation shouldn't wait on the CRM write to finish.
The Payoff: Visibility, Speed, and a Real Demand Ledger
Once this is live, three things change immediately. Your PM opens Slack and sees requests as they arrive, with enough context to triage without chasing anyone. Your CRM becomes a demand map — you can filter contacts by who asked for what and correlate feature requests with expansion or churn. And your Google Sheet quietly compounds into the most valuable roadmap artifact you have: a counted, timestamped record of what customers actually want, ranked by frequency instead of by whoever argued loudest in the last planning meeting.
The time savings are real but secondary. The bigger win is that no request is ever lost again, and every customer gets acknowledged automatically. That combination — zero leakage plus consistent follow-up — is what separates teams that build what customers want from teams that guess.
Common Pitfalls (and How to Avoid Them)
Skipping the email field. Without a reliable customer identifier, your HubSpot upsert has nothing to match on and your requests pile up as orphaned notes. Make the email field required in Typeform.
Letting one failed node kill the whole run. If HubSpot rate-limits or Slack's token expires, you don't want to lose the Sheets log too. Set the Slack and confirmation nodes to Continue On Fail in their settings, and consider an Error Trigger workflow that pings you when something breaks so failures surface instead of vanishing.
Trusting raw Typeform output. Referencing Typeform's nested answer structure directly across five nodes means one form edit can break everything. The Set node in step 2 is your insurance — normalize once, reference everywhere.
Duplicate contacts in HubSpot. Using Create instead of Create or Update spawns a new contact on every submission. Always upsert on email.
Noisy Slack channel. If volume is high, batch or route by keyword rather than firing every single request into one channel — otherwise your PM starts ignoring it, which defeats the purpose. A simple Switch node on request type can send billing asks to one channel and product asks to another.
Build it once, test with a real submission end to end, and you have a feature-request pipeline that runs itself while you focus on shipping.
Ja construimos isso pra voce
Nao comece do zero. O Feature Request Form → CRM Note + PM Slack + Sheets Log e um workflow n8n pronto para instalar — conecta suas ferramentas em minutos, sem codigo.
Instalar por $79 →
