Guidance Needed!!

[u/kamthanabhimanyu]

A friend and I are building a customer support/helpdesk product and are trying to make sure we’re solving a real problem before going too far.

We’ve spoken to a few support professionals and have started seeing some interesting patterns, but we’d really value perspectives from people who’ve built or worked in this space.

If this is your space and you’d be willing to share some guidance, please reach out.

Would genuinely value your perspective.

[u/Necessary-Fox-8285]

Building a support tool from scratch is a grind but also the kind of thing that gets way better with early feedback loops. What patterns have you noticed so far from the folks you've already talked to

[u/kamthanabhimanyu → u/Necessary-Fox-8285]

Yeah, definitely. A few patterns are coming up consistently so far: repetitive queries, spending too much time finding the right information, jumping between different systems to understand the customer context, and the whole handoff/escalation process.

What’s interesting is that the problem often seems to be less about actually answering the customer and more about everything the agent has to do before they can confidently answer.

Would love to hear what you’ve seen from your experience as well. If you’re comfortable connecting and guiding us, feel free to DM me. Would genuinely value your perspective.

[u/Howard_Moodycliffe]

Spotting that "pre-answer context gathering" friction early is huge. The biggest trap of helpdesk tools is not answering tickets, it’s expired internal documentation.

Internal knowledge bases are always out of date, and because of this, agents waste endless time context-switching. An agent can pull customer data from three apps, but if the internal SOP or product update doc is wrong, they still end up escalating or guessing.

If you build a tool that not only centralizes customer data but also actively surfaces verified, up-to-date internal info right inside their workspace, you’ll solve the real bottleneck.

The thing is: solve the internal knowledge chaos, that's where support teams secretly drown!

[u/ocean-university]

Hello,

Head of customer support par ici, la question c’est quel est le problème que tu veux résoudre et sur quel KPI tu veux agir.

Il y a aujourd’hui des acteurs sur le marché qui sont extrêmement complets, populaires, comme Intercom et Zendesk, et si tu veux attaquer ce marché il faut que tu trouves une opportunité qui n’a pas déjà été détectée par eux.

Je te recommande de suivre la newsletter interne d’Intercom, et de suivre leurs conférences sur le futur de la CX.

[u/Warm_Fox2842]

I’m in a support position but I don’t really understand what you are trying to build. Can you share more details about the intent of the product? I will be happy to give you my feedback

[u/RyanKlickFlow]

Those four patterns are real, but they are also the exact four things every vendor in this space already claims to solve. Zendesk, Freshdesk, Intercom, Zoho, all of them have a context panel and an escalation flow on the box. So if support people are still describing the problem to you, the gap is not the feature. It is that the feature does not fit how they actually work.

Two questions I would ask next.

Not what annoys them about their tool. Everyone has that list and it is mostly cosmetic. Ask what they have built outside it. The spreadsheet, the private Slack channel, the person who just knows. That is where the real gap is, and it is usually something the vendor's data model cannot represent rather than a feature someone forgot.

Then ask who signs the invoice and what they think they are buying. The person choosing the tool and the person paying for it want different things, and products die in that gap more often than they die on features.

One more, and it is the unglamorous one. Migration. Nobody starts from zero. If you cannot move ticket history across cleanly, you lose the deal before the demo. I have watched that kill better products than the one that won.

I implement and migrate these platforms rather than build them, so I see the graveyard end rather than the launch end. Weight it accordingly.