May review device, order, role, integration and reporting scope according to the deployment agreement.
Software answer · Operator fields
What should a shared power bank agent dashboard show?
A shared power bank agent dashboard should define every station, inventory, order, payment, refund, settlement, overdue, missing, support and reconciliation field by business meaning, source event, freshness, permitted role and next exception action. Access must follow role and data boundaries.
Direct answer
The dashboard should let an authorized operator or agent answer four questions without switching systems: what is deployed, what is available, what happened to each rental, and who owns the next action. Each displayed state needs a source event and freshness marker, while payment, refund and settlement review needs a reconciliation key rather than an unlabeled total.
This field guide is for shared power bank rental operations. It is not a generic BI dashboard, UPS monitor, home-energy system or portable-charger sales report.
Core field groups
Exact field names vary by integration and role. The operator should agree which fields are required, optional, masked or unavailable before launch.
| Field group | Business fields | Source and freshness | Reconciliation or exception action | Boundary |
|---|---|---|---|---|
| Station and slot | Masked station ID, venue, slot count, available, occupied and fault states | Heartbeat or device event, last-seen time, timezone and stale/offline flag | Create a service, refill or connectivity task with owner | Connectivity does not prove venue performance |
| Power-bank inventory | Masked power-bank ID, assigned station/slot, battery and rental/return state | Last device event, source station and event freshness | Trace mismatch, quarantine or rebalance action | Battery health requires agreed telemetry and test method |
| Orders and returns | Masked order ID, channel, station, slot, device, start, eject, return and closure state | Order/device events with timestamps and exception code | Use the order-device key to investigate open or conflicting states | Personal data should be minimized and role-restricted |
| Payments and refunds | Masked provider reference, authorization, charge, refund/release state, currency and amount | Provider callback class, business transition, timestamps and last readable result | Join provider reference to order ID; assign pending or mismatch review | Provider approval, settlement and timing remain external |
| Settlement and commission | Merchant/agent scope, period, source orders, adjustments and known status | Approved rule version, calculation timestamp and source-record freshness | Reconcile period and source orders before approval | No accounting accuracy or payout promise is made |
| Overdue or missing | Due rule, elapsed time, last device event, support status, owner and disposition | Order/device event and rule version with visible age | Assign renter, venue or device investigation as permitted | A label is not proof of loss or customer fault |
| Support and audit | Case ID, masked order/device/station, issue, evidence, owner, timestamps and resolution | Linked source events plus change and access history | Reconstruct the decision trail and close with disposition | Contact details and unrestricted logs must not be public |
Role and responsibility design
A dashboard is safer when each role sees the information needed for its work and no more.
Should not automatically see another agent's records or unrestricted operator-level settings.
May need station availability, local orders and support contact, with financial fields limited by contract.
Needs enough context to investigate without receiving unnecessary settlement or personal-data access.
Requires defined periods, source orders, adjustments and audit status rather than dashboard-only totals.
Needs device identity, fault state, location and service history without broader renter or financial access.
Dashboard acceptance checklist
Test fields with synthetic or redacted records and verify the same state across renter, device and operator surfaces.
Define the field dictionary
Record field name, meaning, source system, update event, timezone, permitted roles and masking rule.
Trace one rental end to end
Follow a test scan, order, payment handoff, unlock, active rental, return, closure and support record using masked identifiers.
Test stale and conflicting states
Verify the dashboard distinguishes last-known data, delayed events, device-offline conditions and reconciliation needs.
Test role boundaries
Confirm agent, merchant, support, finance and service roles cannot access fields outside their assigned scope.
Review export and audit behavior
Confirm export fields, masking, time range, status definitions and event history before using records for settlement or support.
Evidence boundary
Dashboard screenshots demonstrate visible interface and field types only. They do not prove actual customer, revenue, order, station, merchant or venue performance. Use synthetic or redacted examples in public material.
Agent dashboard FAQ
Answers describe a field and role model; final availability depends on the agreed deployment and integrations.
Which station and inventory fields should a shared power bank agent see?
Within the assigned scope, show masked station, slot and power-bank identifiers, online or last-seen state, available, occupied and fault states, last source event, data freshness and the next exception action.
Which order and return fields support customer service?
Show a masked order reference, station, slot and device chain, start, eject, return and closure timestamps, known order state, exception code, support owner and evidence trail.
How should payment and refund states be reconciled?
Keep the business order, masked provider reference, amount and currency, authorization, charge, refund or release state, timestamps and reconciliation key separate. A dashboard label does not prove provider settlement.
What is the difference between agent and merchant dashboard views?
An agent may need assigned multi-venue operations and exception queues, while a merchant may need only its local stations, orders and agreed report fields. Neither role should automatically see another party's records.
How should stale or offline data be marked?
Show the last source event, last-seen timestamp, timezone, freshness state and owner action. Do not display last-known data as live without a visible stale or offline qualifier.
Are dashboard screenshots evidence of revenue or service performance?
No. Screenshots can demonstrate fields and interface structure, but synthetic or redacted values do not prove customer, order, revenue, uptime, settlement or service-level performance.
Define the fields each operating role needs.
Share the network hierarchy, device protocol, payment route and reporting responsibilities for a dashboard-scope review.