How Do You Sell AI?
A founder's account of learning which problems AI can solve, how enterprise sales changes the product, and why distribution cannot rescue a product without a clear problem.
Distribution can’t rescue a product whose problem you haven’t found yet.
Selling AI has been one of the hardest things I’ve done. I say that having spent a good part of my career in growth, working across organisations including Meta, Turing, Datamellon and Deloitte, where I learned different ways of taking products to market, particularly through communities and developer-led growth. Some of those instincts have been useful, but nothing quite prepared me for selling AI because almost everyone was starting from zero. People who had spent years selling enterprise software probably had an advantage in understanding procurement, decision makers and long sales cycles, but they were still selling something whose economics, buying behaviour and even definition were changing underneath them.
Part of the problem is that AI looks enough like software that the instinct is to sell it like software. SaaS gave us a fairly convenient commercial abstraction in the seat. A company buys software for 100 employees and pays for 100 seats, while the infrastructure underneath the product is largely abstracted away from the buyer. AI changes that because usage has a much more direct relationship with cost. Underneath the application there are tokens, inference and compute, and depending on what you’re building there may also be speech models, telephony and other infrastructure. If usage increases dramatically, your cost can increase with it. The economics become even stranger with agents because five employees might supervise a system that speaks to 100,000 customers. Charging for five seats doesn’t represent the work being done, while exposing the customer directly to every token, minute and infrastructure cost isn’t particularly useful either. We have been trying to understand what the right commercial abstraction is while simultaneously trying to understand what people actually want AI to do.
We started with commerce
Our original view was that the frontier model companies would continue going horizontally across the software stack rather than verticalising deeply into every industry, leaving room for companies like ours to take the underlying intelligence and build more specific applications on top. We started with SMBs and eventually narrowed our attention towards commerce. Restaurants looked particularly interesting because they generate a lot of transactional data and ordering seemed like a workflow that could be decomposed into a conversational experience. Instead of opening a website, moving through a menu, adding items to a basket and checking out, we thought customers could simply tell an AI what they wanted. We built experiences around WhatsApp and Instagram that allowed people to interact with restaurants and place orders conversationally, and technically it worked. What we hadn’t established was whether decomposing an existing ordering experience into text actually made the experience better.
That distinction became clearer when we tried extending the idea into retail. Shopping is often visual. People want to see the shirt, shoe, furniture or whatever else they’re considering buying, and moving the experience into a chat window doesn’t automatically improve it because an LLM is involved. WhatsApp can support commerce and there are useful experiences that can be built around it, but we were also building on top of an interface we didn’t control, which limited how far we could change the experience and meant that many of the things we could build on top of it could be reproduced fairly quickly by somebody else. We had started with the technical question of whether a workflow could become conversational when the more important question was what problem the conversation was solving. AI being capable of turning a workflow into a conversation doesn’t necessarily mean conversation is the right interface for that workflow.
Our move into financial services forced us to think about this differently. The sales cycles became considerably harder. For roughly the last six months we’ve been selling into financial institutions, working through introductions, security questions, integrations, pilots and the other things that come with enterprise deployment. But the problems themselves are different because the problem has an owner. If a financial institution has a churn problem, there is somebody responsible for it, a team looking at the numbers, historical data showing which customers are leaving and often an existing budget or process for doing something about it. The same applies to delinquency, dormant customers, collections and customer service. These aren’t problems created because AI exists. They are existing operational problems that organisations already spend money trying to solve.
Traditional software has already solved some of the easy parts. If a bank wants to re-engage a customer, it can send another email, SMS, push notification or in-app message. At some point you’re simply adding another automated message to the collection of automated messages the customer has already ignored. A person can do something those systems historically couldn’t do very well: have a conversation. If somebody is behind on a loan, a human can listen to the explanation, respond to what the person actually said and determine what should happen next. If a customer is leaving, a human can ask why and change direction as the conversation develops. The limitation has always been scale because you can’t economically put enough people on the phone to have meaningful conversations with millions of customers whenever you need to. Conversational AI changes that constraint, which is why our use cases have increasingly concentrated around re-engaging customers, following up on delinquency and resolving first-line service issues. We aren’t taking a visual workflow and forcing it into a conversation. We’re entering workflows where organisations already use humans because conversation itself is useful.
The difference in data has also been enormous. One financial-services pilot gave us more data to work with than all the transactions and orders we processed through our products in the previous year. Production data changes how quickly you learn because customers don’t behave like the examples you create while designing a product, and larger enterprise workflows expose the system to a much wider range of behaviour. I don’t know yet whether financial services will prove to be the final direction for us, but it has given us a much clearer picture of the kind of problem we want to solve: one that already matters to an organisation, already has an owner and becomes meaningfully easier to address when conversation can operate at software scale.
Founder-led sales taught us what we were actually selling
Finding a more useful problem didn’t make selling it easy. Our earliest founder-led sales involved a lot of cold LinkedIn outreach, and while some of it worked, the conversion was somewhere around 2% by our estimate. We eventually found direct introductions considerably more useful, particularly when they could get us closer to people capable of making an actual decision. Increasingly, what I wanted was a go or no go, yes or no, because a no from the right person is useful information. You know where the opportunity stands and can decide whether there is anything worth revisiting, while a long chain of conversations with people who aren’t able to say yes or no can consume much more time while creating the appearance of progress.
Founder-led sales also meant that we were learning while selling. When someone rejected the proposition, we could understand why and change how we explained it. When a customer cared about something we hadn’t expected, that information went directly back into the product. When one use case consistently created interest and another didn’t, we could change what we led with in the next conversation. The early sales process therefore wasn’t only producing customers. It was producing knowledge about the market: who owned the problem, what language they used to describe it, what they were already doing about it, what objections appeared repeatedly and what had to be true before someone would agree to a pilot. That knowledge eventually became important when we started working seriously with channel partners.
Channel partnerships are attractive to startups for obvious reasons. An infrastructure company may already have relationships with hundreds of enterprises that would take us years to develop independently. A telephony provider already sells into organisations that need communications infrastructure, while a cloud company already serves enterprises running workloads on its infrastructure. On paper, adding your product to that distribution network seems like an obvious way to accelerate sales. What we learned was that access to customers and knowing how to sell something to those customers are different things. Some of our early partners were genuinely interested in what we were building and took it into their accounts, but if a partner approaches five customers and all five say they already have something similar or don’t see the need, there is very little reason for that partner to keep pushing. They have other products to sell and other priorities competing for the same customer relationships.
We started seeing a different response once we had our own momentum. There were cases where a partner had approached an organisation without getting anywhere, and we subsequently got into the same organisation ourselves and moved towards a POC or pilot. That changed the conversation because the customer clearly wasn’t inherently uninterested in the product. The questions from the partner became more specific: who did you speak to, what problem did you lead with, what use case did they care about, and how did you get them interested? We could compare what they had tried with what we had learned through founder-led sales and start improving the motion together. Without the momentum, there would have been little reason for them to return to the table and learn how to sell the product differently.
That experience changed how I think about channel sales. A partner cannot find your market for you, particularly when the product itself is still being figured out. The partner’s distribution couldn’t replace the learning we needed to do ourselves because they didn’t have the same incentive to endure rejection while trying to discover which problem, buyer and language would make the product work. Founder-led sales gave us enough knowledge and evidence to make the channel useful. In that sense, it wasn’t simply the sales motion before the scalable sales motion. It was producing some of the knowledge required for somebody else to eventually sell the product.
Giving partners a reason to sell
The other part we’ve been experimenting with is the economics of the partnership itself. Our voice stack contains several components: telephony, speech-to-text and text-to-speech, the reasoning layer, orchestration, integrations and the data modelling required before enterprise data enters the harness. We build and control important parts of that system, but being full-stack doesn’t mean we have to manufacture every component ourselves. Some of the companies supplying the infrastructure we use already have enterprise relationships of their own, which creates the possibility of a different kind of channel relationship from a conventional referral agreement.
A telephony provider, for example, can supply the infrastructure required for calls while also introducing us into organisations that already buy communications services from them. A cloud partner can provide some of the infrastructure our system runs on while also having enterprise customers that may need the application we’re building. When one of those partners helps us win a deployment, the deployment itself can increase consumption of the infrastructure they already sell. The customer pays for the full product, we pay the infrastructure provider for the component it supplies, and the partner can also participate in whatever commercial arrangement we’ve agreed around the account. We have deliberately designed some of our partnerships around this because it gives the partner an economic reason to care about what happens after the introduction.
The relationship becomes more interesting as the product gains momentum. We’ve seen partners become much more collaborative once they can see deployments happening, including wanting to participate more deeply and discussing white-labelling earlier than we would have expected. We don’t automatically agree to those arrangements because we also want to see that a partner can create meaningful momentum before making the relationship deeper, but the behaviour itself is useful. The partner is no longer being asked to sell an unfamiliar startup product purely in exchange for a percentage of a contract. Our growth can increase consumption of something they already sell, while their distribution can increase our access to the enterprise customers that need the application layer we’re building. The incentives start to reinforce each other.
There is a wider reason I think this matters for AI companies. A lot of AI products depend on infrastructure supplied by other companies, whether that is cloud compute, models, telephony, payments, databases or other services. Those relationships are normally discussed as the cost side of the business: this is the provider we pay to make our product work. But some of those providers also have distribution, enterprise relationships and an incentive to increase consumption of their own infrastructure. If the economics can be aligned properly, an infrastructure supplier can also become part of the route to market. That doesn’t remove the need to build your own distribution, and our experience so far suggests the opposite. You need enough direct momentum to show the partner what works before their distribution becomes particularly useful.
What are we actually selling?
I find this question harder to answer than I probably should. A year ago I might have said we were selling AI software, and at various points I could have described what we were building as conversational commerce, chatbots, AI agents or voice AI. All of those descriptions are technically defensible, but none really explains what the customer is buying. The financial institution trying to reactivate customers doesn’t want tokens. The collections team doesn’t particularly care which LLM sits underneath the agent. The customer-service team isn’t waking up in the morning hoping to purchase more inference. They have a problem with an owner, a number attached to it and an existing way of trying to solve it, and increasingly we are trying to work backwards from that problem rather than forwards from what the technology can do.
This is also why I think the economics of selling AI like SaaS become difficult. SaaS gave the industry the seat as a convenient commercial unit, while AI companies inherit variable costs underneath their products and are increasingly using software to perform work that previously required people. A voice agent might have five employees supervising it while having conversations with 100,000 customers. Charging for five seats makes little sense, but exposing the customer directly to every token, model call, minute and infrastructure cost doesn’t tell them much about the value they’re receiving either. Depending on the workflow, the sensible unit might eventually be usage, a conversation, a completed action, an outcome or some combination of them. We are still experimenting with that ourselves because the economics underneath the product don’t disappear simply because the customer would rather buy an outcome.
There is a significant tailwind helping AI companies right now. CEOs want to know what their AI strategy is, CIOs are being asked what they’re doing with AI, and boards want to understand what the technology means for their companies. That creates attention, but attention isn’t distribution and it certainly isn’t product-market fit. For us, founder-led sales has been the mechanism for turning some of that attention into knowledge about which problems have owners, which use cases survive contact with a real enterprise, what people might pay for and what the economics look like once the product is running at scale. Channel partnerships have become more useful as we’ve accumulated that knowledge because we now have something more useful to give the people selling alongside us than a product deck.
I don’t know whether this is the GTM model we’ll still be using a few years from now, and I don’t know whether we’ve completely answered what the natural commercial unit of AI should be. What I understand much better than I did a year ago is that distribution can’t rescue a product whose problem you haven’t found yet. Our partners became more useful after we learned enough to show them not simply what we had built, but where it worked, who cared about it and why. Selling it ourselves first was how we learned that.