Guide: Using custom tags to track feature requests across customer calls

Nice approach. I've done something similar but found the manual tagging becomes a bottleneck once you're processing more than a handful of calls a week.

Have you looked into running the transcripts through a lightweight sentiment or keyword classifier first? I built a small service that sits between tl;dv and my Notion, flagging segments that contain phrases like "I wish" or "it would be better if" for pre-tagging as potential feature requests. It cuts down the review time dramatically.

The search function is great, but you're still dependent on someone remembering to apply the tag consistently during review.

That's a smart workaround for the scaling issue. I hit the same wall last year.

Your point about consistency is key. Even with a classifier, you still need a human to verify the "pre-tagged" segments, right? I tried something similar but found the classifier pulled in a lot of general feedback that wasn't actually a feature request. The noise almost canceled out the time saved.

How do you handle the false positives from phrases like "I wish"? Do you just accept a lower accuracy for the sake of volume?

Yeah, the false positive problem is real. I ran into something similar when I tried using a basic regex pattern on support chat logs to find feature requests.

That "I wish" pattern would catch things like "I wish I'd known about your pricing earlier," which is just a comment, not a request. I started adding a second check for a noun or product name right after the phrase. It got messy fast.

Do you think a hybrid approach would work? Like, let the classifier flag anything with medium confidence, but only auto-tag segments that also contain a product-related keyword from a list? That might cut the noise without going full manual.

That's a solid foundation! I'm a big fan of manual tagging for establishing a clean dataset, especially when you're just starting out. It forces you to really think about what constitutes a feature request vs. general feedback.

One thing I'd add is to consider using those tags as triggers for automation later. For example, when you tag something `#feature-request`, you could have a little Zapier or Make flow that automatically creates a card in a "Customer Requests" column on a Trello board. It saves the step of manually compiling them later.

How are you handling duplicate or similar requests across different calls? Do you merge them somehow?

Good in theory. The second you scale, it falls apart.

Manual tagging is only reliable if one person does every review call. I've seen this fail hard when a team tries it. Tag definitions drift, people miss things, and your quarterly list is suddenly full of noise.

If this is your process, you better have a solid audit trail for how each tag was applied. Otherwise, good luck explaining your priority list to anyone who asks.

That's a valid concern about scaling. I've seen this drift happen even within small teams in our benefits admin space, where a term like "integration" can mean anything from a full API connector to a simple file upload.

Would a shared tagging rubric help? A simple document defining each tag with examples and common false positives. It wouldn't solve everything, but it could anchor the definitions. The audit trail you mention is harder. Do you know of any tools that log who tagged what and when?

A shared rubric is a good starting point, but it's static. The real problem is that people stop checking it after a week.

For an audit trail, some helpdesk platforms keep this data in their change logs natively. If your tagging happens inside a tool like that, you can pull a report on tag additions. Otherwise, you're looking at a custom field with history tracking turned on, which not every app supports.

Have you considered using a dedicated tagging tool like SproutSocial or Clarabridge for this? They're built for consistent team tagging with full attribution. Might be overkill for just this one use case, though.

Nice to see someone embracing a simple, direct tagging system. It's often the best way to start.

One thing I'd consider adding early is a quick definition for each tag. For example, what exactly separates a `#ui-pain` from a `#feature-request`? Getting that down, even just a sentence, can prevent confusion later when you're looking back at old tags.

That manual review step, while time-consuming at first, really does build a stronger understanding of your customers' needs than any automated scan. It's a great foundation.

You're right about the static rubric problem. We experienced the same drift even after creating a detailed document for tagging reserved instance purchases. People default to their own interpretations.

The dedicated tool suggestion is interesting, but as you noted, it's often overkill. A middle ground we found effective is baking the rubric into the tagging interface itself. We used a simple script to add a tooltip or a short example next to each tag field in our internal dashboard. It's a lightweight, always-visible reminder that helps anchor the definitions without requiring a separate document lookup.

For the audit trail, if you're already using a CRM like Salesforce or HubSpot for customer calls, their field history tracking can serve this purpose without needing a new tool.

What you're calling a game-changer is just the first step of a functional pipeline. If you stop there, you're just moving the mess from a spreadsheet into a siloed tool.

You mentioned using search to compile lists. That's fine for you, but it doesn't scale. The real value is in the metadata. You need to start enriching those tags immediately. For every `#feature-request`, you should be forcing a second tag for the product area (`#product:api`, `#product:billing`) and a priority hint (`#impact:high`, `#impact:low`) based on the customer's expressed frustration level. Otherwise, your quarterly list is just a flat dump of 200 requests with no way to triage.

Also, tl;dv is a transcript source, not a system of record. Your process needs an export and transformation step. I push all tagged segments nightly to a dedicated Postgres table. That lets me run real queries: "Show me all `#feature-request` tagged items from Enterprise-tier customers in the last quarter, grouped by product area." You can't do that in a vendor search bar.

If you're not planning for how this data gets structured and queried outside the tool, you're just creating a new, slightly prettier pile of notes.

It's great that you're building a discipline around capturing these moments. That manual review step, while simple, is where you really learn what your customers are trying to express.

I'd gently push on one thing, though. Relying solely on search inside a single tool can create a blind spot. How do you plan to connect a `#feature-request` from a call last quarter to the one that came in from support yesterday? You might consider a weekly habit of exporting those tagged moments to a shared doc or board, just to bridge the silos.

"Game-changer" is a bit much for what's basically a basic tagging system you're locking into a vendor's ecosystem. That search function is only a breeze until you're locked out of their API or they change their pricing tier. You're just building a nicer looking silo.

You're also missing the business case for any of it. How do you correlate a tagged feature request from a call with the actual renewal value or contract size of the customer who asked for it? You're counting requests, not weighting them. A request from a client about to churn over it matters more than ten from casual users, but your tags won't tell you that. Your quarterly list will be dangerously democratic.

This is a solid foundation for structuring unstructured feedback, but treating it as a complete solution misses the operational lifecycle of a feature request. You've described the annotation step, but not the orchestration.

The moment you tag something as `#feature-request`, it should trigger a workflow. Where does that request go next? Your engineering backlog? A product management tool? The search function is for retrieval, but you need a defined export and sync mechanism, preferably automated, to a system where the request can be prioritized, debated, and tracked to closure. Without that, you've just created a more organized collection of sticky notes.

Also, consider the data model. A flat tag like `#integration` becomes ambiguous at scale. You'll eventually need structured metadata attached to the tag, like `#integration:payment-gateway` or `#integration-type:api`. Starting with a hierarchical or namespaced convention from day one saves a painful refactor later when you have thousands of tagged entries.

Completely agree on the workflow trigger. We use a simple webhook from our call tagging tool to automatically create a ticket in Jira. When a `#feature-request` is applied, the webhook fires, formats the call snippet and context, and posts it to a backlog project with a "Needs Triage" status. It's a small piece of automation but it bridges the gap you mentioned.

Your point about the data model is crucial too. We learned that lesson the hard way with `#cost-optimization`. Now we enforce a colon convention, like `#cost:savingsplan` or `#cost:reserved-instances`. Starting with that structure is way easier.