From 5-Hour Reports to 45 Minutes. MontyCloud's First Insights Dashboard, Adopted by 94% of Customers.

MontyCloud had WAFR check execution, you could run an AWS audit and get a list of findings. But the results were raw data. No charts, no summaries, no way to present them to a client. MSPs were exporting CSVs and building PowerPoint decks from scratch. Four to six hours per client, every time.

I designed MontyCloud's first insights dashboard in 6 weeks. It became the feature sales cited in 12 of 28 closed deals in the quarter after launch.

Impact

· 3 months after launch

Before · ~5 hours

45min

MSP report creation time, per client

Before · N/A

94%

Adoption: 25 of 27 active MSPs

First quarter post-launch

Before · 47%

58%

Deal closure rate

Multiple factors; dashboard was cited in 12 / 28 deals

Before · Consistent complaints

↑

Customer satisfaction on reporting

Qualitative signal, not a tracked metric

The problem

When MSPs ran a WAFR check on MontyCloud, they got a list of findings. That was it. No visualization, no summary, nothing presentable to a client.

What MSPs were actually doing:

Exporting CSV data from the platform
Building PowerPoint decks manually (4–6 hours per client, per quarter)
Creating their own bar charts, donut charts, and "worst offender" lists from scratch
Presenting these decks on client calls, in decks that looked different every time

The business signal:

18 of 27 prospects in Q2 2023 explicitly asked for visual reporting before closing
Existing customers were threatening churn over the reporting burden
Sales had nothing to demo, we had no reporting capability at all

PM and Founder came to me: "We need visual reporting for WAFR results. Can we build something?"

Who it was for

MSP Engineer / Solutions Architect

Primary

Runs WAFR assessments for multiple clients
Needs to produce client-ready reports after each run
Presents findings to non-technical stakeholders (CTOs, VPs)
Currently spending hours per client on manual slide-building

MSP Business Owner / Account Manager

Secondary

Needs reporting output to demonstrate value to enterprise clients
Wants competitive differentiation over manual audit workflows
Not technically fluent, needs the dashboard to be immediately readable

Research method: I reviewed 8 PowerPoint decks collected from MSP customers, ran 2 direct interviews (45-minute calls), read 12 support tickets requesting reporting, and shadowed one live client presentation. The enterprise context made broader usability testing impractical.

The design question

How might we turn a 5-hour manual reporting workflow into something an MSP can produce and present in under an hour: without sacrificing the executive readability their clients need?

What I designed

The redesign was a dashboard, not a report. That distinction was a deliberate choice made early with PM.

A report lets users configure what they see. A dashboard decides for them, standardized visualizations, consistent chart types, one layout. I pushed for the dashboard model because:

We were building from scratch with one developer in 6 weeks
Customization would have tripled scope
MSPs wanted speed and shareability, not pixel-perfect brand consistency

Six visualizations above the fold: bar charts by AWS pillar, donut chart for pass/fail split, top 5 violating resources, top 5 violating checks, breakdown by resource type, and interactive filtering that lets any chart segment filter the findings table below.

The solution. What shipped, and four decisions inside it

Decision 1 · No-scroll dashboard layout

I chose

Everything visible above the fold. Six core visualizations in a grid, top violations prioritized, findings table below for drill-down, no scrolling to reach key data.

I rejected

A scrollable detailed view with all possible metrics, including pillar-by-pillar detail views, resource-type breakdowns by region, and per-account comparisons that 3 of 8 PowerPoint decks included.

Why

I looked at the PowerPoint decks MSPs were building manually. Every one fit key metrics on one slide. Their clients were executives, they scan, they don't scroll. Including every possible metric would have made the dashboard feel like the raw data export it was supposed to replace.

Outcome

In retrospect, this was right, but I underestimated how much users would want detail views once they were comfortable with the overview. "See all findings" links below each Top 5 were added in Q2 to counter anchoring behavior.

Decision 2 · Top violations: frequency over severity

I chose

Frequency-based ranking: Top 5 most-violated checks, Top 5 resources with the most issues. Objective and verifiable.

I rejected

Severity-based ranking: High / Medium / Low risk labels. This was the PM's initial suggestion and the more common industry approach.

Why

I tested both approaches with 5 MSP users. Severity failed: a "High" security issue might be irrelevant for a client running only dev workloads. 3 of 5 users disagreed with severity assignments, it felt subjective. Frequency worked: all 5 users completed "Find the highest-risk resource" without instruction. The label was verifiable, not judgmental.

Outcome

Shipped as frequency-based. Later discovered MSPs' clients anchored on the Top 5 and ignored everything else, we hadn't designed for that. Added "See all findings" links once the anchoring pattern was confirmed.

Decision 3 · Copy as PNG

I chose

A Copy button on each chart that puts the visualization directly onto the clipboard, one click, ready to paste into a PowerPoint slide.

I rejected

Screenshot-and-crop workflow (the existing workaround), and a PDF export that engineering could have built more quickly.

Why

This wasn't in the original spec. I discovered it during customer shadowing. I watched one MSP: screenshot the data export page, open in Preview, crop, paste into PowerPoint, repeated for every chart, every client. The browser clipboard API supports it. Half a day to implement. I asked PM: "Can we just add a Copy button?" PM: "Is that feasible?" I checked with the developer. We shipped it.

Outcome

Used by nearly all active MSPs within the first week. Became the #1 mentioned feature in sales demos, not the charts themselves, but the ability to copy them. The single-chart copy created a new repetitive workflow (chart by chart), which I should have anticipated and solved with "Copy all" from day one.

Decision 4 · Interactive filtering: additive, with explicit Clear All

I chose

Click any chart segment to filter the findings table below. Filters stack additively. An explicit "Clear all filters" button and persistent filter chips at the top of the table show what's active.

I rejected

Auto-clearing filters that reset when a user clicks a new segment, my initial design, which felt cleaner to build.

Why

In testing, 3 of 5 users wanted to compare multiple slices simultaneously, click "Security" pillar, then add "Cost Optimization." Auto-clear broke that. I added the explicit clear button instead. The filter chips came from a second observation: 3 of 5 users forgot they had filters active and thought data was missing. Neither change was innovative, but since we were setting patterns for the first time at MontyCloud, these became the interaction foundation for the next 3 features I designed.

Outcome

Filter pattern shipped and was adopted directly as the MontyCloud standard for subsequent features without modification. Visual QA cycles for table-related features dropped because there was now a documented reference pattern.

What the data showed

Adoption (3 months post-launch): 25 of 27 MSPs were using the dashboard. Report creation time dropped from ~5 hours to ~45 minutes per client.

Business context, with caveats: During the same 3-month period, deal closure rate went from 47% to 58% and customer churn decreased by 15%. Sales cited the dashboard in 12 of 28 closed deals.

I'm listing these numbers because they're real. But multiple factors contributed, pricing changes, market conditions, other product improvements. The dashboard was one variable, not the only one. The qualitative signal was stronger: sales consistently called it a competitive differentiator we hadn't had before, and 3 churning customers mentioned it as the reason they stayed.

"This dashboard transformed our client conversations. We went from explaining problems to discussing solutions.", MSP Customer

What I'd do differently

Test with MSPs' clients, not just MSPs. I optimized for the person building the report and never validated with the CTO or VP receiving it. We designed for the creator's workflow; the audience's needs were secondary. A client-facing "presentation mode" with larger fonts and simplified language would have served that audience better.

Push for analytics instrumentation. The "94% adoption" number came from manually polling MSPs through sales. We didn't have product analytics until Q3. Real usage data earlier would have told us about the anchoring behavior on Top 5 lists and prompted the "See all" links a quarter sooner.

What I learned

Enabling a workflow matters more than polishing an interface. The dashboard wasn't beautiful, standard charts, dense layout. But it replaced a 5-hour manual process with a 45-minute one. MSPs didn't care about visual polish; they cared that they could copy charts into their own decks.

The best feature solved a problem outside our product. Copy-as-PNG got higher adoption than interactive filtering. The most impactful thing I designed wasn't what users did in the dashboard, it was what they did after they left it. This shifted how I think about product boundaries.

Every decision at a 0-to-1 company sets precedent. The filter interaction I chose for this dashboard, additive, with visible chips and explicit clear, became the documented MontyCloud standard for the next 3 features. I didn't plan for that. It happened because there was nothing else to reference.

WAFR Trends Over Time: added in Q4 with 6 months of usage data

The trends chart, showing how failed findings decreased across multiple WAFR runs, didn't make the 6-week cut. It needed historical data storage we didn't have. We shipped it in Q4 once I understood from real usage data which time ranges mattered to MSPs and how they actually used historical data. That was different from what I'd originally assumed.

Impact

The problem

Who it was for

MSP Engineer / Solutions Architect

MSP Business Owner / Account Manager

What I designed

The solution. What shipped, and four decisions inside it

What the data showed

What I'd do differently

What I learned

More Case Studies