Beyond the Demo: The Enterprise AI GTM Playbook

A note from the Arkam Rooftop Meetup Series: Enterprise AI GTM Edition

Siddharth of Ringg.AI spent nearly a year doing a job that did not fit neatly into product, sales, engineering, or customer success.

He visited customer offices, sat with operations teams to understand why calls were failing, built agents to run against human teams, and reported the results directly to senior leadership. When something broke, the customer could call him.

The company is now Ringg.AI’s largest customer.

Vrushank, who was part of Portkey’s journey from its early days to more than 100 enterprise customers and its acquisition by Palo Alto Networks, described the same reality more directly: enterprise go-to-market happens deal by deal. Product and distribution may get a company into the room. What follows is still a series of things that do not scale.

We hosted the Enterprise AI GTM Playbook edition of the Arkam Rooftop Meetup Series to understand what selling enterprise AI actually requires. Moderated by Bala Srinivas of Arkam Ventures, the discussion brought together two companies at different layers of the AI stack. Ringg.AI builds voice agents for enterprise workflows. Portkey built infrastructure for teams taking AI applications into production.

The enterprise is not buying AI because it sounds intelligent. It is buying an outcome and the confidence that it will hold when the product moves from a controlled pilot into a live environment.

The outcome is the product

AI demos have become easier to build and harder to differentiate.

A voice agent can sound human. A developer tool can connect to multiple models. An application can produce a convincing result during a managed demonstration. None of this tells the enterprise whether the product will create value after deployment.

Ringg.AI currently handles roughly 3 to 3.2 million conversational minutes a month, translating into approximately five million connected conversations across its customers. At that scale, the difference between an impressive demo and a dependable product becomes visible quickly.

For Siddharth, an enterprise buying a voice agent is usually trying to achieve one of two things. It either wants more output from the same team or fewer people producing the current output.

That makes voice AI an outcome sale rather than a tool sale.

If the agent sounds natural but cannot improve conversions, strengthen customer service, reduce operating costs, or remain dependable as volumes grow, the novelty disappears and the economics remain.

A workflow that is merely useful can be tested through an internal build, a foundation model, or one of several inexpensive tools. A mission-critical workflow is different. An inbound support agent has to remain available. An agent helping a patient book a doctor cannot invent appointment slots. A tool call cannot work 95 per cent of the time when the remaining 5 per cent affects a live customer.

The more consequential the workflow, the less the conversation is about the model. It becomes a conversation about reliability, integration, cost, and measurable performance.

The ICP is not always the use case

Ringg.AI works across collections, support, lead qualification, scheduling, delivery confirmation, hiring, and other workflows. At first glance, this can look like several different ideal customer profiles.

Large operations teams, however, are rarely organised around one permanent activity. A contact-centre team handling support today may be moved to sales, cross-sell, onboarding, KYC assistance, or retention tomorrow. The same functional leader often owns the people, budget, and outcomes across these workflows.

The ICP may therefore be the operations leader responsible for deploying hundreds of people across the customer lifecycle, rather than a single use case.

Once Ringg.AI enters an account, it can carry context across different touchpoints. At Practo, the platform supports bookings, pre-consultation calls, post-consultation follow-ups, and test-related workflows. At Policybazaar, it works across lead qualification, KYC support, cross-sell, and inbound assistance.

Portkey arrived at its ICP from the infrastructure side.

Vrushank described himself as a platform engineer building for and selling to platform engineers. Portkey’s user could sit inside an early-stage startup or a large enterprise, in India or the United States, and across almost any industry. The organisation changed. The underlying problems remained consistent.

At certain layers of the AI stack, the ICP can be scale-agnostic, geography-agnostic, and domain-agnostic. The harder task is understanding where the product creates durable value and becoming fluent enough in the customer’s world to recognise the problem before the customer has fully articulated it.

That fluency also separates a real buyer from an enthusiastic user.

Many enterprise teams want to experiment with AI. A department head may want to demonstrate momentum. An innovation team may want a pilot. A user may like the product without owning the budget or the business outcome.

Ringg.AI now qualifies this early by asking three questions: What is the customer’s hair-on-fire problem? What does it cost to address today? If the product delivers the same or better outcome at a lower total cost, does the unit price still matter?

A buyer who cannot define the cost, expected outcome, or economic value may not be ready to buy. Ringg.AI consequently disqualifies a meaningful share of inbound leads during the first conversation and commits technical resources only when the problem and its economics are clear.

In enterprise AI, selling can begin by helping the customer understand its own problem.

Product-led entry, sales-led conversion

Portkey was built with a strong product-led motion. Developers could discover the product, try it, and begin using it without waiting for a sales conversation. Yet the company repeatedly found itself moving into a conventional enterprise sales process.

The reason was not that product-led growth had failed. It was that the product had become critical infrastructure.

Once an enterprise considered placing Portkey inside its AI platform, security, deployment, procurement, architecture, and organisational risk entered the discussion. A bottom-up developer user could create the initial pull, but a meaningful enterprise contract still required a sales-led process that could take months.

The lesson is not to choose between PLG and SLG as though they are mutually exclusive.

For developer and infrastructure products, Vrushank argued that product-led access should be the default. Developers should be able to experience the product, understand the value, and create internal demand without first booking a demo.

Ringg.AI followed a similar path despite being an enterprise application company. Customers such as Policybazaar and Practo arrived inbound after experimenting with the product themselves.

The self-serve product created conviction. The enterprise process converted that conviction into a deployment.

Portkey’s inbound engine combined open-source software, product-led access, technical content, partnerships, and integrations. Early design partners mattered too. A recognisable company such as Postman gave Portkey a relevant enterprise logo and reduced uncertainty for the customers that followed.

PLG can open the door. It does not remove the need to navigate everything that waits behind it.

Your competitor is also the internal team

Enterprise AI companies do not compete only with similar startups.

They compete with foundation-model providers, open-source tools, cloud platforms, consulting firms, large software companies, and the customer’s own engineers. The enterprise can often assemble something that works well enough for a pilot. The question is why it should trust an external company with the production version.

For Ringg.AI, the answer is to invite a direct comparison.

The company can ask a customer to allocate a small portion of live volume to Ringg.AI while keeping the majority with the internal system or existing provider. Both are measured against the same business outcome and cost base. The customer can then decide using evidence rather than a feature comparison.

The strongest version of this strategy is to choose the problem the internal team has found hardest to solve. Commodity use cases create commodity comparisons. Mission-critical workflows reveal whether the vendor has built the reliability, orchestration, integrations, and operational layer required to outperform a stitched-together system.

Portkey faced a different version of the same objection. Engineers often believed they could build an AI gateway themselves because the basic product appeared to be a proxy. The company had to move the conversation from the simplicity of the component to the complexity of owning it in production.

That distinction shaped Portkey’s strategy: do not merely help teams develop AI applications. Help them take those applications into production.

Enterprises may build another internal tool. They are less eager to own another critical infrastructure layer that must remain secure, reliable, observable, and current while the AI ecosystem changes around it.

The FDE as the new enterprise operator

The forward deployment engineer has become one of the defining roles in enterprise AI.

Many customers are not buying a finished tool. They are beginning an AI transformation. They need someone who can understand the workflow, define the first phase, integrate the product with existing systems, and create a path to scale.

This requires technical ability, customer fluency, and the judgement to operate somewhere between an engineer, consultant, product manager, and account lead.

Ringg.AI calls these team members TPMs, or TPM-plus. Its conventional platform and sales teams remain relatively small, while the customer-facing technical function is growing. These people work inside the deployment and help turn the product into an operating outcome.

For Portkey, the FDE model had a different emphasis. An FDE was not placed inside a customer merely to create a customised implementation or increase services revenue. The objective was to learn from the deployment and bring those insights back into the core product.

Even after more than 100 enterprise deployments, Portkey maintained a single release channel rather than creating separate versions for individual customers.

That distinction matters. FDEs can strengthen a product company or quietly turn it into a collection of projects. The learning has to return to the core product.

There may also be an opportunity for Indian AI companies here. The next offshore model may include technically strong FDE teams working closely with global enterprises. Global capability centres in India can become another bridge, allowing startups to build trust and deliver locally while solving for workflows used across markets.

The advantage will not come from labour cost alone. These roles require engineers who can speak to customers, understand organisational context, and operate as trusted extensions of the internal team.

Product gets you into the room. Trust wins the account

One of the clearest lessons from the evening had little to do with AI.

People still buy from people.

The larger and more consequential the contract, the more the customer wants to know who is behind the product. It wants to meet the team, know who will answer when something fails, and believe that the vendor will remain present through a difficult deployment.

Ringg.AI once lost an insurance opportunity partly because the company did not meet the customer’s minimum team-size requirement. The enterprise was evaluating not only the technology but also whether the organisation looked capable of supporting the contract.

Vrushank described Portkey customers who had his phone number and could contact him directly. Some relationships were built over Zoom. Others were strengthened over meals and difficult negotiations.

This is why founder-led sales remains important for longer than many startups expect.

Bala’s view was that founders should remain directly involved until the company reaches roughly $2 million to $5 million in revenue. Before that point, the sales motion is still being discovered. An external sales leader cannot inherit a playbook that does not exist.

The founder is not only closing contracts. The founder is discovering what the company sells, who values it, why deals are won, and what the repeatable motion may eventually become.

Price against value, but understand the customer’s P&L

Outcome-based pricing sounds natural for AI because the technology is expected to perform work rather than simply provide access to software. In practice, both the outcome and the cost of delivering it are still changing.

AI does not yet have the marginal economics of traditional software. Serving one more customer continues to require tokens, models, infrastructure, and operational support. As usage grows, the vendor’s costs grow with it. The customer then returns to renegotiate because a small consumption bill has become material.

Siddharth’s practical advice was to preserve enough margin in the first contract to survive these later negotiations. A company that prices too close to its operating cost may discover that its most successful deployments become its least sustainable accounts.

The customer’s business model matters just as much.

Ringg.AI once lost a sizeable logistics deployment after resisting a price revision. The deeper lesson was not simply about negotiation. Logistics companies operate on thin margins. Even when the product creates value, the customer may remain under constant pressure to reduce vendor costs.

Studying the customer’s P&L can therefore be as important as understanding its workflow. A company operating at a 3 per cent EBITDA margin will behave differently from one operating at 20 per cent. The same outcome may support very different pricing.

Vrushank described a complementary approach from the infrastructure and security side. Rather than beginning with the product price, begin with the customer’s overall AI budget, the share allocated to infrastructure or security, and the portion of that value the product protects or enables.

The aim is to shift the conversation from the cost of the tool to its place inside the customer’s economics.

The playbook is still being written

Enterprise AI is changing quickly, but its go-to-market motion is not being rebuilt from zero.

The familiar requirements remain: identify the real buyer, understand the budget, solve a painful problem, demonstrate economic value, navigate procurement, build trust, price sustainably, and remain present after the contract is signed.

What AI changes is the intensity of each requirement.

The product has to keep working while models, costs, and expectations change. The sales process has to educate buyers who may not yet understand their AI economics. The deployment team has to combine engineering and consulting. The founder has to compete against startups, internal builds, open-source software, cloud platforms, and the next foundation-model release.

There is no clean separation between product and go-to-market in this environment. The enterprise conversation shapes the product. The deployment reveals what should be standardised. The FDE carries learning back into engineering. The pilot establishes the outcome used to justify the contract. Trust determines whether the company is allowed to attempt any of it at meaningful scale.

The strongest enterprise AI companies will not be the ones with the most impressive demos.

They will be the ones that can turn a changing technical capability into a dependable institutional outcome, then repeat that process without losing the product along the way.

This conversation was part of the Enterprise AI GTM Playbook edition of the Arkam Rooftop Meetup Series. Thank you to Siddharth of Ringg.AI and Vrushank of Portkey for sharing the lessons behind the wins, lost deals, difficult deployments, and go-to-market decisions, and to everyone who joined us and continued the conversation afterwards.