Designing a Consistent AI Experience Across an Enterprise Analytics Product

At a Glance

Dashboards Answer "What." Not "Why."

A dashboard at Petavue is trustworthy by the time it reaches a viewer: every metric defined consistently, every number checked before publishing. But correct isn't the same as understood. A number moves, and the real question is never whether the data pipeline worked. It's why it moved, whether it's worth reacting to, and what to do next, none of which a static chart can answer on its own.

A dashboard is built to display a computed state clearly. It was never built to explain how that state came to be.

Before Sage, People Filled the Gap

That gap got filled the way it always does in enterprise software: through people, not the product.

None of the old paths were fast, and none left a record the next person could find. Even the workaround itself was manual labor: a single revenue dashboard blends Salesforce, marketing spend, and product usage, so "why did this account's health score drop" meant a human stitching together a support ticket, a usage dip, and a stalled deal from three separate systems, every single time.

That Gap Became Sage

Not "give Petavue an AI feature," but let a person go from a chart that raised a question to a decision they trust, inside the same screen.

Sage's job was to close that gap without becoming a second product people had to learn.

Deciding Where a Conversation Should Begin

The default shape for a feature like this is a standalone assistant, its own page, its own history. We prototyped that path and walked through the first sixty seconds of using it. The cost was entirely about context: a RevOps manager would have to leave the dashboard where they noticed a drop, open Sage elsewhere, name the metric they were already looking at, and restate a date range they'd set thirty seconds earlier, before they could even ask their real question.

• 1Dashboard stays fully visible — the chart that prompted the question never leaves the screen.
• 2Panel opens beside the dashboard, not over it — nothing already on screen gets hidden.
• 3Opening message already reflects the widget, filters, and date range in view.

Everything downstream, the prompt suggestions, the reasoning layer, the response format, only works because the conversation never has to start from zero.

Designing for Confidence, Not Conversation

Nobody asked for a warmer chat tone. Every research conversation surfaced some version of "how do I know this is right," because a wrong answer about pipeline health, presented confidently enough to act on, is a real cost. That reframes the whole problem: not "make Sage sound smart," but "make Sage's confidence legible," so a reader can tell an answer worth acting on from one worth double-checking.

This is also where "not a chatbot" stops being a branding line and becomes a real constraint. A chatbot optimizes for feeling conversational. Sage optimizes for being checkable, and checkable answers occasionally read as more clinical, an intentional trade after watching people hesitate over confident answers with nothing to verify against.

Answering With the Dashboard's Own Definitions

The failure mode we designed against from day one: Sage quietly disagreeing with the dashboard it was opened from, by reinterpreting what a metric means instead of reading the definition already configured for it. In an enterprise product where a metric's definition is often months of internal debate, that kind of silent disagreement is the fastest way to make a team stop trusting a feature. So Sage reads from the same metric and business-logic definitions the dashboard already used, rather than interpreting raw data independently.

What a Response Needs to Do That a Chart Can't

A question like "where are we wasting marketing spend" isn't a short exchange. It needs evidence specific enough to support a conclusion, a recommendation grounded in that evidence, and a way to keep investigating, more than a single chat bubble can hold. So every Sage response is organized the same structured way, regardless of what was asked, and a reader learns the shape once.

• 1Verdict states the true ROAS against platform-reported ROAS in the first sentence: 3.61x versus 0.96x, before anything else loads.
• 2Evidence breaks the number down by channel, Google leading at 4.81x, Meta lagging at 0.98x, so the headline figure isn't taken on faith.
• 3Recommendation is offered as a choice grounded in what it just found: move spend, pause a campaign, or flag specific accounts to sales, not a generic "consider reviewing your campaigns."
• 4Follow-up prompts anticipate the next three questions a RevOps manager would actually ask, rather than a blank box waiting for one.

This structure isn't unique to Sage, and that's deliberate: it's the same headline-detail-next-step shape people already use to review a dashboard elsewhere in Petavue, so Sage reads as an extension of the product instead of a bolted-on feature.

The Cold-Start Problem

An empty prompt box assumes someone already knows exactly what to ask. Most don't, especially the first time, and that gap is where features like this quietly die: one vague question, one vague answer, and the tool never gets opened again, no loud failure, just a feature that stops getting used.

Sage generates its suggested prompts from the dashboard currently in view, so someone on a pipeline dashboard sees prompts about pipeline movement and rep performance, not a generic "ask me anything." Early versions surfaced safe questions like "tell me more about this dashboard," which taught the wrong lesson, that Sage was a summarizer. Rewriting them toward "why did this metric drop this week" nudged people toward the kind of question Sage actually exists to answer, turning that first interaction into recognizing a question that was already there, not inventing one from nothing.

One Assistant, Wherever the Question Comes From

Most conversations never start from Sage's own home in the product. They start from a dashboard, a proactive recommendation, or a goal someone is tracking, and Sage has to feel identical from every one of those, or people learn several slightly different tools instead of one. It would have been faster to ship a lighter version for recommendations, where context is narrower, but that shortcut teaches people that Sage's depth depends on how they got there.

In practice, the recommendation surface turned out to be where most people met Sage for the first time, which made this consistency requirement far more consequential than it looked on a whiteboard.

Answers That Don't Disappear

A chat interface implies its own contents are disposable, fine for a general assistant, not for a product whose original complaint was that reasoning lived only in someone's memory of a meeting. So every Sage response is anchored to the dashboard and moment it was generated, not floating in a timeless chat log. Someone can return weeks later and find the exact analysis that explained a past change, still connected to the state it was based on, shareable with a teammate who wasn't in the original conversation.

Conversation Design Is Interaction Design

A chat interface looks like a solved layout problem, a message list, an input, a send button. Almost none of the real design work happened there. It happened in the states below, each one solving a specific way a clean Q&A model breaks down in practice.

None of these show up in a happy-path screenshot, which is exactly why they're easy to underestimate. They're the reason the experience feels dependable even when a query is slow or data is mid-sync, and in practice they took roughly as much design time as the response layout itself.

Prototyping the Interaction, Not the Interface

Static comps show a response frozen at one moment. They can't show what it feels like to watch an answer stream in at a natural or sluggish pace, or hit a clarification question mid-conversation, because conversation design lives entirely in time. So I built a working front-end prototype in Claude Code, using React and the product's existing design system, specifically to test streaming pace, transition timing, and how disruptive a clarification felt in the moment, questions no static comment thread can answer.

That prototype became the actual review artifact for product and engineering, ahead of the polished Figma file rather than after it. Reviews shifted from opinions about spacing on a static screen to whether the interaction itself held up, and several timing decisions got settled in that room, before a single line of production code existed to relitigate them.

What Engineering Constraints Actually Shaped

"Worked closely with engineering" usually describes proximity, not substance. What actually happened: most of the interesting design decisions here came directly out of a technical constraint, and understanding the constraint was the fastest way to the right design answer.

Execution labels went through several rewrites with engineering for the same reason: "Executing aggregation query on filtered dataset" is accurate and useless. "Checking spend across your active campaigns for the selected period" answers the only question that matters, is Sage looking at the right thing, and getting there required engineering to walk through what each query step actually did.

What Success Looked Like Without a Launch Metric

Sage was new enough at launch that there was no baseline to compare against, so success was defined as specific behavior to watch for, not a number chosen because it was measurable.

• People start real, specific conversations on their own, without an onboarding tour or a colleague showing them what to type first.
• Conversations stay grounded in the dashboard they opened from, rather than drifting into generic questions.
• Answers feel trustworthy enough that people act on them directly, without quietly re-verifying in a second dashboard.
• Fewer retries to reach a useful answer, because the first suggested prompt was already close.
• Exploring a dashboard naturally continues into a conversation instead of stopping cold.

Every one of these is a behavior, not a metric with a target attached. A conversion number can be hit by accident. These couldn't be.