Customer-facing analytics often begins as a request for a chart or dashboard. The production requirement is larger: the right customer must see the right metric, in the right host context, with predictable interaction, artifacts, failure states, and operating ownership.
That is the problem we created Sumboard to address.
Sumboard is a dashboard builder and embedded analytics product for B2B SaaS teams. The goal is not to claim that every analytics workload should be bought or that every dashboard should be built with one platform. It is to provide a product boundary for teams that want to deliver governed analytics inside their application without owning every layer themselves.
A Customer-Facing Analytics Feature Is an End-to-End Task, Not a Collection of Charts
The product thesis was simple: a customer-facing analytics feature should be evaluated as an end-to-end customer task, not as a collection of charts.
A task might be “review account performance, isolate a change, and share the evidence.” Shipping that task requires more than a visualization:
- host identity must map to the correct customer, role, and data scope;
- metrics need explicit definitions, filters, time handling, and ownership;
- queries need bounded execution, freshness, and failure behavior;
- filters, drill paths, loading, empty, stale, and error states need product design;
- exports and shared artifacts must preserve the same scope and branding;
- logs, support evidence, recovery, and change management need owners.
This is why a polished dashboard screenshot is not a launch criterion. The feature is ready when a permitted customer can complete the intended task and the team can explain, test, support, and recover every state on that path.
Build, Buy, or Combine Boundaries
The decision is not a moral choice between custom engineering and software. It is an ownership decision.
Build the full stack
A custom route can be correct when analytics interaction is a core differentiator or when the workload has unusual rendering, latency, deployment, or control requirements. The team then owns the complete contract: semantic modeling, query generation, tenant enforcement, charts, filters, responsive behavior, accessibility, exports, scheduled artifacts, observability, support, and upgrades.
Estimate that route from a production slice and a component inventory. Avoid universal timelines or cost ranges; the work depends on what the task actually promises and which infrastructure already exists.
Embed an analytics platform
An embedded analytics platform can own more of the dashboard, query, artifact, and operating surface. The host application still owns customer identity, product authorization, navigation, commercial entitlement, and the way analytics fits the surrounding workflow.
Different products expose different routes: iframe, SDK, components, API, managed cloud, self-hosted, or combinations. Test the exact route rather than comparing product names or assuming that a platform designed for internal BI cannot have a documented embedded offering.
Combine routes deliberately
Many products need a hybrid. A team might use custom UI for a high-frequency operational task, an embedded builder for customer-authored dashboards, and scheduled reports for durable review artifacts. The important part is to assign semantics, access, runtime, artifacts, support, and exit ownership for each route.
Sumboard Sits Between the Host Application and the Customer's Analytical Task
Sumboard focuses on the customer-facing analytics product layer that sits between a SaaS host application and its customers' analytical tasks.
The host application remains responsible for authenticating the user and deciding which customer, role, and product entitlement applies. The integration passes an authorized context into the analytics route. The analytics configuration then needs to preserve that context through queries, dashboard interaction, drill paths, exports, links, and other artifacts.
Product teams can manage dashboard configuration and presentation without treating every content change as a new host-application feature. Engineering teams retain responsibility for the trusted integration boundary, data access, production testing, and observability.
This division is useful only when it is explicit. “Token-based” is not proof of tenant isolation, “white label” is not one color setting, and “responsive” is not a desktop canvas scaled down. Each promise needs a route, a test, an owner, and a recoverable failure state.
What We Chose to Prioritize
The launch direction centered on five product requirements.
Composition Should Not Require an Application Change, or Invent Business Meaning
Product teams need to arrange metrics, visualizations, filters, and explanatory context without changing application code for every dashboard revision. The builder still depends on governed data and metric contracts; drag-and-drop composition should not invent business meaning.
The Browser Can Carry the Scope, but Only Trusted Services Can Enforce It
Customer-facing analytics must begin with trusted host identity and authorization. The browser can carry scoped context, but trusted services must prevent a user, URL, export, cache, or query from widening it.
Fitting the Host Product Means Its Loading and Error States, Not Only Its Dashboard
The embedded surface needs to fit the host product's navigation, visual language, loading, empty, stale, error, and recovery patterns. Branding also extends to generated artifacts and shared surfaces, not only the live dashboard.
An Export Has to Carry the Same Scope and Definition as the View It Came From
Some tasks end in a filtered view; others end in an export, report, or shared artifact. Every output should retain its metric definition, customer scope, filters, time window, freshness, and access policy.
Queries, Caches and Exports Fail, so the Runtime Needs Named Owners and Recovery Paths
Queries, caches, sources, sessions, renders, and exports fail. A production product needs timeouts, bounded workloads, visible degraded states, logs, support identifiers, recovery paths, and named owners.
The currently published plan and feature details live on the pricing page. Those capabilities and commercial terms can change after a launch article is published, so the live product page, not this historical post, should be treated as the current product specification.
Who Should Evaluate Sumboard
Sumboard is relevant when a B2B SaaS team has a bounded customer-facing analytics task and wants to evaluate a managed product boundary rather than automatically building every layer.
Useful evaluation triggers include:
- customers repeatedly need the same governed view or artifact;
- manual reporting has an identifiable owner and recurring failure cost;
- the host product can provide trusted customer and role context;
- metrics and expected results can be reconciled against a source;
- product, engineering, data, security, and support owners can define pass rules;
- the team can run a production-shaped pilot before committing to rollout.
These triggers do not prove that Sumboard, or any platform, is the answer. They define when an evaluation has enough structure to produce evidence.
How to Evaluate the Product
Start with one difficult, representative customer task. Connect production-shaped data in an approved environment, map one hard metric, integrate the intended customer role, and test the complete path.
The pilot should cover metric reconciliation, tenant denial, direct links, filters, exports, responsive and accessible states, realistic workload, stale and failed sources, timeout, recovery, logs, support handoff, commercial assumptions, and exit. Preserve the configuration, expected results, screenshots or recordings, query identifiers, and owner decisions.
Expand only after the slice passes. A platform should earn rollout through equivalent outcomes and an operable contract, not through a demo that avoids the hard tenant, metric, artifact, and failure cases.
What the Launch Meant
Launching Sumboard meant committing to customer-facing analytics as a product discipline. The hard work is not drawing more charts. It is keeping identity, meaning, execution, interaction, artifacts, and operations aligned as the customer's task moves through the system.
That remains the standard against which the product should be evaluated.
To inspect the current product boundary, continue with the customer-facing analytics product, the embedded analytics product, and the live pricing and plan details.
Where to go next
- Embedded analytics guide: the three routes to shipping it, what each one costs in calendar time, and the four things that set your launch date.
- Embedded Analytics Implementation: most embedded analytics implementations take weeks.
- Embedded Analytics articles: every article in this cluster.
Ready to launch customer-facing analytics?
Stop losing customers to competitors with better analytics. Sumboard's customer-facing analytics platform lets you launch self-service dashboards in days, not months.
