Revenue leaks nobody sees
Greg Howard: One single catastrophic failure usually isn't the problem in revenue operations. Rather, it's the multiple unseen, unsung revenue leaks that spring up when no one pays attention. Somebody eventually sounds the alarm, but by that time, the damage has been done.
Nor is revenue lost in only the obvious places like outages or broken shopping carts. It evaporates inside slow-loading product pages, inventory mismatches, payment failures, hidden inside aggregate metrics, promotions that do not fire correctly, and partner systems that degrade without setting off the right alarms.
Teams have no shortage of dashboards, alerts or analytics. But what they lack is a fast, reliable way to connect business impact to operational cause and take action while the problem is still forming. Thanks to their dashboards, they know something's wrong. They just can't get to the why fast enough.
This is a conversation where we tell some stories about real companies and real firefights, and we try to understand just what happened and how it can be both better and different.
Before we get into the stories, quick context on the two of us. Bhaskar is the CEO of Bicycle AI. He spent a lot of his career building systems for high-transaction environments. Places where a small issue at enough scale becomes a real business problem very quickly. Hi, Bhaskar.
Bhaskar Sunkara: Hey, Greg.
Greg Howard: And I worked with Bhaskar back in AppDynamics. I joined early, employee number 13, and saw a lot of this from the inside. The firefights, the customer escalations, the postmortems, the moments when the dashboard was technically right, but the team still didn't know what to do.
Why now was the right time to build Bicycle
Greg Howard: So, Bhaskar, before we get into the e-commerce stories, let me start there. Why was now the right time to build Bicycle?
Bhaskar Sunkara: Yeah, thanks, Greg, and it's great to work with you again. The simple answer is that the problem has changed, right?
So, when we were in the AppDynamics world, the core question was really, is the application working? First of all, is it available? Is it up? Is it fast enough in terms of response times, in terms of the user experience, what the user feels, load times, et cetera? Are there errors? Can I serve the application without issues? Are there any bottlenecks? Where is the bottleneck? That was a huge problem, and obviously it still matters, right?
But in e-commerce, the question has become more complicated. It's just way more nuanced than that. The site can be up. The revenue can still be leaking, right? The checkout page can load, but one device path can fail. Inventory can show as available, but the customer still can't get the product, right? Because something else is off. The dashboard can be green, but a paid campaign can be pushing traffic into a broken slice of the funnel.
So the question "is the system healthy" just doesn't get it done anymore. So, what is the question instead, right? What has changed? Who is affected? Why is it happening? What should we do before the customer notices? And really, that's the gap that we built Bicycle for.
Greg Howard: Yeah, I think I'm following your narrative, Bhaskar. You're saying that the old world was, hey, tell me something's broken, but in the new world, it's tell me where revenue is leaking, and what should I be doing next?
Bhaskar Sunkara: Yeah, exactly. And most teams have the pieces of the answer, right? They do have some pieces of it. They have the dashboards. They have data sitting in the warehouse that represents all of the transactions, all of the checkouts, all of the searches, et cetera, et cetera. They have observability tools that tell you application availability, response times and all that type of stuff. They have log tools. They have Slack threads. Everybody communicates, understands what's really happening. And they have people who really understand the business, right?
But in the moment, and I think this is the most important point, in the moment, those pieces aren't connected fast enough. And that's what really creates war rooms and all of that type of stuff.
Fragmented evidence and the war room
Greg Howard: All right, that's a great setup. So let's really talk about what you've actually seen. So this slide, this is the reason, this is why we wanted to do the webinar. Bicycle's been around for a couple of years. It's been around long enough now to really understand the customer segments that you serve, [figure removed] proof-of-concept deployments, and [figure removed] war room postmortems. And that's a lot of live environments for revenue engines under pressure. So, Bhaskar, when you look across those kinds of conversations, what pattern keeps showing up?
Bhaskar Sunkara: Yeah, the pattern is that teams are working really hard, but the system around them is very fragmented, right? And fragmentation happens in many different scenarios, but in this one, that's really what comes to the fore, where they're working very hard, but they're fighting against the fragmentation.
Because when you look at a revenue issue, it comes in just as one sentence, right? I'll give you some examples. Conversion is down, or orders are soft, or paid traffic isn't converting, checkout's weird, customers are complaining, inventory looks wrong. That sounds like one problem, but if you look at where that answer might live, it might be across 10 places.
It might be in the warehouse, and that's a simple enough thing to catch. It might be in a release note because something changed, particular to some particular device, some particular version. It might be in a catalog feed. It might be in a campaign change. It might be lying in the session data. It might be in a third-party system. It might be in someone's memory from the last incident, which is really hard to catch. So what the real work here becomes is, how do you stitch the story together, right?
Greg Howard: Oh, that's happening in the war room.
Bhaskar Sunkara: Yeah, absolutely. That is really happening in the war room. The war room is not usually a sign that the team doesn't care, or the people are lazy, or whatever. It's exactly the opposite. It's a sign that these smart people are trying to connect disconnected evidence under time pressure, and that's really hard. And that is the expensive part.
The revenue leak is expensive, and also when you do the investigation on it, it is expensive, because look at the number of teams you're pulling in, right? You're pulling in data, you're pulling in engineering. Data owns the warehouse, engineering owns the observability systems, the session recording systems, and all of that. Marketing owns the spend, like what kind of spend am I pushing to whatever traffic, whatever area. You pull in operations, you pull in support: are customers complaining? So all of these are various factors.
And if you tie it back to what I said earlier on, it sounds like one problem, orders are soft, but then the answer can live in 10 places, which is why you're bringing in all of these people. Everybody brings their own chart, everybody has a theory, and the clock is basically running.
Greg Howard: So it's 2026. Has anything changed much since your time doing this in AppDynamics?
Bhaskar Sunkara: That's a great question. And the answer is yes and no. The shape is familiar, right? Like, high-volume systems still fail in complicated ways. But e-commerce adds a business layer that the traditional system tools don't fully handle, right?
Because when you're just looking at observability, you might really ask, which service is slow? But in e-commerce, the real question is, did that slowness matter to revenue? It's always a correlation back to the revenue, checkouts, et cetera. Which shoppers were affected? Which channel drove them there? Which products were involved? Was there a campaign running? Could inventory fulfill the demand? What action would protect the revenue right now? That is the broader operating question that matters.
Dashboard theater and the hidden segment
Greg Howard: Well, that's another great segue. So that brings us to the old way that teams are typically handling this. So this slide is called dashboard theater. And to be super clear, we're not saying that dashboards are bad. Dashboards are useful, every team needs them. The problem is when the dashboard becomes the place that the conversation stops. So Bhaskar, maybe you can expand on that a little more and tell me what's happening here.
Bhaskar Sunkara: Yeah, absolutely. So the issue here is that each team usually sees its own slice, right? So again, let's bring in some of the teams that we talked about earlier. Marketing sees the campaign spend, click-through, return on ad spend, maybe top-line conversion. Data sees warehouse queries, attribution models, cohorts, definitions, et cetera. Engineering is looking at their tools, looking at errors, latency, deploys, logs, feature flags, et cetera. Ops sees inventory feeds, fulfillment exceptions, things like that.
All of that is useful, right? But again, it goes back to, how do you connect them together? When time is short, when revenue is leaking, the business doesn't need four disconnected views. It needs one connected explanation.
Greg Howard: Right, because the customer doesn't care whether the issue comes from marketing, engineering, inventory or checkout. They just have a bad experience.
Bhaskar Sunkara: Yeah, absolutely. And the company still owns the outcome, right? Let's say conversion slips. Marketing might say traffic quality is looking okay, right? Engineering might say the site is up. Data might say the metric is real, and operations might say the inventory feed looks normal. But the customers, they're still dropping, and you're losing money.
And the problem is not that no one has data. There's enough of it and it's in many forms, right? The problem is that the data doesn't form a decision quickly enough. And it's not enough to just look at a dashboard or look at a signal saying, hey, customers are dropping, because everybody knows that. How do you go from that signal to forming a decision quickly enough?
A dashboard tells you what someone thought was worth measuring in advance, right? So that's why it's on a dashboard. But revenue leaks often happen in the slice no one prebuilt the chart for. It's deep down.
Greg Howard: Yeah, and that line is important, because that's where no one built the chart.
Bhaskar Sunkara: Yeah, absolutely. And that's why dashboards create false comfort, right? People look at the top-line view, it looks okay. The team moves on, but the broken slice keeps leaking.
Greg Howard: So maybe that would have been a better title for the slide. Not dashboard theater, dashboard comfort. It's the comfort that creates the trap that really underscores the stories we're going to talk about in this presentation.
So let's move on here. This is a simple version of the problem, but what you're talking about is the aggregate conversion looks fine. On the dashboard, the top-line number is green, revenue's on plan, nothing looks urgent. But underneath, there's one segment, one slice, and it's cratering. It could be mobile on iOS, or one region, one campaign cohort, one product family, one checkout path. It's just one thing. So Bhaskar, why is that so dangerous?
Bhaskar Sunkara: Because the average hides urgency. At high volume, you can have a serious problem in one slice and still have the aggregate look okay for a while. So we actually had something related in AppDynamics also: when you look at all the traffic, aggregates can hide what's really happening. But when you apply a business lens, which is what we're doing in Bicycle, it gives you a completely different perspective, especially in e-commerce, right?
If desktop is fine, mobile can be broken. If one region is fine, things in San Francisco can be fine, LA can be failing. If top sellers are fine, one product family can be leaking. If checkout's mostly fine, one browser or payment method can be broken. The dashboard says we're okay, but the slice says we're losing money right now.
Greg Howard: And by the time that slice is big enough to move the top-line number, the damage has already happened.
Bhaskar Sunkara: Exactly. And there's another piece, right? The revenue loss is not just the abandoned cart, right? You've wasted paid media dollars that drove someone into the broken path. So you've got to account for that. It's the trust of the customer. You don't know if that's a frequent customer, you don't know if it's one of your most loyal customers. It's the load on support, because someone's reported a problem or you noticed a problem. It's the analyst time spent finding the issue. It's the operational scramble afterwards. So the leak is bigger than the metric.
Greg Howard: It's a good line. The leak is bigger than the metric.
What agentic analytics does differently
Greg Howard: So if the dashboards show the number but don't connect the story, what's the new model? And so if you look at this slide, it says agents close the loop. And I want to slow down here, because "agent" can become a vague word very quickly. It's used a lot. Bhaskar, when Bicycle talks about agentic analytics, what is actually different from a dashboard?
Bhaskar Sunkara: Yeah, absolutely. So let's break it down in terms of comparison, right? So a dashboard shows a metric and it's waiting for you to read it, right? An agent basically works a loop where, apart from reading that metric itself, it's doing a bunch of other work.
And what is that bunch of other work? Number one, detect what changed, right? Number two, focus on the slice that really matters. So let's say only something in San Francisco, only something on iOS or something like that, right? Focus on the slice that really matters. Explain the likely cause, right? Why is that really happening? And we already talked about a bunch of issues that could be happening because of it, right? So that's explaining the real likely cause. Recommend the next action, and then keep learning from what happened.
If you want to shorten it, sometimes we shorten this as detect, explain, act and learn. And so the short acronym is DEAL, right? So DEAL is the loop that the agent is basically working, and it's working on a KPI, and it's really doing all of these things. And the important part is that the agent is not sitting there waiting for someone to ask a question. It has a job, and that is really what is special about what it does.
So let's just take a concrete example. Let's say a conversion leakage agent. That's the use case that it's performing. It's an agent for analytics, and that's the whole definition of agentic analytics. And you've created a conversion leakage agent. Let's say that it's watching funnel health, right? It knows which KPIs matter. So it's going to watch the right KPIs. It knows the relevant dimensions: device, region, channel, product family, campaign, cohort, et cetera. It looks for meaningful changes. It connects those changes to possible causes, and it tells the team what is worth the attention.
Greg Howard: So it feels like you're saying that agentic analytics, in the Bicycle view, is not just a nicer dashboard with chat.
Bhaskar Sunkara: Sometimes it's just taken that way, where it's like, hey, you're talking to your data, but that's just not good enough, right? A chat box over a dashboard still leaves the human doing most of the work. If you're not asking the right question, if you're not looking at it at the right time, the business is still hurting.
The agentic model is different. The system is continuously doing the first pass of the investigation. It looks across the slices. It checks related signals. It narrows the issue. It brings all the evidence together, irrespective of whether that's coming from the engineering tooling, the marketing tooling or wherever that is from. It proposes what to do next. The human still stays in control, but the detective work becomes much faster and more repeatable.
Greg Howard: It sounds like a lot of work is being done by the agent. So in that model, what's the team doing?
Bhaskar Sunkara: Yeah, great question, right? So the team is making decisions, right? What the team is not doing is running 100 queries, Slacking across multiple channels to figure out how to stitch things together. Instead, it's connecting the dots and it's making decisions, and that's the key.
The team is not spending hours asking, where is this happening? Is the data right? Which dashboard should I check? Who has the other half of the story? Instead, the system says, here's the slice, here's the likely cause, here's the business impact, here are the recommended next steps. Here's who should own it, here's what we've seen before. And over time, it keeps learning and keeps doing better. Now the team can use judgment.
Greg Howard: Do teams feel safe doing it that way?
Bhaskar Sunkara: Yeah, that's probably the most important thing, and that's the gap between anything that's agentic and how you make it real world. How do you get it to the point where it is in production? And it is hard, right?
And so in this case, you make the system governed from the start, right? Agents should not be just doing random automation. They need very clear jobs. They need approved data sources. They need approved metrics, known metrics. They need evidence that's explainable. They need guardrails on actions. They need approvals where needed, and then audit history, right?
So in many cases, the first action is, hey, let's just change the system to completely redo it or rewrite it, right? It's alert the right team, or open a ticket, recommend a rollback, suggest suppressing a SKU, show the evidence before anyone acts. So that's how you get speed without losing control.
So you've got to make it basically governed from the start and then build that system, which is why this is not some overnight or weekend project where you're like, oh, I'm just going to run a couple of LLM things on top of it. You have to be able to build that system, and that's how you get speed without losing control.
The release that broke checkout
Greg Howard: Yeah, Bhaskar, the way you explain it is very clear. So let's try to make this even more concrete by looking at three specific stories here. So the first story we're going to talk about is the release that broke checkout, and the line underneath is the painful part: customers found it before the team did. Bhaskar, maybe you can walk us through this pattern.
Bhaskar Sunkara: Yeah, this happens a lot, Greg. The team pushes a site release, and overall the release looks fine. The product pages are loading, add to cart looks normal. The overall traffic is pretty stable. The site is technically up, but one checkout path is broken, right?
Maybe it's iOS Safari. Maybe it's one particular browser version on a regular sort of browser, not mobile. Maybe it's one payment step. Maybe it's a specific shipping option. Maybe it's a new checkout component, right?
The top-line dashboard doesn't scream about it and it's not bringing that to attention, but customers are starting to feel it, right? And the first thing that happens would be a support ticket, right? Then it's a social post, then customer care drops a Slack message: are we seeing checkout issues? Because that's really the bad moment, right? Because now the customer is basically doing QA in production.
Greg Howard: So in the old model, how did the team respond?
Bhaskar Sunkara: Yeah, usually they try to hunt it down, right? Because you don't really know; the work hasn't been done in figuring out where that's coming from. So someone's on conversion, someone's looking at deploys, someone's looking at other logs, someone's looking at support tickets, someone's looking at session recordings, anything obvious that they can find, and people clicking around. Someone asks if marketing changed anything, someone asks if payments changed anything. Eventually the team may find it, but the path is too slow and, worse, everyone is working from a different starting point.
Greg Howard: Okay, so that's the old world. How would an agent handle all this differently?
Bhaskar Sunkara: Yeah, absolutely. That's the right contrast, and that's what's going to bring the point home, right? The agent is already watching checkout completion slice by slice. So let's just say you have five different browser versions, and the agent would be watching each one of those, different regions, different cities. The agent's going to watch each one of those slices, not just overall checkout completion. And the types of slices: by device, by browser, by app or web version, by region, by channel, by steps of the checkout, by release version.
So when checkout completion drops only for iOS Safari after a release, the agent can detect that narrow change, right? Then it connects timing. The dip starts after release 4.18, something like that. It's isolated to iOS Safari. Product page and add to cart are normal. Checkout start is okay. Completion drops at the final step. There's an error spike in the payment or confirmation step.
Now the team doesn't start with "something's weird." They have this brief, right? Checkout completion is down for iOS Safari after 4.18. It's most likely tied to the checkout step regression. Here's the affected segment. Here's the impact. Here's what to check, or roll back. And so that just gives you a completely different starting point.
Greg Howard: So the agent's not just detecting the dip. It's narrowing down the problem for the team.
Bhaskar Sunkara: Yeah, exactly. Detection alone is not enough. If I tell you conversion is down, I've only created work for you. That's when it starts. If I tell you conversion is down for a specific segment after a specific release at a specific step, like in the last example, a regression in the checkout step, with evidence and with recommended next steps, I've shortened the path to recovery. And that is basically really the value.
Greg Howard: And there's a payments parallel here too, right?
Bhaskar Sunkara: Yeah, absolutely. The same pattern shows up in payments, right? Approvals dip for one issuer after a change, a wallet fails for one app version, 3DS breaks for one region. The payment method is technically available, but one path is failing. In e-commerce, it might look like a checkout issue. In payments, it might look like an approval issue. But the operating problem is the same: find the affected slice before customers find it for you.
Averaging away the problem
Greg Howard: Yeah, and that brings us to the second story, where the problem is not that the team sees a red flag, it's that the averages hide the red flag. So this one's called averaging away the problem. Nothing looks broken. You mentioned this before, Bhaskar, that the average is hiding it. Maybe you can unpack a little bit more about what's really happening here.
Bhaskar Sunkara: This is one of the most common e-commerce revenue leaks. The top-line metrics are healthy. Overall conversion, revenue, both are great, orders are not down, average order value looks normal. So the team moves on, right?
But underneath that, one segment is performing terribly. Maybe mobile in the West region is down. Maybe paid social traffic is converting at half its usual. Maybe new visitors on one campaign are dropping after the PDP. Maybe one product family has a layout issue. Maybe one cohort is seeing bad recommendations.
Greg Howard: This is where volume works against you.
Bhaskar Sunkara: Yeah, perfect, absolutely. High volume can make you feel safe, because the business is still generating transactions. The dashboard is still moving, there's still revenue. But that same volume means a narrow slice can be very expensive. And a small percentage of a big business is still a lot of money.
Greg Howard: What does the old workflow look like here?
Bhaskar Sunkara: Yeah, usually someone notices later. Maybe the weekly business review shows one channel underperforming. That's when it kind of comes up. Maybe marketing asks why spend was inefficient. Maybe merchandising sees a product family miss plan. Maybe the data team gets asked to explain last week.
Then the analysis begins, right? Like slice by device, by region, by channel, by cohort, by product family, by campaign. That's valuable work, but it's really too reactive. And by the time the team understands the broken slice, the spend already happened.
Greg Howard: Okay, so how does the agentic model change that?
Bhaskar Sunkara: Great, yeah. Somewhat linked to the last scenario, the agent doesn't just watch the top-line KPI. It watches the KPI across the dimensions that matter. So for conversion leakage, it's watching conversion rate, add to cart, checkout start, checkout completion, purchase rate, right? And it watches those by device, region, channel, campaign, SKU, product family, cohort.
Which basically means that the agent can say overall conversion is healthy, but this slice is driving the decline, right? So for example, mobile, West region, paid social, product family, new visitors. Like, literally, that is the slice, right? That's a segment where things are failing. That slice is down 38%. All other slices are flat or up. The drop starts after a PDP change. Add to cart is down in that slice. Session errors are higher. The estimated revenue at risk is this amount, right? And the recommended next step is roll back or feature-flag the PDP change for that slice and notify the growth team. That is basically the difference.
Greg Howard: So instead of staring at a healthy average, the team's getting to the broken slice.
Bhaskar Sunkara: Yeah, absolutely. And I'd put it this way: dashboards are usually designed around questions people already knew to ask, right? Just, like, preemptively. Agents are useful because they can look for the questions no one knew to ask yet, right?
And because anytime an agent is using reasoning, you're not giving it a workflow. It is asking questions no one knew to ask yet, and it's figuring out what the right question is based on what evidence it has, based on what data it has. No analyst would manually check every KPI across every dimension all day, right? It's just not a good use of human time. But that's exactly the kind of work an agent should be doing.
Greg Howard: Well, and once it finds a slice, it still has to connect it to the cause and then take action.
Bhaskar Sunkara: Yeah, absolutely. A broken slice is helpful, but it's not the finish line. The system has to connect what changed, where it changed, what else actually moved with it, what likely caused it, what the team can do next. That's how you can get from just doing analytics to recovery, getting the business back on track.
Phantom inventory
Greg Howard: Fantastic. Well, the third story takes us into inventory, where the system can say one thing while the customer experiences another. We call this phantom inventory. The inventory exists in the system, but not in reality. Orders get canceled, shelves are empty and the revenue slips away. Bhaskar, this one feels very retail specific, so it should appeal to the people watching this from the retail industry. What do you think is the pattern here?
Bhaskar Sunkara: Retail depends on a lot of systems that the storefront doesn't fully control, right? The storefront can just be search, add to cart, checkout. And so the systems that the storefront doesn't fully control, like inventory feeds, syncing of catalogs, supplier status, store availability, warehouse updates, search indexing, promotion logic. So a product can look available in one system but not actually be available to the customer.
And that creates really two bad versions of the problem. In one version, the site shows something is available, customers buy it, then the order gets canceled, right? In the other version, the product is actually available somewhere, but the site doesn't show it properly, so demand never converts. And both of these are basically revenue leaks.
Greg Howard: And all this is happening while the site may actually look fine?
Bhaskar Sunkara: Yeah, 100%. The storefront is up. The product page is basically loading. The search results show up. You're able to perform whatever search for whatever SKUs, whatever items you want to look for. And the SKU actually is in the catalog. The inventory feed may even show a number. But the customer experience is broken, because what's really happening is a size is missing in one region. Maybe the feed is stale. Maybe a top SKU keeps ranking, even though it can't ship. Maybe a supplier feed didn't refresh, right? Maybe a store pickup promise is wrong. Maybe a product is promoted but not fulfillable. The customer doesn't care which system was stale.
Greg Howard: And how does this show up internally?
Bhaskar Sunkara: It shows up indirectly a lot of times, right? Conversion drops in a product family, add to cart is weird, orders get canceled, support tickets rise, right? And that's the symptom that you're seeing. Search engagement looks fine, but purchase rate falls. The campaign drives traffic to a product that can't fulfill demand.
And the team has to really work backwards, right? Was it a demand issue? Was it pricing? Was it size availability? Was it search ranking? Was it just inventory in the warehouse, right? Was it a supplier feed? Was it a catalog mismatch? And really, you're putting together an investigation across all those questions.
Greg Howard: So how would an agent handle that?
Bhaskar Sunkara: Yeah, so this time let's look at an agent which is different from what we were looking at before, which was looking at KPIs, looking at dips, which were very fine-grained, and understanding why they were happening. So an inventory agent or an availability agent should connect the signals that normally are apart, right?
So they could be product demand, search ranking, PDP views, add to cart, inventory availability, region, size availability, color availability, warehouse or store availability, order cancellation, supplier feed freshness, right?
So that's when it can detect patterns like: this SKU is getting traffic but not converting. This size and color combination is unavailable in a high-demand region. This product is still promoted even though fulfillment is failing. This feed hasn't refreshed. This item is ranking in search but has no actual availability. This store says it can fulfill, but cancellations are rising, right?
And then it can recommend the next step: suppress the listing, refresh the feed, swap the promoted product, route fulfillment directly, notify merchandising, pause paid spend for that product, open a ticket with the feed. Those are the things it can basically recommend.
Greg Howard: Yeah, this is a key point, because the agent's not just telling you that inventory is wrong, it's connecting availability, demand and action.
Bhaskar Sunkara: Correct, yes. And that is why this is not just an inventory dashboard, right? The question is not only how many units are available. The question is, are we sending customers into a product experience we can actually fulfill? And that's the core question. That's the core revenue question.
One root cause and two wheels
Greg Howard: Yeah, so these stories are different, right? Checkout release, hidden average and phantom inventory, but they have the same root cause underneath. And this slide is really the heart of the webinar, because these stories share one root cause: disconnected systems, disconnected teams and disconnected decision loops. Bhaskar, maybe you can help break down the two sides we see here.
Bhaskar Sunkara: Yeah, absolutely. So on one side you have business performance, right? Average order value, all the standard ones: revenue, orders, look-to-book, paid spend efficiency, product performance, supplier health. So think about that as a steering wheel that tells the business where it's going.
On the other side, you have technical and operational performance. So latency, page speed, error rates, deploys, feature flags, health of a cache, picking orders, the catalogs, inventory feed freshness, the quality of the catalog, payment behavior, fulfillment status, et cetera. That's the machine that makes the business outcome possible.
The issue is that most teams don't connect these two sides quickly enough.
Greg Howard: As soon as a KPI moves, everyone goes into action. Data investigates, engineering checks logs, ops checks feeds, marketing checks campaigns.
Bhaskar Sunkara: No, exactly. And everyone's doing useful work, right? But the work is scattered. The business team is like, hey, there's a dip in conversion, but I can't tell if it's pricing, I can't tell if it's inventory, payments, checkout. The data team basically says, we're on a treasure hunt, right? The answer lives across the warehouse, there's logs, there's vendor portals, Slack. And sometimes they don't really understand the full loop of what the business logic is that actually drives this, because they're so focused on how they're collecting data and how they're harnessing it. Engineering says the system is up, but we don't know the business impact. Ops says the feed says it's fine, but the customers are still getting stuck.
Greg Howard: So that's not a people problem, right? It's an operating model problem. And the goal is to connect signal, cause and action.
Bhaskar Sunkara: Yeah, absolutely. So let's just really break these three things down, right? The signal is basically what changed. The cause is why it likely changed, and the action is what we should do now. So if you only have signal, you have a dashboard that just gives you a signal. If you connect signal to cause and action, you have an operating loop. And that's what Bicycle is designed to help with.
And that's where the name Bicycle comes from. So if you kind of look at the two wheels, the business part of it, the technical part of it, that's where it's really connecting together. And there's like a data drivetrain that's actually going through that is able to connect the dots for both of them, right? And that is why we call it Bicycle. Two wheels are the business, right?
And it's not meant to replace the warehouse or replace BI or replace observability or replace the tools teams already use, because teams have this already. But they're not able to solve a bunch of revenue leaks, or whatever is happening, in real time, because nothing's really stitching it together. And the goal for Bicycle, and what it really does, is to sit across them and connect the revenue signal to the likely cause and the next steps to action, right?
Greg Howard: Yeah, and that leads into the operating model you're referring to, Bhaskar, with the two wheels here, which shows exactly what you're talking about. You need both wheels. Technical performance is just one wheel, business performance is the other. Bhaskar, what do you think that means in practice?
Bhaskar Sunkara: It means that you can't run revenue operations with business metrics on one side and technical or operational causes on the other side. They have to be connected together. A code deployment can affect conversion. It can't be done in isolation. A stale inventory feed can affect paid media efficiency. A slow page can affect add to cart. A checkout change can affect payment success. A product data issue can affect search conversion, right? The customer experiences all of that as one journey.
So the company needs one operating model, not one dashboard: one agent loop, which is detect the issue, explain the likely cause, route it to the right owner, recommend the next step, track what happened. And then, with everything that you've done repeatedly, reuse the knowledge the next time.
Greg Howard: Where does AI fit into that loop?
Bhaskar Sunkara: Yeah, AI's only useful when it's grounded in the company's real data and real workflows, right? Generic AI is not enough. And this is the reason why we've built a vertical solution, which understands the vertical and then, beyond that, the data and the context for the particular company that we're working with.
So what does that basically mean? What does it need to understand? So the KPIs, the events, the dimensions, the funnel, the inventory and catalog context, the technical signals, the historical patterns, the approved actions, the guardrails. Only then can it help teams move from "something's changed" to here's the affected slice, here's the affected segment, here's why it likely happened, here's the impact and here's basically what to do next.
Greg Howard: And that's the difference between doing just more analytics and better recovery.
Bhaskar Sunkara: Yeah, exactly. Most teams don't need more places to look. There's enough places to look, and that's not getting it done, right? They need fewer handoffs between noticing the problem and acting on it, right? So the moment you see the signal and the moment you make a decision: how quickly can you turn that signal into a decision? That's the key thing.
The teams that win won't be the ones with the most dashboards. I can guarantee you that, right? They'll be the teams that connect signal to cause to action fast enough to act before customers notice.
Questions on agents and industry differences
Greg Howard: Now that's a great place to pause and move into questions. Let me check to see if any of them are coming in here. We do have a question coming in, Bhaskar. We touched on this, but maybe we can make this really crisp. How would an agentic analytics system handle one of the problems you discussed differently from a dashboard?
Bhaskar Sunkara: Yeah, absolutely. Just to recap a few things that we talked about already: a dashboard is showing you a metric, right? An agentic system works the loop, and the loop is end to end, from signal to action.
So let's say conversion drops. A dashboard is basically saying conversion is down. A useful agent here could be a conversion agent, right? It's basically saying conversion is down for mobile Safari in the West region, starting after the latest checkout release. Product page and add to cart are normal, but checkout completion is down. The issue is concentrated in paid social traffic. Here is the estimated revenue at risk, and here is the likely cause. Here are the next steps.
That is a different operating outcome, right? So the dashboard is giving you visibility. The agent is giving you a starting point for action, right? And the human still stays in control, right? The agent does the detective work faster. Ultimately, the team makes the judgment, and that is who is basically connecting the dots.
Greg Howard: Yeah, that makes sense. And I like how you're making it clear, once again, how the team fits into this overall agentic model.
Bicycle works with a variety of consumer segments or verticals, such as e-commerce, retail, fashion. How do you think what you're describing changes by those industry segments?
Bhaskar Sunkara: So that's a great question, because it really brings into focus what I said a little earlier, which is we're building a vertical solution. The actual vertical, the sub-vertical, the company context, all of that matters. And how is the agent basically different for that, right?
Because at the starting point, the loop is the same, right? Detect, explain, act and learn. So DEAL, as I mentioned, right? So it's the DEAL loop that's actually going from signal to action. But even as the loop is the same, the KPIs, dimensions, causes and actions change by the business model.
For fashion, the important dimensions might be size, color, fit, product family, seasonality, campaign, inventory depth, et cetera, et cetera. A fashion agent might care about questions like: is conversion down because a key size is out? Is a product ranking well, but missing core variants? Did a PDP change hurt add to cart for one category? Are returns rising for one fit profile? Is paid spend driving demand into products that can't ship? This is what an agent that's actually created for fashion would care about. This is the knowledge that it would be steeped in.
For grocery or big-box retail, the questions may be more around store availability, substitutions, delivery windows, pickup promises, inventory freshness and supplier performance. For marketplaces, it may be seller availability, catalog quality, ranking, price competitiveness.
So at Bicycle, we can't treat all retail the same. The agents we create are separate for different models, different verticals, different companies, and the agent's job needs to match the operating model. That's why we think in terms of use case agents, right? Or analytics agents that basically perform use cases.
A conversion leakage agent is different from an inventory health agent. A catalog quality agent is different from a checkout reliability agent. A payments agent is different from a merchandising agent. So the same platform can support different verticals, but the agent needs the right context for the job, which we've basically already trained, so they have the right context. And then on top of that, it can basically add the customer company context to it, and that's when it has the right context to do the right job.
Greg Howard: Just listening to you answer that question, Bhaskar, I've always believed that one of the superpowers of Bicycle is the fact that it's vertical and industry focused. You're rattling off use cases. You're not even looking at notes. You're just like, I know what fashion deals with, I know what retail deals with. The company brings a lot of tribal knowledge to these deployments, and I think it's incredibly powerful.
Bhaskar Sunkara: Absolutely.
Governance around agents
Greg Howard: Like you said, you can't treat them all the same. Okay, however, that said, another question we got: once everyone hears the word agent, they're immediately worried about safety. What kind of governance does Bicycle put around those agents? Because obviously these are very sensitive, high-transaction, consumer-facing deployments.
Bhaskar Sunkara: This is one of the most important things before you can actually push into production, right? And the most important thing is that the agents need a clear mandate. They don't watch everything equally. They have a job. For example, agent A owns conversion leakage, another agent owns inventory health, another agent owns checkout reliability, and that's what's limiting the noise.
And governance shows up in a few ways, right? So number one, data sources are approved, and there's a link to the approved sources that the data team, or whatever team, is collecting the data from. The agent only uses the systems and metrics it's allowed to use, right? So it starts off with a strong foundation.
Second, definitions for metrics, like the KPIs. You don't want an agent inventing what conversion means. It needs to pick up an approved conversion definition. The definitions need to be grounded.
Third, explainability. When it recommends something, it should show the evidence, right? The slice, the timing, the related signals, the confidence and the business impact. So that's the explainability; that's where it comes from.
Fourth, action guardrails. Some actions are safe to suggest. Some require approval. Some should only happen on a small slice. Some should be reversible. Some should just create a ticket or notify a team. And over time, it's a model where action recommendations and automations keep getting more and more nuanced, more and more complex.
Lastly, audit history, right? You need to know what the agent found, what it recommended, who approved it, what happened, and whether it worked. The goal is definitely not uncontrolled automation. It's how do you have faster and safer delivery?
What Bicycle replaces
Greg Howard: Yeah, that's a great view of how you see safety and guardrails around Bicycle's agents. A question we have: everyone's very invested in their stack. They don't necessarily want to rip and replace. So the question is, what does Bicycle replace if you were to deploy Bicycle inside an environment?
Bhaskar Sunkara: Yeah, at a very high level, it's not a rip-and-replace product. This is the reason why this category called agentic analytics is actually evolving, and it's not replacing BI per se. It's on top of BI. But at the same time, if you're using BI in a very simplistic way, there's a bunch of areas that it can really work with.
I also say it's not a rip and replace because the companies already have a warehouse. They have BI, they have observability, they have ticketing, they have Slack, they have teams. They've already paid for systems for e-commerce, payments, inventory, catalog, et cetera. So basically it's sitting across all these systems and connects them.
So I'd say Bicycle, if anything, replaces the manual stitching. Everything that you're stitching on top of it to get to the answers. It replaces the repeated investigations, it replaces the repeated treasure hunt. It replaces the war room scramble where everyone brings a different chart. It replaces the delay between seeing a metric move and knowing what to do.
It doesn't replace analysts. So the analogy I can bring in here is, it's very similar to how Cursor or Claude Code have been for developers. They don't really replace them. They're really force multipliers for them, right? It gives analysts more leverage. Let me say that differently. It gives analysts more time for higher-value work, and it really multiplies their impact, right? Instead of spending hours slicing the same KPI across 20 dimensions, they can focus on judgment, decisions, experiments and deeper analysis.
So the best way to think about it is, Bicycle doesn't replace your data stack. It makes the stack operational when revenue is basically moving.
Greg Howard: Yeah, I love the Cursor analogy. It just gives the existing team more efficiency and impact, not replacing anybody, but taking all the mind-numbing work they don't want to do anyway, and reducing those treasure hunts.
Inside a typical deployment
Greg Howard: Just looking at time, Bhaskar, we do have a couple more. We'll follow up with people by email if we didn't get a chance to answer your question. But let's just do one more here, and I think, before we really dig into use cases, this is a good one to tie off with. What are the actual tasks that these agents perform in a typical Bicycle deployment?
Bhaskar Sunkara: So number one, it understands the data. So it identifies the relevant events, KPIs, dimensions, relationships. So for e-commerce, that might include product views, add to cart, checkout start, checkout completion, purchase, inventory updates, fulfillment status, campaign data, et cetera, right?
And so it understands this because, again, because we're a vertical solution, it has the context. It's pre-trained with context for a particular vertical that we support, like retail. So once it understands that, we have an agent that actually onboards all of that data and builds an ontology, builds a core data model. That is important.
The second: once it has the data model, where it's like, hey, here are the KPIs, here are the dimensions, it actually builds the logic for watching all of those KPIs. So which of these KPIs matter? Which slices matter? What is normal? What counts as meaningful movement? Which changes should wake someone up? So that's the playbook that Bicycle will generate on the core foundation, and then produce whatever is needed to execute that logic, right?
Third, it detects issues. So not just top-line changes, but slice-level movement, right? So that's the detection part of it.
And fourth, it investigates. So it asks, where is the issue concentrated? What changed around the time? Which technical, operational or business signals moved with it? Have we seen this before?
Then it explains, right? It turns the investigation into a clear story. Here's where it needs access to multiple tooling, so that it can connect the dots across. Here's what changed. Here's who was affected. Here's the likely cause, business impact, et cetera.
And lastly, it recommends action. And that could be opening a ticket, notifying an owner, suggesting a rollback, refreshing a feed, pausing spend, et cetera. All of those can be automated, or they can be done with human intervention.
Once it does all this, the most important thing for this loop is learning from the outcome, right? What action did the team take? Did the metric recover? Should this pattern be recognized faster next time? That is the agentic task list, not just answering questions. It's actually running an operating loop to go through all of those. And that's what we need to do to set up the right deployment.
Closing thoughts
Greg Howard: I think that's a great place to land. I love that, running the loop. So the takeaway for me in this conversation, Bhaskar, is pretty simple. Revenue leaks in e-commerce are not just visibility problems, they're connection problems. You've got the signal in one place, the cause is somewhere else, the action belongs to another team. And you even said that the root cause tying all these stories together is the disconnected teams. And the problem is that the impact is felt by the customer before the company even realizes there's money going out the door. So that's my takeaway, but I'm curious if you have final thoughts you wanted to share before we close out.
Bhaskar Sunkara: I feel most teams already know when something changed. So that's not the hard problem. The opportunity here is to get much faster at understanding why it changed and what to do next. And that's where I think AI can help: not by adding another dashboard and not by creating more noise, but by helping teams recover faster.
If you give AI the right context, and it's steeped in the vertical, the context around the particular company, that's where it can actually do the job, right? And help teams recover faster, which is why Bicycle's built around that idea. Connect the business signal, find the broken slice or the segment, explain the likely cause, recommend the safest next step, keep the human in control. That's where accountability for decisions really comes in. That's how e-commerce teams can move from dashboard theater to real revenue recovery.
Greg Howard: That's perfect. Bhaskar, thank you so much for joining us and sharing those thoughts. I thought that was fantastic. And everyone, thanks for joining us and giving us your time as well. We'll send you the recording after the session. And if we didn't get to your questions, we'll answer them by email. And if you want to see how Bicycle can help your team find and fix revenue leaks before they reach the customer, reach out and we'll be happy to set up a walkthrough. Thanks again, everybody. Have a great day.
