What it actually takes to build AI feedback capture in-house

· [wtr-time]
What it actually takes to build AI feedback capture in-house

It sounds simple enough. AI reads your sales and support conversations, pulls out the feature requests, and files them neatly in your project tracker. Claude can do this with one prompt. How hard can it be?

Let’s go through it together. We’ll keep a running tally of engineering hours and monthly costs as we go, just like we did when we built a feedback portal.

Reading a conversation

Fable can legitimately do this in five minutes. Paste in a support ticket, get back the feature requests, bug reports, and pricing complaints inside it. It even quotes the customer.

Nobody on the team is impressed. It’s 2026. Everyone here has run this exact prompt. That’s precisely the trap: the demo is so easy that the project looks done before it starts.

Effort: 0 hours. Running total: 0 hours. Cost: $0/mo.

Extraction

We wire the prompt to our support tool’s API with a small script and run it on last week’s conversations.

Turns out most conversations aren’t feedback. Password resets. “Great support, thanks!” A customer venting about their day. The extractor dutifully files “customer seems frustrated” as a feature request.

So we tune the prompt. Then we build a benchmark set, because “seems better” is not a metric. Then we tune again. Precision versus recall makes its first appearance. It will not be the last.

The bill is real too. At our volume, about 2,500 support conversations and 400 sales calls a month, running a frontier model (like Fable) over everything lands around $3,000/mo. That’s not a typo. Sales transcripts are long, and frontier tokens aren’t cheap. Your number will vary with your volume, but it won’t be small.

Effort: 16 hours. Running total: 16 hours. Cost: $3,000/mo.

Model costs

$3,000/mo to read tickets will not survive a budget review.

The fix is a cheaper model. The catch is that cheaper models miss things. So we benchmark recall and precision across models, tune prompts for each, and decide how many missed feature requests we can live with.

One problem: benchmarks need labeled data. Hundreds of conversations, hand-labeled with the right answers. We don’t have that. Someone spends a week making it.

The bill drops to around $200/mo at our volume. The week is gone forever.

Effort: 20 hours. Running total: 36 hours. Cost: $200/mo.

The ingestion pipeline

A month in, a PM asks about a feature request she saw in a ticket. The pipeline never saw it.

Our little script, it turns out, has been quietly missing things. It dies on rate limits. It skips conversations that update after it runs. It double-processes others. Nobody noticed, because nobody notices missing data.

So we build it properly. Webhooks, plus polling to catch what webhooks miss. A queue with retries. A database, so every conversation is stored, tracked, and processed exactly once. A backfill job for everything we missed.

A pipeline is not a prompt. A pipeline is plumbing.

Effort: 24 hours. Running total: 60 hours. Cost: $220/mo.

Feedback types

We launched with feature requests. That lasted a month.

Support wants bug reports. Success wants churn reasons. Finance wants pricing feedback. Each type is a new prompt, a new benchmark, a new round of precision tuning, and a new debate about what counts. Is “the export is slow” a bug or a feature request? Two teams, two answers, one field in the database.

More types also means more AI passes per conversation. The bill ticks up.

Effort: 20 hours. Running total: 80 hours. Cost: $250/mo.

Do we already have this?

The pipeline keeps filing requests for features we already have.

Customers ask for things that shipped last year. They just never found them. The extractor doesn’t know our product, so it can’t tell “doesn’t exist” from “exists, but hidden.” Fixing that means keeping a synced list of what we’ve built and running one more AI check on every idea. One more prompt, one more benchmark, one more way to be subtly wrong.

Silver lining: requests for existing features are their own insight. That’s a discoverability problem, and someone should hear about it.

Effort: 20 hours. Running total: 100 hours. Cost: $250/mo.

Linear/Jira integration

Time to put ideas where engineering lives. New ideas create issues in Linear, with the customer quote attached. Honestly, this part isn’t so bad.

Then someone asks: when engineering ships an issue, can we find out? We’ll want that later. Two-way sync. Slightly worse.

Effort: 12 hours. Running total: 112 hours. Cost: $250/mo.

Deduplication

The pipeline runs. It works! Engineering asks us to please stop.

Most ideas already exist in Linear. The tenth request for SSO should attach to the SSO issue, not create “SSO (10).” Text search catches exact matches. Semantic search catches most of the rest. Then an LLM gets each new idea plus the closest candidates and makes the call: dupe or not, and of which issue.

On Jira? Worse news. Jira has no semantic search, so you’re building your own: embeddings for every issue, a vector index, kept in sync as issues change.

Then the familiar grind. Benchmark, tune, decide how many false merges you can tolerate versus how many dupes slip through. This takes weeks, not days.

Effort: 20 hours. Running total: 132 hours. Cost: $300/mo.

Auto grouping

A thousand ideas in a flat list is not organization. It’s a landfill with search.

Related ideas should cluster. Everything about exports in one group, everything about permissions in another. So the pipeline learns to group, which means deciding when two ideas are related but not duplicates. Somehow a harder question than when they’re the same. Another prompt, another benchmark, another precision target.

Effort: 20 hours. Running total: 152 hours. Cost: $300/mo.

Theme detection

Leadership doesn’t want a thousand ideas. They want five themes.

“What are customers complaining about this quarter?” should have an answer. So we build theme detection: recurring topics, tracked over time, with movement up and down. The themes have to stay stable month to month, or the trend chart is fiction. Stability is its own tuning problem, and yes, its own benchmark.

Effort: 20 hours. Running total: 172 hours. Cost: $300/mo.

Traceability

A PM asks: “Who actually asked for this?”

Fair question. An idea without receipts is just a sentence. So every idea needs links back to its source conversations, the customer quotes, and the people who asked. When the tenth request attaches to the SSO issue, all ten requesters should be listed on it.

Now the pipeline has memory, and the memory needs a schema.

Effort: 12 hours. Running total: 184 hours. Cost: $300/mo.

Undoing actions

The AI files an idea under the wrong group. It merges two requests that aren’t duplicates. It doesn’t happen often, but it happens.

The first time it happens, a PM asks two questions: why did it do that, and how do I fix it? So every automated action needs a trail, merges need to be reversible without losing the linked conversations, and a human’s correction has to survive the next pipeline run. Otherwise the AI quietly re-makes the same mistake tomorrow night.

In Canny, undo is a button. In your pipeline, undo is a Slack message to whoever built it.

Effort: 20 hours. Running total: 204 hours. Cost: $300/mo.

Form CTA

Connecting all the sources

Support was just the beginning.

Sales wants their calls in there, so we integrate Gong. Except half the AEs use a different recorder. CS runs on a different tool entirely. Then someone asks about NPS surveys. Then app store reviews. Then G2.

Every source is a new integration: new API, new auth, new data shape, new failure modes. Then the sales team switches tools next quarter, and we rebuild one from scratch. The pipeline never gets finished. It just gets more inputs.

Every new source is also more volume, and the AI bill grows with it.

Effort: 32 hours. Running total: 236 hours. Cost: $380/mo.

CRM integration

We now know what customers want. We don’t know what it’s worth.

An idea plus a list of users is only so useful. It gets really useful when those users roll up to companies, the companies have revenue attached, and open deals link to the features blocking them. “27 people want SSO” is interesting. “SSO is blocking $840k in pipeline” gets a meeting.

So we sync account and opportunity data from Salesforce or HubSpot. Field mapping, sync jobs, rate limits, retries. Someone owns that sync now. Forever. They know who they are.

Effort: 24 hours. Running total: 260 hours. Cost: $380/mo.

Deal filters

Sales lives in segments. “Show me feedback from deals we lost last quarter.” “Just open opportunities.” “Only deals closing this quarter.” “New business only, not renewals.”

Each filter is easy. Supporting all of them means the CRM sync has to carry deal stages, close dates, amounts, and deal types, and keep them all fresh. A filter on stale data is a lie with a dropdown.

Effort: 8 hours. Running total: 268 hours. Cost: $380/mo.

User segmentation

Same story on the customer side. “Only companies paying over $50k.” “Only the enterprise plan.” “Only accounts using the API product.”

So we sync company traits from billing and our app, then build the filtering UI. Then we keep the traits fresh, because stale data is worse than none.

Effort: 8 hours. Running total: 276 hours. Cost: $380/mo.

Reporting

Leadership has questions. Which features will help us close deals? Which deals are blocked right now, and on what? We shipped three of those features last quarter. Did the deals actually close?

That last one is the killer. Answering it means joining feedback, issues, and CRM history across time. We build dashboards. Every exec wants a slightly different slice, and every slice is a ticket.

Effort: 24 hours. Running total: 300 hours. Cost: $380/mo.

MCP access

The team is living in Claude now. They don’t want another dashboard. They want to ask: “What are enterprise customers complaining about this month?” “Do we already have this feature?”

So we build an MCP server over the data: the ideas, the themes, the customer quotes behind them. Tool definitions, authentication, updates every time the schema changes. It’s genuinely useful. It’s also a second interface to maintain, and it has to respect every permission rule the first one has.

We take a moment. We built an AI pipeline to avoid buying an AI tool, and now we’re building AI tooling so our AI can read our AI pipeline.

Effort: 8 hours. Running total: 308 hours. Cost: $380/mo.

Team notifications

A feature ships. Three closed-lost deals wanted it. Nobody tells the reps.

So we build notifications. When an issue ships, the AEs and CSMs whose accounts asked for it get a ping: “Acme wanted this. It’s live. Go win them back.” It’s one of the most valuable things in the whole system. It’s also a join across feedback, issues, accounts, and deal owners that has to stay accurate forever.

Effort: 8 hours. Running total: 316 hours. Cost: $380/mo.

Close the loop

Then the bigger version: email every customer who asked for a feature when it ships.

Which means we’re sending email now. A provider, a send queue, unsubscribe links, a preferences page. Bounce handling, because sending to dead addresses tanks deliverability, and once our sender reputation slips, every email we send lands in spam. Sanitizing anything user-generated that ends up in an email. Email is an entire discipline, and now it’s ours, bolted onto the side of a data pipeline.

Effort: 16 hours. Running total: 332 hours. Cost: $400/mo.

Privacy

It hits us one night. We built a database that stores copies of every customer conversation. Support tickets, sales calls, all of it. Names, emails, the occasional pasted API key.

That needs access controls, a retention policy, and deletion that actually works. When a customer deletes their data in the support tool, our copy has to go too. GDPR doesn’t care that our copy lives in a side project.

Effort: 12 hours. Running total: 344 hours. Cost: $400/mo.

SOC 2

A prospect’s security team sends a questionnaire. One question: “Do any internal tools process customer conversation data?”

Yes. Yes they do. The pipeline is now in scope for our SOC 2 audit. Access reviews, evidence collection, a pen test that covers one more application, vulnerability scanning, a slightly pricier audit. Call it another $300/mo once the annual bills are amortized.

Our compliance lead just learned the pipeline exists. They have follow-up questions.

Effort: 12 hours. Running total: 356 hours. Cost: $700/mo.

And this is just the start

One morning, an email arrives: the model we tuned everything on is being deprecated in 90 days.

Every prompt, every benchmark, every precision number we fought for, re-validated against its replacement. This will happen again, roughly once a year. It’s nobody’s fault. It’s just weather now, and we live in it.

That’s one storm. There’s also the customer who writes in German. The exec who wants Zoom calls in the pipeline. The quarter where support volume triples, and so does the bill.

A pipeline isn’t a project with an end date. It’s a subscription you pay in engineers.

The real cost

Notice what the tally doesn’t include: an owner.

Every pipeline needs one. Someone who re-runs the benchmarks, fixes the Gong sync, answers “why did it miss this ticket.” That person is one of your best engineers, because accuracy work is hard. Now a chunk of their year belongs to an internal tool.

The worse version is having no owner. The pipeline drifts, the numbers quietly rot, and the roadmap meeting runs on data nobody can vouch for. A wrong number in that meeting costs more than every line item in this post. You’ll just never see the invoice.

You wanted this automated because the decisions riding on feedback are big ones. That logic cuts both ways. The bigger the decisions, the less you want them running on a side project.

Ours isn’t a side project. It’s the whole company.

Was it worth it?

Read the tally back. 356 hours. Twenty-seven grand of engineering time, $700 a month in bills, a quarter and a half on the calendar. For a pipeline that does, roughly, what the five-minute demo appeared to do.

Most internal tools degrade gracefully. Half-finished, they’re still half-useful. This one isn’t. If the pipeline misses a third of the feedback, or invents requests nobody made, your team notices. They stop trusting it, and they quietly go back to gut feel. Below a certain accuracy bar, the whole thing is a decoration.

Getting above that bar is the real work. It’s why a third of the tally is pure benchmarking. It’s also where a decade matters. To know whether a model is good enough, you need datasets to benchmark against. We spent a long time building ours, and we re-run those benchmarks every time a model changes, a prompt changes, or a new feedback type ships. That’s how Autopilot gets high accuracy without flagship costs. You’d be starting that work from zero, at flagship prices.

So sure, spend the quarter. Or spend an afternoon connecting your tools to Autopilot, and spend the quarter on the product your customers are giving you all this feedback about.

They’re already telling you what to build. Don’t make hearing them a side project.

Get a free walkthrough
author avatar
Andrew Rasmussen
Hi, I'm a co-founder of Canny. Before that, I was a software engineer at Facebook. I love JavaScript, rock climbing, nerding out about the future, and SaaS.
Canny is a user feedback tool. We help software companies track feedback to build better products.