Products

ODD: on-demand dashboards with a reviewable data story

A fast dashboard is useful only if the audience understands the information behind it. Uploaded files may contain ambiguous dates, mixed units or several definitions of the same measure. Those issues deserve attention before a chart becomes evidence for a decision.

Overview

ODD, On-Demand Dashboards, is a product for turning supported files or connected data into interactive reporting views. Evaluate it using a defined management question and a dataset whose meaning the team can explain.

01

The workflow to evaluate

01

Select the source

Confirm supported file types or live connectors and the information the user is authorised to process.

02

Check the interpretation

Review columns, dates, units and relationships before accepting generated measures.

03

Explore the dashboard

Use drill-down and follow-up questions to inspect the records behind a result.

04

Validate and share

Reconcile important figures and confirm access, refresh and export behaviour for the intended audience.

FI Digital UK / Workflow

ODD

Illustrative workflow, not a product screenshot or a claim about a client’s production architecture.

Step 5 of 5Resolve with the owner (Needs correction)

Keep scrolling to follow the flow

  1. Select the sourceConfirm supported file types or live connectors and the information the user is authorised to process.
  2. Check the interpretationReview columns, dates, units and relationships before accepting generated measures.
  3. Review and authoriseDecision point
  4. Validate and shareReconcile important figures and confirm access, refresh and export behaviour for the intended audience.
  5. Resolve with the ownerOutcome: Needs correction
02

A practical example

Illustrative evaluation: an uploaded file contains booked revenue and cash receipts. The dashboard should not combine them as one measure without a clear definition, even if both columns contain monetary values.

03

Questions that shape the scope

Use these questions to identify the first decision and the information needed to make it.

  • Which sources and sizes are supported?
  • How are measures interpreted?
  • Can a result be reconciled?
  • What permissions apply to sharing and connectors?
04

Make the UK operating requirements explicit

Separate the UK organisation’s requirements from any wider group template. Identify the legal entity, business owner, connected accounts and the people authorised to accept the result. If the workflow relies on financial or employment rules, your qualified advisers should confirm the applicable settings and obligations; software configuration alone does not establish compliance.

05

From assessment to an accepted result

01

Choose a representative task

Bring one workflow and an example of an acceptable result, using synthetic or approved material.

02

Review the current product

Confirm supported features, dependencies, permissions and commercial availability for the intended deployment.

03

Run a bounded evaluation

Check ordinary cases, exceptions and human handoffs. Record limitations and unresolved requirements.

04

Agree production responsibilities

Confirm provisioning, support, information handling and the acceptance decision before rollout.

06

Scope and responsibilities

Confirm the current product version, local availability, supported integrations and information-handling arrangements in the walkthrough. No universal price, hosting location or service level is implied.

FAQ

Frequently asked questions

001Can ODD replace our governed BI platform?

That depends on the reporting requirements, controls, refresh needs and scale. An on-demand exploration tool and a governed enterprise reporting platform can serve different purposes. Evaluate access, definitions, reconciliation and ongoing operation before deciding whether the product should complement or replace an existing reporting workflow.

002How do we check a generated dashboard?

Start with known totals and a small set of representative records. Confirm dates, units, filters and the definition of each important measure. Inspect a drill-down where available and compare the result with the approved source. A visually convincing chart should remain a candidate for review until its underlying interpretation is accepted.

003How can we assess whether the product fits our process?

Bring a representative task, the people involved and an example of an acceptable result. Use synthetic or approved redacted information for the first walkthrough. Ask to see ordinary work, exceptions and the handoff to a person. A demonstration should establish current functionality and prerequisites rather than treating a roadmap item as an available feature.

004Is the product available in our market?

Confirm the current commercial offer for your organisation, including contracting entity, supported applications, provisioning and support arrangements. A group product description does not establish identical availability in every country. The walkthrough should identify the supported version and any regional provider requirements before you purchase subscriptions, connect accounts or plan a production rollout.

005What determines product pricing and implementation cost?

Request a written quote for the current version and intended usage. Separate the product subscription from setup, third-party licences, model or channel usage and any custom work. Include onboarding and ongoing support responsibilities. Published examples should not be treated as a binding offer for a different market, configuration or transaction volume.

006How is business information handled?

Review the actual data flow for the selected deployment: what is read, where it is processed, who can access it and how it is retained or removed. Include connected model and platform providers where relevant. Agree the appropriate information-handling terms before production use; a product name alone does not establish a hosting region or certification.

007Can the product be connected to other applications?

Confirm each required connection and action against the current product, supported editions and provider permissions. A possible custom integration is different from an included feature. Test authentication, identifiers, error handling and the resulting records before relying on the connection, and identify who maintains it when the product or the external application changes.

008What should be agreed before going live?

Confirm the accepted use case, accountable owner, permissions, support route and procedures for errors or unavailable dependencies. Complete a representative pilot and document its limitations. Agree who can approve changes to the workflow and connected accounts. The production decision should follow evidence of fit, rather than relying only on a polished demonstration or a general product description.

Request a product walkthrough

Request a product walkthrough→

Tell us about your project

Include your country code.
Tell us about the process, system or business problem you want to solve. Please do not include confidential records.

We use the information you provide to respond to this enquiry. Read our Privacy Policy.

Book a Call