SugarAI · Enterprise reporting

What if building a report started with a question?

I designed a SugarAI reporting concept that starts with a business question and keeps expert controls within reach.

Role: Lead UX designer, partnered with PM and the Engineering Lead
Status: Prototype in development; tested with three sales reps
Scope: Strategy, UX, UI

The problem

A business question had become a technical setup project.

A sales leader knows what they need: open opportunities closing this quarter, grouped by sales stage. The existing workflow begins somewhere else, with the product’s data structure.

Users first choose a report type and module, navigate relationships, define filters, configure summaries, select columns, and set chart options. They reason through the implementation before seeing an answer.

Each decision lives on a separate screen, so users hold the report in their head while working through one fragment at a time.

The current experience begins with the system’s data model. The redesign begins with the user’s question.

Existing Report Wizard module selection screen with dozens of modules — 01Choose the module. The first step asks for a data-source decision before the report question can even be described.

Research

Start with the questions people actually ask.

I met with sales reps and leaders to understand what they repeatedly needed reports to answer. Reps focused on today’s priorities; leaders looked for team health, forecast risk, and pipeline patterns.

Sales Representative

What do I need to work on today?

My pipelineWhich opportunities need my attention?
Closing and stalled dealsWhat is urgent, valuable, or no longer moving?
Recent activityWhere do I need to follow up next?

Sales Leader

Is my team healthy?

Team pipelineWhere is value concentrated across reps and stages?
ForecastAre commit and likely revenue tracking against quota?
Risk and performanceWhich deals or patterns need coaching attention?

Design challenge

AI had to expose the setup, not hide it.

The research made the central tension clear: natural language could make reporting faster, but a silently generated chart would hide the reasoning behind it.

A chat-only shortcut was not enough. SugarAI needed to propose the setup, then make inspection, editing, and recovery immediate.

Key decisions

Three choices shaped the design.

Review before building

Considered: Generating the report immediately
Chose: A review step before anything is built
Why: Incorrect filters can still produce a convincing answer.

Let people type or edit directly

Considered: A chat-only experience
Chose: A prompt and direct editing together
Why: Experienced report builders still need precise control.

Preview changes before applying them

Considered: Applying refinements immediately
Chose: Preview, Undo, and version history
Why: A short request can substantially change the answer.

Before and after

From seven setup screens to one question.

SugarAI handles the setup work. People describe what they need, check the proposed structure, and build the report.

Before · 7 steps

Configure the system

Start with the CRM’s structure and work through seven separate decisions.

01
Choose a moduleKnow where the data lives
02
Define filtersTranslate the question into rules
03
Define groupsChoose how records are organized
04
Choose summariesDecide what gets calculated
05
Choose columnsAssemble the result table
06
Set chart optionsConfigure the presentation
07
Add report detailsName and save the report

After · 3 steps

Ask, review, and build

Start with the business question and confirm the structure before building.

01
AskDescribe the business question in familiar language.
02
ReviewCheck SugarAI’s interpretation before anything is built.
03
BuildCreate a report that shows its setup and can be changed without starting over.

The new concept

A question becomes a report users can inspect.

Flow 1

Create a report from a business question

The primary path turns a plain-language request into a report through a few deliberate checkpoints.

Demo

See the complete creation flow

SugarAI frames the question, checks for existing work, confirms the setup, and returns an editable report. Users can preview the table and switch chart types without changing the definition.

Flow 1: creating a report from a business question.

Key moments inside Flow 1

Supporting details that make the flow feel understandable

Help getting started

Welcome users with language and examples grounded in familiar jobs

Create with SugarAI opens with common questions from the research: pipeline by stage, at-risk opportunities, quarterly forecast, and win rate by rep. The examples give users a strong starting point.

SugarAI report assistant welcoming the user with helper text and four common reporting questions — Suggested questions teach the input format without making users start from a blank prompt.

Check what already exists

Find reports that may already answer the question

SugarAI first searches existing reports and surfaces likely matches. Users can open one or start a new report anyway, avoiding duplicates without blocking creation.

SugarAI showing two existing reports that may answer the user's pipeline question, with Pipeline by sales stage hovered — Similar reports appear before generation, giving reuse a chance without blocking creation.

Review before building

Show exactly what SugarAI is about to build

One screen brings together the data source, report type, grouping, metric, filters, and columns. Users can correct the setup before generation.

SugarAI review card showing the complete report definition before building — The review card turns the request into editable report settings.

While SugarAI builds

Keep users informed while the report is being assembled

A short sequence names the work underway: reading the request, checking records, grouping the result, and preparing the chart and table.

SugarAI building progress with completed checks, an active grouping step, and an upcoming chart-and-table step — Progress labels make each step legible while the result is being assembled.

After the report is built

Keep the report setup easy to find

The Report definition drawer keeps the setup available after the result appears, so users can inspect or refine it without starting over.

Report definition drawer showing the report data source, report type, grouping, metric, filters, and visible columns — Report setup remains one click away after the result appears.

Flow 2

Refine, preview, and track history

The follow-up path lets users change a completed report, preview each update, and recover earlier versions.

Demo

Show the change-and-recovery loop in context

The recording starts from the completed report, applies two refinements, previews each update, and ends with the history drawer open.

Flow 2: refining a completed report, previewing each change, and opening Change history.

Why should I trust this?

Use drawers for details that need inspection

Post-build drawers answer practical questions without competing with the main report: Why this report?, Change history, and Data checked.

Testing and learnings

One result. Different ways to get there.

Three sales reps tried the prototype. They responded positively to seeing a report take shape from a few plain-language statements. During these sessions, I observed no confusion completing the tested flows; reps could see the data they were trying to assemble.

01
The visible result made the flow understandable
Reps liked seeing the report build before their eyes from simple statements. The visible data helped them follow what they were creating.
02
Different users preferred different controls
Two reps preferred tweaking the report directly, while the third used chat to make updates. This supported keeping both interaction methods available rather than making chat the only path.
03
Recovery mattered; history could be easier to discover
One rep asked whether they could return to an earlier report state, then learned that report history supported this. The capability addressed their concern, while the question raised an opportunity to make it easier to discover.

What I learned

The value was not simply replacing report configuration with chat. It was making the result visible quickly while letting people refine it in the way that felt natural to them. Testing supported the existing combination of chat and direct editing rather than pointing to a single preferred method.

These findings reflect three prototype sessions, not a measured time saving or validation of every reporting workflow. Next, I would test whether users can discover and restore report history without guidance.