Skip to main content

Understand Command Center Analytics

Quick Setup

Most hotels review Completion Rate, Biggest Drop‑Off, and Issues in under 3 minutes.

This guide explains how AVA calculates each Analytics chart in Command Center. It also explains the extra check-in and check-out coverage cards and STB EVA export.

Go to: Main Menu → Command Center → Analytics

Faster analytics loading

AVA now reads this tab from daily rollups for faster wide date ranges. If rollup data is missing or a rollup call fails, AVA falls back to the live path.

Longer load time for large date ranges

Large date ranges can still take longer to load. Very busy properties may return a narrow-date-range error sooner instead of hanging. This applies only to the Analytics tab.

Demo sessions

Demo check-ins still appear in Status and reservation details. They do not count in Analytics totals, drop-offs, time analysis, issues, or recent activity.

No report download

The main Analytics charts do not include a browser PDF download. Funnel reservation lists include a Download CSV action for the displayed reservations. When the STB EVA submissions panel appears, you can use its download icon to export CSV. That export now uses the same EVA submission log source as the dashboard counts.

Copy an MCP config for Codex or Claude​

Quick Setup

This takes under 1 minute. The token is short-lived and uses your current browser session.

Use these buttons when you want to send Analytics data to an AI client. The copied token also includes full Streamliner MCP scope. Supported clients can use settings tools after you restart them. After you copy, AVA shows a client-specific modal with paste instructions.

ButtonWhat it copiesBest for
Copy Codex MCP ConfigA TOML MCP config with mcp_servers.streamlinerCodex
Copy Claude MCP ConfigA JSON MCP config with mcpServers.streamlinerClaude Code or Claude Desktop

  1. Go to Main Menu → Command Center → Analytics.

  2. Click Copy Codex MCP Config or Copy Claude MCP Config.

  3. Wait for the button to change to Creating MCP token....

  4. Read the modal instructions for your client.

  5. Paste the copied config into your AI client config file.

  6. Restart your client so it loads the new MCP server.

    ✓ The Claude config uses JSON. ✓ The Codex config uses TOML. ✓ Both configs include a short-lived STREAMLINER_MCP_TOKEN.

Fresh tokens only

If you copied a token before this change, copy a fresh config. Older tokens keep their previous scope until you renew them.

Where to paste each config

Codex uses ~/.codex/config.toml.

Claude uses Claude Desktop Developer config, usually claude_desktop_config.json.

What the modal shows​

The modal confirms that you copied the config successfully. It then shows the file path, paste location, and restart step for that client.

If you're using Codex

  1. Open ~/.codex/config.toml on the machine where you run Codex.

  2. Paste the copied TOML block at the top level of the file.

  3. Save the file, then restart Codex.

    ✓ If mcp_servers.streamliner already exists, replace that section.

If you're using Claude Desktop

  1. Open Claude Desktop.

  2. Go to Settings → Developer → Edit Config.

  3. Paste the copied JSON into claude_desktop_config.json.

  4. Save the file, then fully quit and reopen Claude Desktop.

    ✓ On macOS, the file is usually under ~/Library/Application Support/Claude/. ✓ If mcpServers already exists, merge only the streamliner entry.

Quick Reference​

ViewWhat counts as a sessionCompletion rule
Pre‑ArrivalAny reservation with Pre‑Arrival activity, including abandoned attempts and journeys that later complete check-inPRE_ARRIVAL succeeds
Check‑In → AllAny reservation with check-in flow steps, including KEY_ENCODED, excluding pre-arrival-onlyCHECKIN, KEY_COLLECTION, or GET_DOOR_LOCK_KEY
Check‑In → Early Check‑InEARLY_CHECKIN_ATTEMPT or ROOM_ASSIGNMENT_QUEUEDEARLY_CHECKIN_ATTEMPT or ROOM_ASSIGNMENT_QUEUED succeeds
Check‑In → Pre‑RegistrationAny reservation with Pre‑Registration stepsPRE_REGISTRATION succeeds
Check‑In → Full Check‑InCHECKIN, KEY_COLLECTION, GET_DOOR_LOCK_KEY, or KEY_ENCODEDCHECKIN, KEY_COLLECTION, or GET_DOOR_LOCK_KEY succeeds
Check‑OutAny reservation with checkout stepsCHECKOUT or COMPLETED_CHECKOUT_PAYMENT succeeds

Open Analytics and choose a view​

Check-In/Out Analytics Dashboard

  1. Go to Main Menu → Command Center.

  2. Select the Analytics tab.

  3. Choose Pre‑Arrival, Check‑In, or Check‑Out.

  4. If you select Check‑In, use the sub‑tabs: All Check‑Ins, Early Check‑In, Pre‑Registration, or Full Check‑In.

    ✓ All charts update to that view and date range.

Use the hotel's local date window​

Analytics uses your hotel's configured timezone when it reads the selected date range. It filters sessions by check-in and check-out activity timestamps, not reservation update times. Only steps inside that local window contribute to the selected day's charts and completion results. A later reservation update cannot add older or future completion steps to that day's analytics. The Successful Check‑Outs card is the exception: it uses the terminal event's completion date.

Compare local operating days

Select dates using the hotel's calendar day, even when you review Analytics from another timezone.

How AVA builds a session​

  • A session is one reservation check-in record (not each guest).
  • A session is included when at least one step from that view is logged.
  • Demo-tagged sessions are excluded from these Analytics charts.
  • Failed steps still count in totals so you can see drop-offs and issues.
Pre‑Arrival is separate

Sessions that only reach Pre‑Arrival are not included in All Check‑Ins. Use the Pre‑Arrival view for those sessions. If a guest completes pre-arrival, then completes check-in on a device, AVA includes that session in both views. An abandoned Pre‑Arrival attempt still appears in the Pre‑Arrival view after the guest starts the flow.

When a guest continues after pre-arrival​

The Pre‑Arrival view is a membership cohort, not an exclusive category. A session can belong to Pre‑Arrival and a Check‑In cohort. A session qualifies after Pre‑Arrival activity begins, even if the guest abandons the flow. Reaching PRE_ARRIVAL marks the session as complete. Opening a pre-arrival link without recorded flow activity does not qualify the session. An observed full check-in milestone still keeps that session in the correct Check‑In totals.

Guest activityAnalytics view
Guest opens the link without recorded flow activityNot included in Pre‑Arrival
Guest starts Pre‑Arrival but abandons itPre‑Arrival, incomplete
Guest completes pre-arrival onlyPre‑Arrival, complete
Guest completes pre-arrival, then completes device check-inPre‑Arrival and Check‑In

This keeps mixed journeys visible in both relevant cohorts. Pure pre-arrival journeys remain excluded from All Check‑Ins.

For Pre‑Arrival, Total Logs counts every session with recorded activity. Completion Rate counts sessions that reach PRE_ARRIVAL. For example, three attempts with two completions show a 66.7% completion rate. An abandoned attempt therefore lowers the rate and reveals flow drop-off.

Historical rollups

Previously saved daily rollups can retain completion-based Pre‑Arrival counts until AVA recomputes them. Newly computed rollups include abandoned attempts in the denominator.

When key encoding is the final recorded step​

AVA treats KEY_ENCODED as a Full Check-In classification signal. This applies even when the session has no KEY_COLLECTION or KEY_RETRIEVED step. The session appears in Full Check-In and All Check-Ins.

KEY_ENCODED does not count as a completion milestone for Completion Rate. The session can therefore increase the Full Check-In total without increasing completed sessions.

Completion rates can change

Properties using keycard encoding may see a slightly lower Full Check-In completion rate. This happens when sessions end at KEY_ENCODED without another completion milestone.

Summary cards (top of the tab)​

CardHow it is calculated
Total LogsNumber of non-demo sessions in the selected view
Completion RateCompleted sessions ÷ total non-demo logs, using the selected view's completion rule
Avg Completion TimeTime from the first successful step (usually Entry) to the configured completion signal
Successful Check‑InsDistinct sessions with a successful PMS CHECKIN milestone
Successful Check‑OutsDistinct checkout sessions with a successful terminal event, attributed to the completion date

The Completion rule column controls Completion Rate and Avg Completion Time. It does not define Successful Check‑Ins.

Use this table to confirm which sessions count as complete before you compare periods.

Successful Check-Outs use completion dates​

The Successful Check‑Outs card counts each unique checkout that reaches a successful terminal event. AVA attributes the count to the hotel's local calendar date when checkout succeeds. Checkout attempts, funnel stages, Completion Rate, and Avg Completion Time keep their start-date attribution.

For example, a checkout that starts Monday and succeeds Tuesday appears in Tuesday's Successful Check‑Outs. Its attempt and funnel activity remains in Monday's checkout analytics.

This keeps successful departures aligned with the day they completed.

Example

If Total Logs is 40 and 28 sessions reach the configured completion signal, the completion rate is 70%. Successful Check‑Ins may show a different number because it counts successful PMS check-in milestones.

Separate PMS check-ins from journey completion​

Successful Check‑Ins confirms that AVA completed the PMS CHECKIN request. For OPERA, this is when AVA sends the SCI code to the PMS. AVA counts the milestone only when recorded Check-In evidence is SUCCESS or PARTIAL. Pending or failed legacy milestone data does not count as a successful PMS check-in. AVA excludes checkout-only journeys when event evidence shows no Check-In activity. This prevents a legacy CHECKIN marker on a completed checkout from inflating the count. If a guest completed Check-In before Checkout, AVA keeps that successful Check-In count.

Completion Rate and Avg Completion Time continue using the configured terminal or room-access signals. This keeps journey performance separate from the PMS milestone.

What happenedSuccessful Check‑InsCompletion metrics
PMS CHECKIN succeeds, then keycard encoding failsCounts the PMS check-inMay show an incomplete journey or failure
Only a pending or failed legacy CHECKIN marker remainsDoes not countFollows the selected view's existing completion rule
Room assignment enters a queue without successful PMS CHECKINDoes not countFollows the selected view's existing completion rule
PMS CHECKIN and room access both succeedCounts the PMS check-inCounts as completed when the terminal signal succeeds

The card no longer combines queued, early, and key-collection categories into Successful Check‑Ins.

Check-in coverage cards​

When AVA receives coverage data from your PMS, you may see two extra cards after Completion Rate. This works for AVA PMS, Cloudbeds, Opera, Mews, and eZee.

CardWhat it showsWhy it matters
Eligible Check-In UnitsDistinct confirmation or sub-reservation units in the selected periodThis is the coverage denominator
AVA Check-In SharePercentage of eligible units with durable AVA check-in activityThis shows AVA adoption for arrivals in that period
Coverage uses arrival dates

Coverage uses each reservation's arrival date in your hotel's timezone. Guests who finish pre-arrival check-in early still count when they arrive in range. The funnel uses activity dates, so these measures answer different questions.

Units vs reservations

These cards count units, not whole reservations. A multi-room booking can add more than one eligible unit.

How AVA decides eligibility

AVA counts only reservations with AVA activity, a valid merchant-local arrival date, and an eligible status. For AVA activity, eligible statuses are RESERVED, CHECKED_IN, CHECKED_OUT, and DUE_OUT. DUE_OUT counts because the reservation already reached check-in before departure. For OPERA, AVA also folds DueOut into the CHECKED_IN PMS coverage bucket. This keeps departure-day and day-use arrivals in the coverage denominator. If AVA cannot verify the required fields, it hides the coverage cards instead of showing a misleading percentage.

OPERA reservations

If your PMS is OPERA, AVA ignores PM, PF, and PX pseudo rooms in the eligible unit count. It also uses top-level room type fields when room rows are sparse, so real guest rooms still count correctly.

OPERA reservation families

AVA also dedupes linked OPERA reservation families by parent confirmation. That keeps terminal sibling rows from inflating Eligible Check-In Units.

OPERA checked-out coverage

If your selected date range includes today before night audit, future-arrival Checked Out legs count as zero. AVA uses the property's business date for that short-circuit, so the coverage read stays fast and consistent.

When the arrival cohort is unavailable

AVA first uses a narrow coverage result for arrivals in your selected date range. If that result is unavailable, incomplete, or still rolling out, AVA uses arrival-filtered logs. If those logs are unavailable, AVA may use an activity-based session map. That fallback can understate coverage for narrow date ranges. An empty result is a valid zero, not missing data. If no source is available, the coverage cards stay hidden.

AVA counts each processed reservation once. It uses the arrival-keyed cohort for normal coverage results. The selected range uses your hotel timezone for arrival-date comparisons. Search-only reservation lookups and PMS or front-desk sync steps do not credit the AVA numerator. If the numerator would exceed the denominator, AVA withholds the share card instead of clamping it. This keeps AVA Check-In Share aligned with reservation coverage.

Fresh results may lag briefly

If you refresh the same date range again, AVA may reuse the last coverage result for a short time. This keeps the Analytics tab fast during repeated checks.

Corrected historical coverage

After a coverage rule update, AVA refreshes older saved coverage results before reusing them. Short date ranges can show corrected cards first. Longer ranges may use live coverage until the scheduled refresh finishes.

Check-In Share Looks Wrong​

What you see: AVA Check-In Share is missing, or it looks higher than expected.

Fix:

  1. Refresh the Analytics tab.
  2. Confirm the date range matches your PMS report.
  3. Check that the range uses your hotel timezone.
  4. Confirm your PMS is sending arrival dates and reservation statuses.
  5. If it still looks wrong, contact support with a screenshot.

If you do not see these cards, your PMS data may be missing the fields AVA needs. Unsupported PMS providers do not show these cards.

Check-out coverage cards​

AVA shows checkout coverage only when your PMS provides a complete departure-scoped cohort. You may see two cards in the Check-Out view. These cards measure AVA checkout activity separately from check-in activity.

CardWhat it showsWhy it matters
Eligible Check-Out UnitsDistinct confirmation or sub-reservation units departing in the selected periodThis is the checkout coverage denominator
AVA Check-Out SharePercentage of eligible units with durable AVA checkout activityThis shows AVA adoption for departures in that period
Coverage uses departure dates

Checkout coverage uses each reservation's departure date in your hotel's timezone. Check-in coverage uses arrival dates, so the two cards can cover different units. The checkout numerator credits durable AVA checkout activity only. Search-only lookups and PMS or front-desk sync steps do not count.

Check-out coverage by PMS​

Cloudbeds, Mews, and OPERA provide native departure cohorts for checkout coverage. AVA does not relabel arrival coverage as checkout coverage. Unsupported PMS adapters may show Unavailable instead of a percentage. For OPERA, incomplete reservation pagination also shows Unavailable. AVA does not calculate a percentage from partial departure data.

Check-out coverage is unavailable​

What you see: The checkout coverage card shows Unavailable instead of a percentage.

Why this happens: AVA cannot verify complete, departure-scoped coverage data. The PMS may not support departure cohorts, or an OPERA reservation page may be incomplete. It hides the rate rather than showing a misleading result.

Fix:

  1. Confirm you selected Check-Out and the correct date range.

  2. Refresh the Analytics tab after PMS sync finishes.

  3. Try the same range again after a few minutes.

  4. Contact support if the card remains unavailable.

    ✓ An unavailable card means the result cannot be trusted yet. It is not a zero.

Export STB EVA submissions CSV​

Quick Setup

This takes under 1 minute. The export appears only on Check-In when EVA is enabled.

Use the small download icon on the STB EVA submissions panel to export the selected date range.

ItemWhat it showsWhat you can do
STB EVA submissionsAttempted, successful, and failed EVA submissions for the selected periodClick the download icon to download the CSV
CSV contentsSummary counts plus one row per EVA API attempt from eva_submission_logsUse it for STB reporting or audit review

  1. Open Main Menu → Command Center.

  2. Select the Analytics tab.

  3. Keep the Check-In view selected.

  4. Scroll to STB EVA submissions.

  5. Click the download icon.

  6. Save the downloaded stb-eva-submissions.csv file.

    ✓ The file includes transaction IDs, result codes, reservation and check-in IDs, error metadata, and sanitized request details. ✓ Passport and document numbers are masked. ✓ MRZ and base64 fields are omitted. ✓ The export no longer includes legacy reservation rows from older EVA reports. ✓ If the download fails, AVA shows a local error message in the panel.

Funnel chart (drop‑offs and step timing)​

The funnel shows the percentage of sessions that reached each step.

  • Drop‑off compares each step to the step before it.
  • Avg Stage Duration measures time spent inside the stage, from stage start to stage success.
  • Avg Time to Next Step measures time from one successful step to the next.
  • The Slowest Step card uses stage duration first.
  • If AVA does not have stage timing, it falls back to the next-step duration.
  • If a later step happens earlier than the prior step, the duration is shown as 0.

Use the Biggest Drop‑Off card to pick the step that needs coaching first.

Example

If Document Upload has 60 sessions and the prior step has 100, drop‑off is 40%. If Document Upload itself takes 20 seconds, Avg Stage Duration is 20 seconds. If Document Upload completes at 10:05 and Validation at 10:07, Avg Time to Next Step is 2 minutes.

Checkout conversion uses required milestones​

In Check‑Out, AVA calculates conversion from the required checkout milestones.

StageHow AVA treats it
Checkout StartedRequired starting milestone from FETCH_CHECKOUT
Bill ReviewedOptional activity when a guest views the bill
Charges ConfirmedOptional activity when a guest confirms charges
Checkout PaymentOptional activity when payment is collected
Checkout CompleteRequired final milestone from CHECKOUT

A guest can move directly from Checkout Started to Checkout Complete. AVA counts that path as completed instead of showing a false drop‑off.

Observed optional stages appear in Optional checkout activity. They do not lower conversion or create a red loss transition. The dashboard and downloadable analytics report use the same stage rules.

AVA shows Checkout Payment when it observes checkout payment activity. It keeps payment outside the required funnel, even when a saved setting is stale. It does not label missing payment as not required or treat it as a failure.

Direct PMS checkouts look like drop-offs​

What you see: A guest completed checkout in the PMS, but skipped bill or payment stages.

Fix:

  1. Select Check‑Out in Command Center → Analytics.

  2. Find Checkout Complete as the final required stage.

  3. Review Optional checkout activity for bill, charge, or payment events.

  4. Compare the dashboard with the downloadable report if you need a saved copy.

    ✓ Direct PMS checkouts count toward final conversion.

View reservations from required-step drop-offs​

Required checkout drop-offs can include a View list action. Use it to find reservations that reached one required stage but missed the next.

  1. Select Check‑Out in Command Center → Analytics.
  2. Find a required-stage transition with a drop-off count.
  3. Click View list.
  4. Review the confirmation number, guest name, room, and latest failure details.
  5. Click Download CSV to save the displayed reservations.

AVA shows View list only when every matched session equals the displayed drop-off count. If the reservation mapping is incomplete, AVA hides the action for that transition.

Review failed checkout payments​

Payment appears under Optional checkout activity when AVA observes checkout payment activity. It can appear even when a saved payment setting is stale. Payment activity never changes checkout completion or required-stage conversion.

  1. Select Check‑Out in Command Center → Analytics.
  2. Find Payment under Optional checkout activity.
  3. Click View failed reservations when failed payments are listed.
  4. Review the reservation details and failure message.
  5. Click Download CSV to save the displayed failures.

The CSV includes Confirmation number, Guest name, Room, Failure step, and Failure message. AVA shows View failed reservations only when every failed payment maps to a session.

Successful Check-Outs appears on another day​

What you see: A checkout started on one day, but Successful Check‑Outs increases on another day.

Fix:

  1. Check when the terminal checkout event succeeded.

  2. Compare that timestamp with your hotel's local calendar date.

  3. Review the checkout start date when comparing attempts or funnel stages.

  4. Refresh the Analytics tab if the checkout completed recently.

    ✓ This is expected when checkout crosses midnight or completes after a delay.

Time Analysis (hourly volume)​

Time Analysis groups sessions by the first successful step in the selected view.

  • Hour buckets use UTC.
  • The analytics response labels this with timezone: UTC.
  • Check your hotel's timezone before comparing peaks with local staffing.
  • Pre‑Arrival requires a successful PRE_ARRIVAL step.
  • Shows Peak Hours and Rush Periods to help with staffing.

Use Peak Hours to plan coverage for your busiest time blocks.

Example

A session that first succeeds at 7:10 local time counts in the 07:00 hour.

Issues (recent failures)​

Issues list sessions with the most recent failed steps.

  • AVA checks the last 10 events for failures.
  • If no recent failures exist, it uses the most recent failure on record.

Use View Details to see full step history.

Example

If a payment failed at 3:12 after earlier success, the issue shows Payment at 3:12. If the last 10 events are successful, AVA shows the most recent failure on record.

Recent Activity​

Recent Activity shows key steps that were successful or failed, such as:

  • Check‑In, Check‑Out
  • Room Assignment
  • Pre‑Registration
  • Identity Verification
  • Payment

This list is capped to the latest 30 items.

Use this list to confirm which steps were completed most recently.

Example

You may see “Check‑In completed successfully” or a failure message for Identity Verification.

Final Step Distribution (where sessions end)​

This chart groups the last step of each session into categories:

  • Success — Full completion steps
  • Timing — Early check‑in steps (including Room Queued)
  • Partial — Pre‑registration
  • Room — Room assignment steps (Room Assignment)
  • Documentation — Document or ID verification
  • Payment — Payment steps
  • Early — Entry / Fetch steps

If a failure happens after the last success, the failure step becomes the final step.

Use this chart to see the most common stopping points.

Example

Out of 50 sessions, 20 end at Check‑In (success), 10 at Early Check‑In (timing), 8 at Document Upload (documentation), and 12 at Payment (payment).

Open sessions from the Final Step Distribution​

  1. Select a bar segment in Final Step Distribution.

  2. Review the session list that opens.

    ✓ The list shows confirmation number, guest, room, and the latest failure.

  3. Select Open details on any session.

    ✓ The Reservation Details panel opens for that session.

Session lists vs reservations

The list shows sessions, not grouped reservations. Use it to spot repeat failures fast.

Device Analytics (optional)​

Device Analytics uses the device details from the check‑in/out session.

If guests did not provide device information, this chart may be empty.

Use this view to compare kiosk vs mobile usage by OS.

Example

If most sessions are iOS, you may want to optimize the mobile check‑in flow.

Limits & data freshness​

  • Analytics covers up to 90 days per query.
  • When daily rollups are available, wide ranges load from rollup data first.
  • Very busy properties may need a smaller range if the result set is too large.
  • If AVA asks you to narrow the date range, shorten the period and try again.
  • Session lists are capped for performance (about 200 per step and 2,000 total).

Troubleshooting​

All charts show zero​

What you see: Summary cards show 0 and charts are empty.

Fix:

  1. Expand the date range.
  2. Confirm there are logs in Status.
  3. Check if your plan includes Analytics.

Completion rate looks lower than expected​

What you see: Completion rate is low even though many guests checked in.

Check:

  • Demo check-ins are excluded, so test sessions do not raise Total Logs.
  • Pre-arrival-only sessions do not count toward All Check‑Ins.
  • A session that completes pre-arrival and later completes check-in appears in both relevant views.
  • A session that starts Pre‑Arrival but abandons it qualifies for Pre‑Arrival and lowers its completion rate.
  • A session that only opens a pre-arrival link does not qualify without recorded flow activity.
  • All Check‑Ins only treats CHECKIN, KEY_COLLECTION, or GET_DOOR_LOCK_KEY as completed.
  • KEY_ENCODED places a session in Full Check‑In, but does not complete it.
  • Early Check‑In and Pre‑Registration are tracked in their own sub‑tabs.
  • Successful Check‑Ins counts successful PMS CHECKIN milestones.
  • Checkout-only records with a legacy CHECKIN marker do not count without Check-In activity evidence.
  • It can differ from Completion Rate when room access is a required terminal signal.

Coverage cards are missing​

What you see: You only see the standard summary cards.

Fix:

  1. Stay on Check-In.

  2. Confirm your PMS connection is active.

  3. Refresh the page after sync finishes.

  4. If the date range is busy, refresh again after a few minutes.

    ✓ If your PMS supports reservation coverage, Eligible Check-In Units and AVA Check-In Share appear after Completion Rate.

Coverage cards still look unchanged​

What you see: Eligible Check-In Units or AVA Check-In Share still looks the same after a refresh.

Fix:

  1. Wait a minute.
  2. Refresh the Analytics tab again.
  3. Confirm the date range matches the PMS update you expect.
  4. If it still looks wrong, check that PMS sync has finished.

Time Analysis uses the wrong local hour​

What you see: Peak hours do not match your hotel's local time.

Fix:

  1. Check the analytics response's timeAnalysis.timezone value.
  2. Treat UTC buckets as UTC, not hotel-local time.
  3. Use merchantTimezone to convert the buckets for local staffing.
  4. Verify your hotel timezone at Settings → Essentials → Hotel Basic Details.

Analytics keeps loading or asks you to narrow the range​

What you see: The Analytics tab spins for a long time, shows a timeout, or asks you to narrow the date range.

Why this happens: Larger ranges need more time to process. Very busy properties can also hit request limits sooner.

Fix:

  1. Wait up to 2 minutes for the request to finish.

  2. Try a smaller date range if the page still times out or asks you to narrow the range.

  3. Refresh the Analytics tab and retry.

  4. If small date ranges still fail, contact support with the selected dates.

    ✓ Smaller ranges should finish faster and help you confirm whether the issue is range size or data availability.

Analytics shows a step from another day​

What you see: A selected day appears to include a completion from another calendar day.

Fix:

  1. Confirm the hotel's timezone at Settings → Essentials → Hotel Basic Details.
  2. Re-select the date range using the hotel's local calendar day.
  3. Refresh the Analytics tab.
  4. If the result still looks wrong, contact support with the selected dates and reservation number.

MCP config copy fails​

What you see: The button shows an error after you click Copy Codex MCP Config or Copy Claude MCP Config.

Fix:

  1. Stay on the Analytics tab.
  2. Try the copy button again.
  3. Refresh the page and retry if the token request timed out.
  4. If the error stays, contact support with the exact message.

Config copied, but the client cannot connect​

What you see: The modal opens, but Codex or Claude does not load the Streamliner server.

Fix:

  1. Check that you pasted the config into the correct file.
  2. Confirm the STREAMLINER_MCP_TOKEN value is still present.
  3. Restart the client completely.
  4. Copy a fresh config if setup took too long.

Settings tools are missing​

What you see: Your client connects, but settings actions do not appear.

Fix:

  1. Copy a fresh config from Analytics.
  2. Restart the client completely.
  3. Confirm the pasted STREAMLINER_MCP_TOKEN is the latest one.
  4. Remove any older Streamliner config block if it is still present.

Settings writes time out​

What you see: A settings save looks stuck, then returns a timeout or cancel message.

Fix:

  1. Copy a fresh config from Analytics.

  2. Restart the client completely.

  3. Try the settings change again.

  4. If it fails again, check whether your token or session expired.

    ✓ Valid settings updates should finish instead of hanging.

Authentication failed on a settings write​

What you see: You get an authentication error when saving merchant settings.

Fix:

  1. Copy a fresh config from Analytics.

  2. Restart the client completely.

  3. Retry the settings change in the same hotel.

  4. If you switched hotels, refresh the config after the switch.

    ✓ The new error should tell you to generate a fresh MCP config/token.

Browser PDF download is still missing​

What you see: You expect a Download report button for the full analytics charts.

Fix:

  1. This is expected in the current Analytics tab.
  2. Use the charts and date range filters on screen.
  3. Use the download icon for STB EVA submissions if you need submission details.
  4. Contact support if you need a different export path.

STB EVA export is missing​

What you see: You do not see the download icon under STB EVA submissions.

Fix:

  1. Switch to Check-In.
  2. Confirm EVA is enabled for Singapore in Settings → Check-in → Government Integration.
  3. Refresh the page after the analytics data loads.
  4. If the panel is still hidden, the selected date range may not include EVA submissions.

CSV export fails​

What you see: You click the download icon, but no file downloads.

Fix:

  1. Retry after the analytics summary finishes loading.
  2. Narrow the date range.
  3. Check that your browser allows downloads.
  4. Try again once the local error clears.
  5. Contact support if the export still fails.

Funnel reservation list is missing​

What you see: A required drop-off or failed payment has no list action.

Fix:

  1. Confirm you selected Check‑Out and the correct date range.
  2. Check that the transition has a non-zero drop-off or failed-payment count.
  3. Refresh the Analytics tab after the data finishes loading.
  4. If mapping remains incomplete, use Status to search for the reservation.

AVA hides list actions when it cannot safely match every displayed count.

Still Stuck?​

Contact success@vouch-technologies.com if:

  • ❌ Analytics shows data in Status but Analytics is empty
  • ❌ Charts never update after changing the date range
  • ❌ Issues list shows incorrect timestamps

Helpful to include:

  • Date range you selected
  • Screenshot of the Analytics tab
  • Confirmation number of a sample reservation