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
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.

Current status and testing

Faster reporting still needs proof.

The concept is intended to speed up reporting without removing the controls people rely on. Advanced work remains available in the builder, while the design also accounts for data quality, empty results, stale records, and permissions.

01
Frame the business question
Sessions test whether sales reps and leaders can describe the report they need without first translating it into modules, filters, and fields.
02
Verify before building
Participants review SugarAI’s interpretation, check the proposed structure, preview refinements, and recover an earlier version.
03
Find the supporting workflows
Entry points for scheduled reports, sharing, export, and report details help test where people expect those actions to live.

“How do we get this in the hands of my team next week?”

Early feedback suggests that the core premise is understandable, with participants asking when they can use the prototype in day-to-day reporting. Until testing is complete, the move from seven setup screens to three steps remains a workflow hypothesis rather than a measured time saving.

The goal is not to replace buttons with a prompt. It is to move faster without losing the ability to verify, correct, and recover.