Most BI vendor evaluations focus on features: visualization types, connector library, SQL support, dashboard customization. These matter. But for organizations with occasional users, the structural questions — about pricing mechanics, account provisioning, commitment terms, and what happens when things go sideways — are where the real evaluation happens. A tool can look excellent on features and still be structurally wrong for how your organization uses data.
These six questions are calibrated for the occasional-user buyer. They're not generic evaluation questions — they're the specific things you need answered before you can assess whether a tool's pricing model fits your situation.
Question 1: What Exactly Counts as an Active User in Your Pricing?
On MAU pricing, the definition of "active" determines your bill. Not all vendors define it the same way, and the definition matters significantly when you have automated processes running alongside human users.
Good answer: One login per calendar month constitutes an active user. Automated processes — scheduled report delivery, API calls, data refresh jobs — run as system processes and don't count toward MAU. A user can have an account provisioned without it counting as active until they actually log in.
Warning sign: A vague answer ("it depends on your usage"), a definition that includes any API access, or a definition where scheduled jobs count as user activity. If automated processes consume MAU capacity, you're paying for machine activity at human-user rates — and your MAU count will be unpredictable regardless of how many people actually log in.
DashboardFox: One login per month counts as one MAU, regardless of how many subsequent logins that user has that month. Scheduled jobs run as system processes and don't consume MAU capacity. Provisioned accounts don't count until they're used.
Question 2: Can I Provision More Accounts Than My MAU Limit?
This question gets at one of the most important structural differences between pricing models. On MAU pricing, the value comes from being able to give access to everyone who might need it — because accounts cost nothing until they're used. If you can only provision as many accounts as your MAU tier allows, you've effectively paid for per-seat pricing with a different name.
Good answer: Yes — provisioned accounts are separate from your MAU count. You can create accounts for your entire organization (or client base, or user population) without any of them counting until they log in. The MAU limit governs how many can be active in a given month, not how many can exist.
Warning sign: "You can only have X total accounts" or any answer that ties the number of accounts you can create to your MAU tier. This forces the same rationing behavior as per-seat pricing — you have to deprovision inactive accounts rather than letting them sit idle, which means the same friction and gatekeeping that produces shadow reporting.
DashboardFox: Provisioned accounts are unlimited. Your MAU tier governs how many users are active in a given month — not how many accounts exist. You can provision your entire organization without any cost until they actually log in.
Question 3: What Happens When I Go Over My MAU Limit?
Overage behavior is one of the most practically important questions for seasonal or growing organizations. If an unexpectedly high-usage month triggers a hard stop — users can't log in until you upgrade — that's an operational crisis. If it triggers a graceful add-on, it's a minor billing event.
Good answer: Overage is handled via add-on blocks that activate automatically when you exceed your tier limit. There's no service interruption. You get billed for the additional active users at a defined rate. You can review the overage at billing and decide whether to upgrade your tier for the next period.
Warning sign: A hard cap that cuts off logins when the limit is reached, punishing overage rates (more than 1.5–2x your per-MAU tier rate), or a vague "contact us" answer that suggests the vendor will try to renegotiate rather than handling it programmatically. Any of these makes budgeting unpredictable and creates operational risk around high-usage months.
DashboardFox: Overages are handled via +10 MAU add-on blocks at $49/month (or $39/month annual). No hard caps, no service interruption. You can add blocks as needed or upgrade your tier at renewal.
Question 4: Is There an Annual Commitment Requirement?
Annual contracts are standard in enterprise software, and they're not inherently a problem — but they need to be evaluated carefully for organizations that are still discovering their actual usage patterns or might need to change tools. The question isn't just whether annual billing exists, but what the exit terms look like if you need to leave early.
Good answer: Monthly billing is available, or the annual discount is clearly stated with a reasonable early exit clause — not "contact sales." You can evaluate the tool on month-to-month terms initially and lock in the annual rate once you've validated that it fits.
Warning sign: Forced annual commitment on all plans with no monthly option, a vague or punishing early exit clause, or pressure to commit annually before you've had a meaningful trial period. Any of these dramatically increases the cost of being wrong about the tool selection.
DashboardFox: Month-to-month billing is available on all plans with no long-term contract required. Annual billing is available at a 20% discount for organizations that want to lock in the lower rate.
Question 5: What Does the Trial Actually Give You Access To?
Trial quality varies enormously. Some trials give you full feature access with a real database connection — you can evaluate every capability the tool offers against your actual data. Others give you a sandbox with toy data, limit the features available, or require a sales conversation to unlock anything meaningful. A trial you can't use for real evaluation isn't really a trial.
Good answer: Full feature access — including row-level security, SQL, scheduled delivery, and any white-label features — with the ability to connect your actual database. No artificial restrictions on which features you can test. Enough time to build a realistic workflow and evaluate it properly.
Warning sign: Trial limited to sample data only, key features withheld until you're on a paid plan, or a short window (fewer than 7 days) that doesn't give you time to build and test anything meaningful. If the vendor won't let you evaluate the full product with your real data, they're betting you'll commit before discovering the limitations.
DashboardFox: The 7-day free trial includes full feature access — RLS, SQL, custom domains, scheduled delivery — with the ability to connect your own database from day one. A self-service 7-day extension is available if you need more time, no contact required.
Question 6: What Happens to My Data If I Stop Using the Tool?
This question is asked less often than it should be, and it gets more important the longer you've been with a vendor. Report definitions, dashboard configurations, semantic layer setups, user permission structures — these take time to build and should be exportable when you decide to move on.
Good answer: Data export is available at any time, not just during an offboarding window. Report definitions and configurations can be exported in a portable format. There's a documented offboarding process, not a support ticket that takes weeks to resolve. No fees for exporting your own data.
Warning sign: Data held until a specific request is processed, export only available during a narrow offboarding window, fees for data export, or no documented process at all. Vendors that make offboarding hard are either struggling financially (and may be bought or shut down) or deliberately creating switching costs.
DashboardFox: Data export is available at any time. Report configurations and dashboard definitions can be exported. There are no data export fees and no locked offboarding process.
Start a free 7-day trial — no credit card required. Connect your own database and test every feature on this list before you commit to anything.
Why These Questions Do the Work
A vendor that answers all six questions clearly — good definition of active users, unlimited account provisioning, graceful overage, flexible commitment, full trial access, clean offboarding — has structurally designed their product for the occasional-user scenario. The answers tell you as much about the vendor's orientation as the features do.
A vendor that hedges, deflects to sales, or gives warning-sign answers to multiple questions is telling you something important: their product wasn't designed for your usage pattern, and the contract terms reflect that. That's a signal worth taking seriously before you sign anything.
What should I ask a BI vendor before signing?
For organizations with occasional users, the six most important questions are: (1) What exactly counts as an active user in your pricing? (2) Can I provision more accounts than my MAU limit? (3) What happens when I go over my MAU limit — hard stop or soft add-on? (4) Is there an annual commitment requirement, and what does early exit cost? (5) What does the trial actually give you access to? (6) What happens to my data if I stop using the tool? These questions surface the structural pricing and contract details that most vendor demos don't cover.
How do I evaluate BI software for occasional users?
Start by pulling 90 days of login data from your current tool to understand your actual active-user count versus your provisioned account count. Then evaluate new tools specifically on: whether they charge per provisioned account or per active user, whether you can provision broadly without each account being a cost decision, and whether the MAU definition excludes automated jobs. Run the trial with your actual data, not a sandbox, and verify that your expected active-user count produces a realistic cost at the tier you're considering.
What are the hidden costs of BI software?
The most common hidden costs in BI software are: overage charges when active users exceed the tier limit, feature gating where capabilities like row-level security or SQL access require a more expensive tier, annual commitment lock-in that prevents switching without penalty, implementation costs when the tool requires specialist configuration, and data export fees or hostage data policies when offboarding. For occasional-user organizations, overage behavior is particularly important — a hard cap that cuts off service is much more disruptive than a graceful add-on overage model.
