How Cavyro Reinvented CRM for Telegram Deals, Not Inbox-Based Messaging

I was doing BD in Web3, which in practice means you live in Telegram. Deals happen in DMs, and the bigger ones happen in group chats with people from both sides sitting in them. There was no system anywhere. Just chats. The thing I remember is a Monday call where someone asked what we had in the pipeline, and the answer was that we'd have to go read our own messages to find out. So we did, and one deal had been sitting untouched for three weeks. Nobody dropped it deliberately. It wasn't anywhere to be dropped from. If the person who owned that conversation was busy that week, or away, or eventually gone, the deal went with them. Then I looked at what existed. Shared inboxes came closest, and to be fair, they're good at making a pile of messages manageable, but they forget a conversation the moment it goes quiet, which is exactly when a sales deal needs remembering. The bot-based ones I couldn't use at all. A bot only sees what gets sent to it, so my existing chats, groups, and history simply weren't there, and customers would have had to start writing to some new account first. A couple of others were bulk senders with a CRM label on the box. What I wanted was fairly boring, the chat itself as the record, tied to a contact, sitting on a pipeline with an owner and a next step, and the history staying put when people leave. Telegram as a real channel inside a CRM, not a CRM squeezed into an inbox. That didn't exist, so I ended up building it.

The one that worked wasn't really planned as marketing. We built an MCP server because I wanted to run the CRM from Claude myself, then wrote a post explaining how. Somewhere along the way, we also made the site readable by agents, so llms.txt, markdown at every URL, listings in the MCP registries. All of that felt like plumbing at the time. It turned into our best channel. People building with AI agents look for things to plug in, they find you through those registries or through whatever a model answers when someone asks it for a CRM with a decent API, and they turn up already knowing what the product does. Half the conversation is over before we say anything. It also helped that nobody else in the Telegram CRM space was doing any of it, probably more than the work itself deserved. Paid ads were the flop. We bought the obvious searches, "Telegram CRM" and the variations around it, and it never came close to paying for itself. Clicks were expensive, the intent was mostly wrong (a lot of people hunting for a chatbot builder), and there simply aren't enough people typing that phrase to build anything on. The audience sits in group chats and communities where no ad platform can target them, and more budget doesn't fix that. We stopped after a few weeks and put the money into content and the site instead.

Honestly, we're early, so I won't pretend there's a wall of angry feedback to manage. It's small internal teams using Cavyro day to day, and what comes back is requests far more than complaints. The pattern is nearly always some version of "can it also do X." Sometimes X is a genuine hole. Tasks with due dates is one we hear repeatedly, and that's fair, we don't have them yet. More often, X is something every general CRM has, that we left out on purpose, because adding it would drag the product back towards being a generic CRM with Telegram bolted on the side, which is the exact thing we were trying not to build. So we try to ask what the person is actually trying to get done rather than take the feature request at face value. Quite often, the underlying job is already possible and we've just buried it, which is a copy or a UX problem rather than a missing feature, and those we fix quickly. If a request fits where the product is going, it ships fast. If it would make Cavyro look like everything else, it gets a no, and I'd rather explain why than park it on a roadmap forever and quietly never do it. That balance is most of the job, really. Listening properly without letting the product turn into whatever the last person asked for.

Most people still file Telegram under messaging, or worse, under support. That assumption is baked into nearly every tool in the category, which is why they all end up shaped like inboxes, with queues, assignment rules, and SLA timers. That isn't how these teams use it. In web3, in agencies, in plenty of markets outside the US, Telegram isn't one channel alongside email. It's the channel. First contact, the negotiation, the contract argument, the complaining afterward - all of it happens there, and the deals that matter usually happen in a group chat with people from both companies sitting in it. That's a deal with a value, an owner, and a next step, not a ticket somebody needs to close by Friday. The second thing people get wrong is more technical, and it's the one that catches teams out when they go shopping. They assume you connect a CRM to Telegram with a bot because that's how it works nearly everywhere else. A bot is a separate account, and it only knows about messages sent to it, so everything you've already built up is invisible to it, and your customers would have to go start a fresh conversation with a robot before any of it counts for anything. Connect through the real accounts your team already uses, and all of that history just comes over. From the customer's side, nothing changed at all.

Mostly marketing, which isn't the answer I expected to be giving a year ago. The product's in decent shape. It does more than you'd guess from the outside, and that's half the problem because hardly anyone knows it exists. So the next six to twelve months go into visibility. Domain authority is the boring version of that, getting listed in places that actually carry weight, earning links rather than buying them, keeping the comparison and use case pages sharp because those are the searches people run when they're already thinking about switching. The AI side matters too. A lot of this category now gets researched by asking a model, and I'd like us to be in that answer. Once there are enough customers to ask without embarrassing myself, we'll chase reviews properly. We'll keep shipping, just narrowly. Tasks are coming, people keep asking. Past that, whatever current users trip over. More surface area wouldn't move anything right now.

Nothing worth bragging about yet. We're still early, small internal teams using it day to day. Ask me again in six months, and I'll gladly come back with a real number. :)

Not from scratch, though not from a CRM background either. I started in sales at an ISP, which is close to fifteen years ago now, and that's where I learned what a pipeline is in the least glamorous way possible, by carrying one. Then I moved into SaaS and spent years at ActiveCollab and Cake.com, both out of Novi Sad. Two good companies, and I got to watch products actually get built and sold up close rather than read about how it's supposed to work. That's most of my working life. Web3 came after that, and it's where this whole thing started. Everything there runs through Telegram, support and BD alike, and doing that job with no system underneath it is genuinely miserable. So I had the SaaS years telling me what decent tooling looks like, and the Web3 years handing me the problem every single day. At some point, it stopped feeling like a gap in the market I'd noticed and started feeling like something I should go and build.

Ask me in a year. The real one probably hasn't shown up yet, and I'd rather not invent a tidy lesson for the sake of the question. If I had to guess now, it's that we built too much before telling anyone. Cavyro does a lot, and all of that was time spent heads down instead of out talking to people who'd actually use it. The part I can already feel is that we worked out how to describe the product long after we'd finished building it, which is the wrong way round. Then again, most of what makes it worth using came from having the problem myself and building the answer I wanted, and I'm not sure that survives being designed in public by committee. So I genuinely don't know yet whether it was a mistake or just the order it had to happen in. Give it a year and I'll have a better answer, probably a more expensive one.