How do you build an event dashboard for different team roles?

Your sales lead says the event has sold 320 tickets. Finance says you're working with $18,000 of ticket charges. The door manager is preparing for 320 valid admissions. Those numbers might all be right. The problem starts when everyone assumes they're describing the same thing and makes a decision from the wrong total.

To build an event dashboard for different team responsibilities, agree on the underlying definitions first, then create a small view around each person's decisions. Sales needs to know what can still sell. Finance needs to understand money, obligations and payment timing. Operations needs the current admission position and exceptions. Each view should show its scope, update time and the person who acts when something needs attention.

You don't need to squeeze every department onto one screen. You do need a way to explain how their figures relate. Otherwise, a dashboard meeting becomes another conversation about whose spreadsheet is correct, while a supplier deadline or ticket opportunity passes.

This guide walks through that design using one invented paid event. You'll see what belongs in each view, how to keep shared measures consistent, and how to test the result before your team relies on it. The figures illustrate the decisions. They aren't industry benchmarks or a claim about a platform's reporting format.

Start with the person who has to make a decision

The first thing you want to do is ask each person what they need to decide next. Avoid starting with a list of every available chart. Your finance lead might need to approve a production payment. Your sales lead might need to find out whether another ticket release is available. Your door manager might need to investigate rejected scans at one entrance.

Those questions tell you what the dashboard must make visible. A cumulative sales line won't tell finance whether money will reach the bank before an invoice falls due. A gross ticket count won't tell the door team how many cancelled tickets remain in an old download. The right number depends on the action.

Ask the person to describe a recent decision in ordinary language. What did they need to know? Which source did they trust? What did they check elsewhere? Who could approve the next step? The answer often reveals that a useful view needs a deadline or exception list more urgently than another percentage.

For example, the person handling supplier payments might say, "I need to know what we owe before Friday and what money is actually available to pay it." That becomes a view of dated obligations and available funds. It doesn't become a large sales total with a green arrow.

The UK Government Digital Service's guidance on using performance data connects measurement with understanding performance and deciding what to improve. Its public-service measures aren't event targets. The useful principle here is choosing information around a real task, then using it to change something.

Keep a separate record of interesting questions that don't affect the next decision. You may want to compare audience segments after the event, but that shouldn't delay a working payment view. Build the first version around decisions your team already makes, using records your systems already maintain.

Agree on the facts every view shares

Different responsibilities don't justify different meanings for the same label. If sales and finance both display valid paid tickets for the same event and cutoff, the figures should agree. If one displays tickets originally issued and the other displays tickets remaining after cancellations, their labels should explain the difference immediately.

Start with the event itself. Record the dated performance, reporting currency and relevant time zone. A programme running every month needs a separate event reference for each date. A filter for the whole series shouldn't quietly replace the selected performance when someone opens a saved link.

Then agree on the few shared measures that appear across views. These usually include original paid tickets, currently valid paid tickets, complimentary admissions and a clearly named ticket-money measure. Our guide to event KPIs and metrics explains the wider choice of measures. Here, the job is making the selected measures usable by different people.

Write the definition somewhere the reader can open from the dashboard. For valid paid tickets, specify which admission statuses qualify, how cancellations work and which cutoff applies. For money, say whether the amount includes discounts, refunds, fees and taxes. A label such as net revenue invites too many interpretations unless the calculation is available.

You also need the source and the person responsible for the definition. Finance should approve a money calculation. Operations should approve an admission calculation. Whoever builds the view can implement both, but they shouldn't have to guess your business rules from the names of export columns.

Keep source facts separate from calculated measures. A completed refund amount comes from a financial record. Ticket charges after completed refunds combines original charges with those refund records. That distinction helps you locate a disagreement. You can check whether a refund is missing before arguing about the display.

When the underlying records already need repair, deal with that first. The process for cleaning ticket sales and attendance data covers duplicates, statuses and comparisons. A new dashboard won't repair a missing refund or make two incompatible ticket categories equivalent. It can only make the resulting mistake easier to repeat.

Work through one event before choosing a layout

Imagine an event called Studio Forum. All money in this example is USD. It has an approved allocation of 500 guest tickets, established within the event's wider capacity arrangements. The overall capacity arrangements separately account for crew and other people covered by the safety plan. The guest-ticket allocation alone does not measure safe occupancy.

At the example's 7:30 p.m. ticket-data cutoff, 320 paid tickets were originally issued at $60 each. Twenty have been fully refunded and cancelled. There are 300 currently valid paid tickets and 20 valid complimentary tickets. No other ticket issues, cancellations or replacements affect these totals.

So original paid tickets are 320, valid paid tickets are 300, and valid guest admissions are 320. The same number, 320, describes two different populations. That's exactly why a large tile called tickets can create confusion even when its arithmetic is correct.

Of the 180 places not assigned to valid tickets, 30 are held off sale for an agreed allocation. That leaves 150 currently available for purchase. For this example, cancelled tickets have returned to inventory and all ticket groups draw from the same 500-place allocation. Your own platform's inventory and release rules need checking before you use the calculation.

Original ticket charges are $19,200. Completed refunds total $1,200, leaving $18,000 of ticket charges after refunds. Assume the event bears a further $960 of actual charges recorded in its payment records. That leaves $17,040 after those particular deductions. Use your actual recorded charges when applying this example; the $960 is invented, not a provider fee quote.

Of that $17,040, $12,000 has reached the bank and $5,040 awaits payout. This simplified payment example excludes taxes, disputes, reserves, other income and other balance adjustments. It also isn't a profit calculation. Supplier costs still have to be considered, and the bank's remaining spendable balance may be lower after previous payments.

Build these relationships into your acceptance checks before discussing colours or charts. Ask each team member to explain the same event using their proposed view. If finance thinks $18,000 is bank cash, or sales thinks all 180 unassigned places are available for purchase, you've found a design problem worth fixing early.

Build the sales view around the remaining selling job

The sales view should help its reader decide what to do about demand and available inventory. Start with valid paid tickets against the relevant sales plan, current availability by ticket type, and sales over a meaningful recent period. Keep original issues and cancellations available as supporting detail.

For Studio Forum, suppose the agreed plan called for 400 valid paid tickets by this point. The current 300 leaves a gap of 100 against that plan. Label it as a plan gap. It isn't proof that another 100 buyers exist, and it doesn't authorise releasing held tickets or increasing capacity.

The available-for-purchase figure is 150, while another 30 places remain held off sale. Show the hold's purpose, owner and release decision. A sales lead can then ask the right person whether the hold is still needed. They shouldn't infer from spare headline capacity that every place can be sold immediately.

If ticket types have different entitlements or prices, show the availability within those actual groups. A premium ticket that includes a limited workshop can't necessarily replace a standard ticket. Your view should make that restriction clear enough that a campaign doesn't promise an offer the event can't fulfil.

Show sales pace in a way that can support a comparison. Use a stated period and separate new paid issues from cancellations. If you display net additional valid paid tickets, make the calculation visible. A day with strong new orders and many cancellations needs a different investigation from a day with few purchases.

Keep the money consequence close enough to examine. Selling more low-price tickets can improve headcount while leaving income short. The reader should be able to check ticket mix, realised ticket charges and relevant selling costs before proposing another offer. Avoid a headline percentage that turns every discounted booking into an unquestioned success.

Channel results need their own limits. A report of attributed sales shows the purchases credited under that source's rules. It doesn't establish that those purchases would disappear without the channel. Don't add overlapping claims from several advertising systems and call the result total sales. Completed orders remain the check on the event's overall selling result.

For this view, a useful action record might read, "Sales are 100 valid paid tickets below the current plan. Priya will review available standard inventory and the unanswered buyer questions before proposing a change. The 30-place hold stays closed until its owner decides." That is specific enough for the next conversation without pretending a chart can choose the promotion.

Give finance the amounts and dates needed to approve spending

Finance needs to move from ticket activity to money available, then compare that money with obligations. Put the different amounts on separate lines with names that describe their basis. Studio Forum's $18,000 after ticket refunds, $17,040 after the example's recorded payment charges, and $12,000 paid into the bank answer different questions.

The dashboard should let an authorised person follow an amount back to its supporting report. If a payout includes several events, a bank deposit alone won't establish what belongs to Studio Forum. Match its underlying transactions to the event before presenting an event-specific receipt. Don't allocate the full deposit to whichever performance the dashboard happens to display.

Stripe's payout reconciliation documentation describes matching automatic payouts with the payments and other transactions they settle. It also distinguishes that reporting from the balance-report approach used for other arrangements. Check the process that applies to your payment setup rather than assuming every payout identifies one event or one day's sales.

Now add payment obligations. Suppose the event has $9,000 of supplier balances due tomorrow and only $7,000 of confirmed, uncommitted bank funds available for them. Those are additional invented facts, taken from the example's obligations and bank records after earlier payments. They don't follow simply from the $12,000 cumulative payout total.

There is a $2,000 immediate gap. The $5,040 not yet paid out could cover it only if enough becomes available before the deadline and no other restriction applies. Until timing is confirmed, keep it separate. Otherwise the dashboard can tell the team it has enough money while the person making the payment still cannot complete it.

A dated obligations list makes that payment decision easier to check. Record the supplier, amount, due date, payment status and owner. Show deposits already paid separately from balances remaining on the same contract. You need the full committed cost for the forecast, but you shouldn't add the deposit again when calculating what remains to pay.

Keep estimates and confirmed amounts distinguishable. An unsigned sponsor conversation can't become available funds because someone entered a likely amount. An expected invoice can belong in the forecast with a clear status. Finance needs to see what is known and what could change before approving another commitment.

The dashboard can link to the detailed event cash-flow forecast when timing needs more explanation. The front view should show the next payment decision, its current funding position and who will resolve a shortfall. It shouldn't try to replace the accounting records or squeeze every financial calculation into a single event total.

For Studio Forum, the action is to confirm payout availability or agree another authorised way to meet the supplier deadline. It isn't to tell marketing to spend the remaining ticket income. Access to a financial view doesn't grant spending authority, and a favourable event forecast doesn't remove a payment restriction.

Design the operations view for the next operational action

Operations needs information that helps the team deliver the event now. Before doors, that can mean readiness, valid admissions by entry entitlement and unresolved access issues. During entry, it can mean accepted admissions, queue observations and exceptions needing the door lead. Afterward, it can mean unfinished incidents and the evidence needed for review.

Keep the current ticket position visible. Studio Forum has 300 valid paid tickets and 20 valid complimentary tickets at the stated cutoff. Door staff need the supported current admission process for those tickets. They shouldn't use the historical count of 320 original paid tickets as though every original credential remains usable.

For the same example cutoff, assume 240 paid tickets and 10 complimentary tickets have recorded a first accepted admission. Total recorded first admissions are 250. There are 70 valid tickets without a recorded first admission, split into 60 paid and 10 complimentary. That doesn't mean all 70 people are standing outside or will attend later.

Now suppose the scan activity contains 263 attempts. Of those, 250 produced the first accepted admissions, five were permitted re-entry scans and eight were rejected attempts. The activity count is useful for diagnosing the entry process. It isn't 263 different attendees. One person can generate more than one attempt.

The operations view should let an authorised door lead examine the eight rejected attempts by reason. Repeated use, cancellation and a device problem call for different responses. A headline failure rate can suggest that scanning has broken when the system is correctly rejecting an invalid credential. Keep enough detail to identify the actual problem without exposing everyone's booking to the whole team.

Recorded first admissions also aren't current occupancy. People can leave and return, and staff or other authorised groups may be counted through another process. Use the entry, exit and occupancy arrangements in your approved safety plan. A ticket dashboard can supply relevant facts; it mustn't label a cumulative scan count people inside when it doesn't measure that.

Include observations the digital records don't provide. The door lead may need a current queue report from a particular entrance, a confirmed equipment fault or an unresolved accessibility issue. Give each observation a time, location and responsible person. A fast average scan time doesn't establish that every entrance is working well.

Don't make staff complete a complicated reporting task while attendees wait. Use the admission tools for their existing job and keep supplementary updates short. Agree which situations need a direct call rather than a dashboard update. An urgent issue should reach the person able to respond even if nobody is looking at the reporting screen.

For Studio Forum, the useful operations action might be to investigate a cluster of rejected attempts at the west entrance while another team member checks the queue. It wouldn't be to increase ticket availability because only 250 first admissions have been recorded. The unsold allocation, valid admissions and people currently inside are different questions with different owners.

Make filters and update times impossible to miss

A dashboard can contain the right calculations and still mislead people because it opens on the wrong scope. Display the selected event, date range, currency and relevant time zone near the figures. If a filter changes a major total, show the filter alongside that total rather than hiding it inside a menu.

Defaults deserve particular care. Someone opening the door view during Studio Forum shouldn't unknowingly see last month's performance because that was their previous selection. Someone comparing the series shouldn't assume the current event's payment timing applies to every edition. Test saved links and returning visits, not just the first clean opening.

Show when the underlying information last updated successfully. A page loading now doesn't establish that the payment records behind it are current. Where sources update separately, show their separate timestamps. Studio Forum's ticket cutoff can be 7:30 p.m. while the bank position comes from an earlier confirmed check. Label both honestly.

The UK's Government Data Quality Framework treats timeliness as suitability for the intended use and discusses trade-offs between quality dimensions. That is useful here because the same delay can be harmless for a monthly comparison and unacceptable for an admission decision. Choose freshness around the job rather than calling every view real time.

Agree what happens when an update fails. Keep the last successful time visible and say which information may be incomplete. Don't replace an unavailable amount with zero. Don't leave a healthy status that only means the page loaded. The reader should know whether they can proceed, use the original source or wait for verification.

A sales review may continue using a clearly dated snapshot while someone restores reporting. The door should use its supported admission process and agreed contingency arrangements. Finance may postpone an approval if the available-funds position cannot be confirmed. A single dashboard failure doesn't require the same response from every team.

Record who checks a freshness problem and how it reaches them. If the person noticing stale information must ask around to find its owner, the warning is incomplete. The view should explain the limit and the next action in words the team can understand without contacting whoever built it.

Share the right amount of detail with each role

A different view isn't automatically a different permission level. Hiding a financial tile from a page won't protect its data if the same account can open the underlying report or download everything. Check the actual access controls available in your tools before promising that a role sees only what its layout shows.

Start with the task. A sales lead usually needs results and inventory, not every attendee's phone number. A door manager needs enough booking information to resolve an admission issue, not the event's supplier contracts. Finance may need transaction references and controlled supporting records without needing sensitive notes about an attendee's access requirements.

Under the UK GDPR, the Information Commissioner's Office explains that personal information should be limited to what the purpose needs. Its guidance is currently marked as under review following legislative changes. Check the requirements applying to your organisation; the practical dashboard question is why this particular person needs this particular information for their job.

Treat shared screens and exports as access decisions too. A view projected in a production room can be visible to suppliers and temporary staff. A downloaded file can survive after someone's account access ends. Use summary counts where they answer the question, and keep individual records in a controlled view for authorised investigation.

Test access with the actual role. Can the user open a restricted link, alter the event filter to see another performance, export details or change a source setting? A manager viewing the dashboard through an administrator account won't tell you what door staff can really do. Confirm both the intended task and the limits.

Decide when temporary access ends and who removes it. Keep the dashboard's retained detail aligned with your existing retention rules. A useful after-event summary doesn't require preserving every operational note in a widely shared report. Keep the evidence needed for its proper purpose in the appropriate controlled record.

Put a named response behind every warning

A red number doesn't tell someone what they're allowed to change. Write the response behind each warning before adding it to the view. Identify the condition, the first check, the person responsible and any approval needed. That keeps a sales shortfall from becoming an automatic discount or a cash warning from becoming an unauthorised supplier commitment.

Studio Forum's 100-ticket plan gap is a prompt to investigate demand, the offer and availability. Its $2,000 immediate cash gap needs a funding or payment-timing decision. Its rejected scan attempts need operational diagnosis. Those conditions shouldn't share a generic event at risk label, because they require different evidence and different people.

Set any numerical warning level from your event's plan, obligations and operating arrangements. Don't borrow a universal percentage because it produces a tidy traffic-light display. A small cash shortfall before a non-negotiable deadline may need attention sooner than a much larger forecast variance that still has time to be resolved.

A useful warning says, "Confirmed available funds are $2,000 below supplier payments due tomorrow. Finance is checking whether the pending payout arrives before the deadline. Additional discretionary commitments require approval." It tells the team what is wrong and what happens next without pretending that expected money is already available.

Record the response after somebody acts. If a hold is released, note who approved it and when. If finance arranges another payment date, update the obligation rather than leaving yesterday's warning indefinitely. The dashboard should reflect the resulting position while preserving enough history to explain the decision later.

Avoid alerting the entire team whenever a small number moves. Send the condition to the person who can assess it, with escalation when they cannot resolve it or the decision deadline approaches. If everyone receives warnings that never require action, an important one becomes harder to recognise.

Write a dashboard brief someone else can build

You can use the following brief for each view. Complete it with the person who will use the result, then ask whoever maintains your existing reporting tools to confirm what they can supply. It works whether the result is a platform report, a controlled spreadsheet view or a separate reporting page.

• User and decision. Who opens this view, and what choice should they be able to make?

• Scope. Which dated event, reporting period, currency and ticket groups does it cover?

• Main measures. What does each figure mean, which source supplies it and how is it calculated?

• Supporting detail. What can the authorised user inspect when a figure needs explanation?

• Freshness. When does each source update, and what happens when it is too old for this task?

• Response. Which condition needs attention, who checks it, and what changes require approval?

• Access. Who may read, investigate, export or change the information?

• Acceptance. Which known cases must produce the right results before the view is approved?

Here's a completed example for Studio Forum's payment view. Its user is the finance lead, and its decision is whether tomorrow's supplier balances can be paid. It covers this event's dated obligations and the money confirmed available to meet them, in USD. Cumulative ticket charges and payouts provide context, with their definitions available separately.

The main result is $9,000 due against $7,000 available, leaving a $2,000 gap. Supporting detail includes the supplier balances, their deadlines and the bank check. The $5,040 awaiting payout remains separately labelled until availability is confirmed. Finance owns the response and checks the position before approving the payment or another commitment.

The acceptance case is deliberately awkward. Show a healthy ticket-income total while keeping available funds below tomorrow's obligations. Ask the user what they would approve. If they answer that the event can pay simply because ticket charges are $18,000, change the view's wording or hierarchy before it becomes a real decision tool.

Make the screen understandable without its author present

Arrange each view in the order the user reasons through the decision. Show the condition needing attention, the relevant comparison and then the supporting breakdown. Keep definitions and records accessible without asking someone to read a long explanation every time. The first screen should help them begin the task.

Use a chart when it clarifies a relationship. A sales line can show pace over time, provided the dates and measure remain consistent. A list works better for supplier amounts with different due dates. Operations may need exceptions grouped by entrance and reason. Choose the format that helps that person find the answer.

Don't rely on colour alone. Label the condition directly, include the amount or count and explain what it means. The World Wide Web Consortium's guidance on complex images explains providing text alternatives that communicate a chart's essential information. Apply that principle when a dashboard's conclusion would otherwise be available only through its graphic.

Check a narrow screen, a shared display and the actual environment in which the view will be used. A detailed chart that reads well at a desk can be awkward at the door. Make the event selection and update time readable wherever a person might act on the figures.

Be careful when someone takes a screenshot. It loses live filters, definitions and later updates. Include enough context for the captured view to identify its event, scope and cutoff. When a decision requires the current position, direct the team back to the supported source rather than circulating an old image as a live report.

Use the reporting your platform already supplies

Before commissioning a separate dashboard, check the reports and team access you already have. Rebuilding ticket counts elsewhere creates another place to maintain definitions and updates. A new view is justified when it answers a specific unmet question, such as bringing approved supplier obligations into a payment decision.

Loopyah ticketing provides sales-by-source reporting, team access and QR check-in by door staff. Those capabilities let the relevant people use the records already supporting ticket sales and entry. Check the supported role permissions for your event before deciding who should receive access.

Where the job spans ticketing and entry, Loopyah event software keeps the order, sold count and door list connected. Start with those supported workflows rather than asking someone to manually rebuild every booking relationship. Your team still has to explain its reporting definitions and include external obligations where those affect a decision.

Confirm the support for any custom layout, financial restriction or external data connection before planning around it. A view of transactions and a company-wide spending approval process are separate things.

Decide what changes when the event finishes

A view designed for action during entry needs a different treatment after the event. The door lead no longer needs a constantly changing queue report, while finance may still be waiting for invoices or payment adjustments. Keep the relevant operational history available without presenting yesterday's conditions as current warnings.

Set a reporting state that readers can recognise. During sales, the figures describe the latest available position. In an initial review, they may be provisional because particular items remain unresolved. In the final financial review, confirm what has been completed and list anything still excluded. Don't use final as a filename someone chose because they wanted to stop editing.

Preserve the position used for a material decision. Suppose the sales lead requested release of Studio Forum's 30 held places. Keep the request, the inventory position at the time and the authorised decision. A later dashboard may correctly show different availability. The earlier record explains why the team acted without requiring anyone to remember which filter was selected.

The same applies to finance. If a payout arrives after the supplier deadline, the current view should reflect its arrival. That doesn't mean yesterday's cash warning was wrong. Preserve enough of the earlier position to explain the timing and the action taken. Avoid rewriting history so the latest outcome appears to have been known all along.

Resolve a disagreement by comparing scope first

When two people disagree, ask them to open the definition, filters and cutoff before changing a calculation. For Studio Forum, one person may be discussing 320 original paid tickets while another means 320 current guest admissions. Their equal totals can hide different meanings just as easily as unequal totals can create an argument.

Compare the same named measure at the same cutoff. If those still disagree, trace a known booking through each view. Check whether a cancellation, held allocation or source update explains the difference. Ask the responsible source owner to resolve it, then record the correction and the decisions that may need reconsidering.

Don't make the dashboard agree by changing a definition locally. If operations excludes a ticket category that finance includes, find out whether the views serve different purposes or one is wrong. Where the distinction is legitimate, label it. Where the shared rule changes, apply the approved definition to every affected view and tell its users what changed.

Keep a short change record for the report itself. Record the definition changed, the effective date, the person approving it and which historical comparisons remain valid. A new combined ticket package can change what a ticket count represents. A new entrance can change the completeness of admission recording. Those changes deserve explanation before the next edition is compared with this one.

This review needn't become another long meeting. Ask the people using each view which decision it helped them make and which question sent them elsewhere. Remove measures nobody uses. Improve a missing explanation when it repeatedly delays a decision. The aim is a reporting process the team can maintain through the next event, using its actual responsibilities and evidence.

Test the views together before handing them over

Run one joint review using known records. Studio Forum gives you a useful starting case: 320 original paid tickets, 300 valid paid tickets, 20 valid complimentary tickets and 150 places available for purchase after the hold. Ask sales, finance and operations to explain how their figures relate without changing the shared definitions.

Then check the money. The example moves from $19,200 of original charges to $18,000 after refunds and $17,040 after its stated payment charges. Of that last amount, $12,000 has reached the bank and $5,040 awaits payout. The separate current payment decision still uses $7,000 available against $9,000 due. Each view should preserve those distinctions.

Test a cancelled ticket, a permitted re-entry and a rejected attempt individually. The operations view should retain 250 first admissions despite 263 attempts. Ask the user whether that establishes current occupancy. If the view encourages that conclusion, clarify the label and provide the correct operational source.

Also test a missing value, a delayed update and a restricted account. The missing value should remain unknown, the delayed source should show its last successful time, and the restricted user should see only the information their authorised task requires. Record any limitation and which uses must wait for a fix.

Finally, ask each user to complete their normal task without the builder explaining the screen. Can sales find the hold owner? Can finance identify tomorrow's gap? Can the door lead locate the relevant exceptions? Their questions will tell you what the view still fails to explain.

Approve the useful parts when those tasks work and record any remaining restrictions. Set the next review around an actual change, such as a new ticket type, a different payment arrangement or another entrance. Before the next event uses the same view, confirm that its definitions and permissions still fit. Reuse the working design, with the event's current facts and responsible people in place.