Custom Dashboard Cost: What Are You Paying For?

Custom dashboard cost depends on whether you are paying for a screen, a reliable way to prepare the figures, or both. A quote might cover charts and filters while leaving staff to export spreadsheets, correct records and reconcile totals every week.

A useful estimate needs to separate the reporting interface from the work behind it: connecting systems, defining figures, controlling access, testing results and keeping updates running. A headline price range would obscure those differences rather than help you compare suppliers.

Before paying for a custom interface, confirm the two or three decisions it must support and whether the underlying figures agree with the systems staff already use. If those figures are disputed, agreeing their definitions may be the first useful deliverable.

First decide whether you need a custom dashboard

Start with a decision rather than a list of charts. “See sales performance” is too vague to scope. “Decide which overdue accounts need chasing” tells a supplier much more: someone needs an outstanding balance, a due date, a customer contact and a route to the relevant invoice.

Write down who will use the view, what they need to decide and what they will do afterwards. Then check whether an existing CRM report, invoicing report or business intelligence tool can support that work. A business intelligence, or BI, tool turns prepared data into reports, charts and interactive views.

I would test the most important decision in an existing reporting tool before commissioning a custom interface.

A BI-tool implementation is a sensible starting point when staff mainly need to filter, compare, drill into and export figures. A custom interface becomes more plausible when users must perform specific business actions, work through an unusual process or access reporting inside an existing customer-facing service. Those requirements should be demonstrated, not assumed.

Separate the interface decision from the data decision. You may need custom connections and preparation behind a standard reporting tool. Equally, a custom-built screen can still depend on manual spreadsheets.

What a dashboard quote should separate

Agreeing what each figure means

“Sales this month” could mean opportunities marked as won, invoices issued or payments received. Each answers a different question. The quote should allow for agreeing definitions, identifying the authoritative source and deciding how cancellations, credits and late entries affect the totals.

This work needs a business owner who can settle disagreements. A developer can implement a definition, but should not silently decide what your business means by revenue.

Connecting and preparing the data

Ask which systems, records and fields are included, and how they will be accessed. A ready-made connector still needs checking against the actual information required. Historical imports, inconsistent customer names and records without a matching customer identifier can add work.

Data modelling means organising those records so they can be combined and calculated consistently. For example, one customer may have several opportunities, invoices and payments. Joining those records incorrectly can count the same invoice more than once.

This preparation belongs in the scope of the data systems supporting the dashboard, whether the visible report uses a BI tool or a custom interface. Ask explicitly which manual export, cleaning and matching tasks will disappear, and which will remain.

Building the views and controlling access

Charts are only part of the interface scope. Filters, invoice-level detail, exports, mobile layouts and actions such as assigning a follow-up all need defining.

Access requirements also change the work. A company-wide summary differs from a view where each salesperson can see only their own accounts. Specify who can view details, export records and administer access, including how access is removed when someone leaves.

Updating, testing and supporting the result

Choose update frequency from the decision being made. A morning planning report may not need continuous updates; a team allocating work during the day may need fresher information. More frequent updates can introduce additional connection, processing and monitoring requirements.

The quote should define what happens when an update fails. Does the dashboard show the last successful update time? Who receives an alert? Can the failed import be rerun without creating duplicate records?

Testing should compare agreed sample periods and individual records with the source systems, rather than merely confirm that charts appear. Handover should identify who owns the calculations, who checks discrepancies and who maintains connections after launch.

Worked example: sales figures from a CRM and invoicing system

Consider an illustrative business that combines CRM opportunities and invoices in a spreadsheet each week. The owner wants to decide which deals need attention and which unpaid invoices need chasing. Assume staff need internal access and that a morning update is sufficient.

The first disagreement is predictable: the CRM's won-deal total does not match invoiced sales. A won deal may not yet have been invoiced, and an invoice may later have been credited. The useful first step is to define separate measures, such as won deal value, invoiced value and outstanding invoice balance, with an agreed date basis for each.

Option one: implement a BI report

The work would include connecting both systems, matching customers, calculating the agreed measures and building views that link totals to underlying records. Staff could review overdue invoices and then open the invoicing system to take action.

For the stated requirements, I would start here. It keeps the interface work limited while addressing the manual preparation. It still requires testing, access configuration, licences where applicable and someone responsible for failed updates.

Option two: build a custom interface

The same connection and reconciliation work remains. In addition, the team builds and maintains the interface, its filters, user access and any business actions.

The recommendation could change if staff must assign debt-chasing tasks and write notes back to the CRM from the same view, and the existing tools cannot support that workflow satisfactorily. Before building, test those exact actions in the available tools. A preference for different colours or chart layouts is a much weaker reason to take on a separate application.

Whichever option you choose, a failed invoice import must not make an old balance look current. The person responsible for reporting needs a visible warning and a recovery process. For more on those controls, see how to automate reporting without unreliable numbers.

Compare the ongoing costs as well as the build

For a BI implementation, check author and viewer licences, connector charges, hosting where relevant, support and future report changes. Microsoft's Power BI licensing guidance distinguishes free access from Pro sharing and collaboration features, with available options depending on organisational settings. Do not assume a development quote includes the licences needed by everyone who will use it.

For a custom interface, check hosting, monitoring, backups, software maintenance and support. Building your own interface does not automatically remove licences or service fees elsewhere in the system.

Ask both suppliers what happens when a source system changes its fields or connection method. Separate fixing a defect in the delivered work from adapting it to a later change, and establish who will own the accounts, code and documentation.

A short brief for comparable dashboard quotes

Send each supplier the same requirements and ask them to mark each item as included, excluded or dependent on further investigation:

• Decisions and sources: the decisions users must make, the systems involved, required history and current manual preparation.
• Figure definitions: calculations, date rules, authoritative records and the person who approves them.
• Updates: required frequency, visible freshness information, failure alerts and recovery arrangements.
• Views and access: filters, record-level detail, actions, exports and what each user group can see.
• Acceptance testing: sample records, periods and exceptions that must reconcile before sign-off.
• Ongoing ownership: licences, hosting, monitoring, documentation, support and responsibility for source-system changes.

Ask suppliers to price data preparation separately from the interface wherever practical. If access or data quality is uncertain, a bounded investigation can establish those facts before a larger build is agreed.

The useful comparison is the cost of delivering the same reliable reporting process, including the work your staff will still have to do. A cheaper screen is not necessarily a cheaper replacement for the weekly report.