The Slack shortcut we never managed to get rid of

From day one at my last company, we had to put a lot of time into onboarding and supporting our customers. The product was very technical and needed explaining, and getting onboarding right was critical to the value our customers got from it and therefore to the buying decision. So after the first call, we created a Slack channel for each customer to stay close. It took less than two minutes. Everyone agreed that this would only be temporary. As soon as things calmed down a bit and the organization became more “professional,” we would buy a proper support tool and move customer communication there.

Plot twist: things never calmed down.

I should add that most of this mess was my own doing. I joined as the Founding Sales Hire and ended up responsible for Growth and Customer Success, reporting directly to the CEO. I started in an operational role, then built and scaled the support team, managed a portfolio of 200+ accounts, and built the company’s entire Success and Support system myself. In other words: I’m the person who kept deciding that Slack would be fine for one more quarter.

And for a long time, it was better than the alternative. Customers had a direct line to us, without an annoying ticketing system or portal in the middle. Requests moved faster because there was no queue and no form to fill out first. Nobody landed in an anonymous inbox either: they got access to several real people with names, in a tool where they already spent a large part of their day.

What I underestimated at the time was the effect this had on what customers shared with us in the first place. A private Slack channel feels like a conversation, so people say things there that they would never put into a ticket form: half-formed feedback, what they are planning for next quarter, what annoys them but not enough to formally complain about it.

Three years later, that one decision had turned into an entire machine the company ran on. Onboarding happened in those channels. Escalations ran through those channels. Product questions, contract questions, bug reports, the occasional “anyone there?” at 11 p.m. on a Friday: everything happened in shared Slack channels, spread across all the customer accounts and partners we had. It worked. That was the confusing part. Deals happened partly because prospects had heard from others that we were easy to reach.

At some point, we still tried to roll it back. We had enough good reasons. Nothing was properly searchable, nobody could hand over an account cleanly, our reporting was fiction, and the knowledge of what was currently happening with a customer sat exclusively with the colleague who had last been active in the Slack channel.

Our customers hated the idea. Our partners even more. Nobody wanted to log into a portal to ask a short question they could quickly type into Slack. And once you have given a B2B customer that kind of access, taking it away feels like a massive step backwards, no matter how well you package it.

That reaction taught me more than the two years before it. The shortcut was right. The problem lay underneath it.

The question nobody could answer

At some point in the second year, the same question started coming from every direction: Customer Success before renewals, Product while prioritizing the roadmap, Marketing looking for case studies, Engineering researching complex problems, or the board in the quarterly deck.

Which customers were we actually doing well with?

Nobody could answer it. What did we do instead? Archaeology. “Someone” scrolled back through the channel to get a feel for the tone of the previous few weeks, asked the CSM whether something felt off, checked when the last real conversation had happened, and compared login numbers to see whether usage had dropped. Half a day per account, and what came out was a gut feeling with a chart next to it.

The pattern was predictable. Renewals surprised us in both directions. Accounts we had written off renewed. Accounts nobody was worried about churned, and when we did the post-mortem and went back through the channel, the signs were there in black and white. Six weeks earlier, unformatted in a message in a Slack thread, written by a customer on a Tuesday afternoon.

That inevitably led to the next question: “Why didn’t we notice this earlier?” The answer is simple: noise. With hundreds of internal and external Slack channels, a bad signal-to-noise ratio works against you. Signals like these getting lost is normal. Annoying? Absolutely, but normal.

That is the part that stayed with me. The information was there. It had been sitting in the channel for weeks. The customer had told us in their own words before the same signal became visible in a usage curve. Nobody had properly noticed or interpreted those words.

What we tried

We were one of Pylon’s first customers, and it helped more than anything else we had tried at the time. It gave us a real system for Slack at a time when most alternatives could not connect to Slack at all. Zendesk and Intercom are built for a different kind of business (B2C). In B2C, support means high volume from many individuals, most of whom you never hear from again. One support team owns the full interaction. The tools reflect that honestly. A ticket comes in, an agent closes it, and the case is complete.

B2B does not work like that. Support, Success, Product, Engineering, and whoever owns the commercial relationship all work on a single account. And they all need the same context for their part. What actually happens: the context gets broken into pieces. Support has the issue history. Success has the notes from the last call. Product has a feature request submitted three months ago by someone who no longer even works at the customer. Engineering has the Linear thread for a bug that nobody outside Engineering can read (or wants to).

So a customer asks a question and the answer costs four people, three internal threads, two syncs (to get everyone on the same page), and a day and a half. The customer experiences that as laziness. Internally, it looks as though everyone is doing their job properly. Nobody is doing anything wrong, and yet the whole thing crawls along. This is exactly the kind of problem that usually never gets fixed because there is no single person or single process at fault.

Most teams assemble the same stack instead: a helpdesk, a CRM, a notetaker, and Zapier or Make holding the tools together. That stack needs constant maintenance. And it moves records back and forth between systems without ever giving people a shared picture.

We still had gaps. Our product was technical and needed explaining. When we looked at how to implement AI and put it in front of customers, the answers came back shallow enough for someone paying four figures a month for our product to notice immediately. And a customer paying that much does not want a fast standard answer. They want their person, faster and better informed.

The models were fine. The problem lay on both sides of them. What we fed in was spread across several channels that nobody had ever properly mapped to the accounts. So a good model produced confident output from an incomplete picture, and that is worse than no output at all.

Nothing flowed back into the system either. When a Support Engineer rewrote a draft into the answer that was actually correct, that correction went exclusively to the customer and nowhere else. There was no reinforcement loop, no mechanism that could turn the best answer someone on the team had already written into the system’s answer the next time. Every question started from zero. The system never got better in our product, no matter how long we ran it.

There is a structural reason why this is difficult to retrofit later. Many tools reduce a conversation to whatever fits into a ticket record and sync only that record to the CRM. All that remains of the conversation itself is a thin summary. A model you add on top later reads exactly that thin summary. What was said and what sat between the lines is no longer in there. Anyone who wants to read what customers actually said needs the full conversation from the start, directly attached to the account.

Then I had time

My role at the company ended, and for the first time in years I had free time. I used it to sharpen my programming skills; I had started doing that a while earlier anyway. Part of the learning curve was steeper than I had initially expected, and that meant many nights spent on problems I had never needed to think about in a VP role. At three in the morning, my girlfriend found me in front of a YouTube video about JWTs, then one about AES. I took notes like I was studying for a university exam.

The side project turned into something bigger more quickly than expected. When it started to look like something real, I did what I definitely should have done first and started talking to the market: around 20 conversations with Support and Success leads at B2B companies. Three years had already answered whether the problem existed. I wanted to know whether other teams still saw it as a problem or had quietly accepted it. The same picture emerged in almost every call, usually in the same slightly embarrassed tone I knew from my own version of it. “Yes, we do it in Slack. Yes, we know the process isn’t ideal. No, we can’t tell you off the top of our heads which accounts we’re doing well with.”

That was enough to go all in. Friends who are CTOs at tech companies helped me with architecture and infrastructure. I am building the rest myself, and it is the first product I have built from start to finish.

What Aloy is

What I ultimately built was the tool I had wanted for three years. A tool used primarily by Customer Support and Customer Success teams that improves collaboration with other customer-facing teams and reduces the loss of context. My core principle: the internal Slack workspace, where nearly all communication happens, cannot feel like a foreign object. Aloy has to integrate seamlessly into existing systems and reach people where they already work.

So it does not matter whether you work directly from Slack, following your own system, or prefer to log into a web interface. If you prefer Claude Code, Codex, Cursor, or another IDE, our MCP server and CLI are set up in no time. You choose how you want to work. Aloy structures, organizes, and keeps the shared context intact for your colleagues.

Aloy keeps track of the conversations in the channels, processes them, and presents them clearly. It also captures additional health signals such as Vibe and Risk at the account and contact level. Health is one of the parts I cared most about getting right. Other tools track the proxies: logins, usage, number of issues, NPS, CSAT. Aloy tracks them too because they are real, deterministic signals that established Customer Support and Success metrics are based on. Aloy also reads what customers actually said in the channel. A proxy tells you that someone is no longer logging in. The conversation tells you why and often showed the problem weeks earlier.

The view from above has become increasingly important to me. When every conversation hangs on an account, the same question coming from customer after customer becomes a visible pattern: the integration that constantly breaks, the request that keeps appearing in slightly different words, the part of the product you always have to explain. We had this information at my last company too. It was spread across hundreds of channels and the memories of several people, which is practically the same as not having it.

Most of what Aloy does happens before anyone even sees a suggestion. Aloy watches the channels, catches signals as soon as they appear, and does the thankless work. That turns a stream of messages into a system you can work with: which account it belongs to, which contact, whether it is a new issue or the fourth follow-up on an old one, whether what was described matches something another customer mentioned last month. Nobody wants to build this part. And this exact part determines whether the AI on top is useful or confidently wrong.

Aloy suggests, drafts, and makes things visible. Aloy OS acts on its own when the underlying facts are measured and the action can be undone. Everything else reaches a human as a draft. Pylon has since repositioned itself as an Agentic Support Platform, and a large part of the tool category is moving in the same direction. I understand the appeal, and I think the default setting is crucial: in B2B, where a single account can represent a meaningful share of revenue, the person on the other side can tell the difference between an answer from your team and an answer from your AI stack.

This was the point in just about every discovery call where the mood was at risk of turning. As soon as I showed where Aloy acts on its own and how a human still remains in the loop, you could see the relief on the other side, despite the virtual meeting and the distance it inevitably creates.

Where Aloy stands today

Aloy will launch in Early Access in October 2026, registration is already open. During this time, Aloy will be free. There is a waitlist and a long backlog of things still to build.

There is no concrete two-year roadmap set in stone. What gets built next is based almost entirely on user feedback and how it fits into my vision for Aloy.

If you already communicate with customers over Slack or Teams and recognize parts of this story, I would like to hear from you. Tell me how you hand over accounts today, assess health, and keep agreements from disappearing in the channel. If Aloy fits your setup, I will be happy to bring you into Early Access.