Sisense embeds AI analytics inside the products customers already use

Sisense provides the analytics layer a software company can embed inside its own product. AI supports analytics creation and natural-language query generation, while Compose SDK gives developers control over the surrounding experience. In the documented dashboard assistant, users must interpret the generated results themselves. The buying decision is whether those results use the right metric, customer boundary and application context.

01 / ProductAn analytics platform underneath the product interface

The embedded analytics overview describes a governed semantic layer, application embedding, APIs and AI interactions. The semantic layer represents metrics and relationships that should remain consistent across the user experience. The surrounding application remains responsible for its own navigation, commercial entitlements and business workflow.

Compose SDK lets developers create queries, charts and filters from application code, with support for React, Angular, Vue and TypeScript. It is useful when an analytics experience needs to fit a particular product screen rather than appear as a separate dashboard destination. Choosing it also means taking ownership of component behavior and application integration.

The current Assistant documentation distinguishes Studio Assistant for analytics creation from Analytics Assistant in dashboards. Users' permissions affect what they can save or change. A viewer may explore data without being allowed to modify the shared dashboard. Sisense's company page continues to present the business around embedded analytics, with its own leadership and investor backing.

02 / AudienceProduct teams with recurring customer questions

Imagine a logistics software vendor whose customers repeatedly ask why their on-time delivery rate changed. The data already exists in the product, but answering a follow-up requires exporting records and asking a support analyst. Embedded analytics is attractive when those questions recur often enough to justify a maintained reporting experience inside the customer portal.

The audience includes developers, product managers and data owners together. A developer can implement an attractive chart without knowing whether a cancelled shipment belongs in the denominator. A data analyst can define that metric without knowing how the customer switches accounts. Sisense addresses pieces of the analytical workload; the product team still needs to join those decisions coherently.

For a broader conversational analytics comparison, see the ThoughtSpot blueprint. The Microsoft blueprint is relevant when existing Microsoft applications and analytics already shape the deployment. Compare the cost of connecting analytics to the product's identity and release process, rather than comparing chatbot responses without the surrounding permission model.

Sisense may be excessive for a site that needs only one static chart or a downloadable monthly report. In that case the model, hosting and embedding work could outweigh the benefit. The useful threshold is a recurring need for exploration that the product team is willing to support as an ongoing feature.

03 / WorkflowA proposed delivery panel with natural-language query generation

Begin the proposed pilot with one customer-facing logistics screen. Show delivery performance for a selected customer and period, then let the user investigate a change. This example is a design for evaluation, not a report of implemented Sisense behavior. Keep the existing report available during the pilot so that disagreements can be investigated against a known calculation.

Define the metric first. Specify what counts as delivered on time, which timestamp represents the promise, how cancellations are treated and which time zone closes a reporting day. Add descriptions that make those definitions available to the analytics model. A conversational interface should not be expected to infer a contractual service definition from an ambiguous column name.

Build a small set of deterministic views before enabling natural-language questions. A customer should be able to choose a period, see the underlying shipment count and inspect the same denominator used by the headline percentage. That creates an anchor for evaluating an assistant's answer. The percentage is easier to trust when the supporting rows are discoverable within the customer's authorized scope.

Then connect the host application's customer identity to the analytics access model. Use two test customers with deliberately different shipment records and one user who can legitimately access both. Check switching accounts, reopening a saved view and following a deep link. Those transitions can reveal a data boundary failure that a single successful dashboard load would miss.

Enable the assistant only for the intended environment, group and dashboard. The Assistant guide describes administrator enablement, dashboard-level sharing and the need to configure a supported LLM provider. Confirm the prerequisites for the chosen deployment before promising the feature to customers. The presence of an SDK package alone does not establish AI entitlement.

Generate successive queries for delivery rates by route, shipment counts by carrier and the same metric excluding a selected carrier. Compare each chart with the deterministic view. A person then interprets what changed and investigates possible causes. The documented dashboard assistant builds queries from metadata; it does not inspect query results to draw conclusions, and cannot answer using the outcome of a previous query. Remembering earlier prompts does not remove that limitation.

The release review should cover both the result and the interface state. Does the chart retain the selected customer and date range? Does a conversational answer reveal which filters it used? Can a viewer mistake an exploratory visualization for a saved official dashboard? Keep those distinctions visible so that generated analysis does not silently become the product's source of record.

Finally, ask support staff to reproduce a failed or unanswered question. The documentation says historical NLQ questions are not visible, so the pilot must supply an application-owned or manual record of the question, selected context and observed result. Minimize sensitive content in that record. Do not assume a native query-history audit trail will reconstruct the issue for support.

04 / PricingPlan and deployment choices determine the real commercial scope

The plans page separates Self-serve and Enterprise. Enterprise includes deployment options spanning SaaS, dedicated cloud and on-premises, together with higher-control features and a bring-your-own-LLM option. The page does not expose a universal dollar tariff. A quote must therefore match the deployment and customer-facing usage being proposed.

For the logistics pilot, describe the number of customer organizations, expected concurrent activity, data volume and embedding approach. Ask how each affects cost and how AI-provider usage is handled. An inexpensive proof of concept with a few internal users does not establish the cost of a product feature available to every customer during a busy reporting period.

Also price the work around the platform. Semantic modeling, tenant provisioning, identity integration and support training remain real project costs even when the SDK shortens UI development. Separate those implementation costs from the recurring platform agreement so that the team can evaluate whether a second analytical feature becomes easier to deliver.

05 / DistinctionsThe semantic layer can serve both charts and questions

The useful architectural idea is reusing business definitions across conventional analytics and AI query generation. A well-defined delivery metric can anchor a chart, a filter interaction and a natural-language request. This reduces the risk of inconsistent definitions. It does not make the dashboard assistant a root-cause analyst or remove the need to verify the model and interpret its results.

The developer toolkit also changes how analytics can fit the product. A team can place a focused analytical component beside the operational action it informs, instead of expecting users to open a broad dashboard and rediscover the relevant context. That is most valuable when the feature has a specific job, such as investigating a late-shipment cluster before contacting a carrier.

06 / QuestionsAI data handling deserves a feature-specific demonstration

Sisense's AI data-handling documentation says customer data is not used to train models and describes controls that vary by feature. Treat that as a vendor statement to map to the selected configuration. Identify which prompts, metadata and data values reach the configured provider, and how the organization reviews that flow.

Deployment flexibility does not automatically mean every AI operation stays inside the customer's network. The assistant documentation includes cloud-linked setup and provider prerequisites. Ask for the actual request path in the chosen environment before making an on-premises or residency claim to customers. The product owner needs a precise explanation, especially when analytics becomes part of a contractual customer feature.

A clean semantic model is also an ongoing responsibility. If an operational team renames a status or changes how a delivery promise is recorded, the analytics definition may need revision. Include that dependency in the normal software release process. Otherwise a fluent answer can continue using an old definition after the operational product has moved on.

07 / DecisionEvaluate a customer question, not a generic dashboard demo

Sisense is worth evaluating when customer-facing analysis is becoming a maintained part of a software product. Choose a query with a verifiable result and a meaningful permission boundary. Test whether users can generate and inspect useful charts inside the product, then interpret them with appropriate business context, while developers retain control over data definitions and access.