Answer first: trigger action before the station reaches zero ready units or zero working return slots. Set separate borrow-risk and return-risk thresholds from recent net flow, time to the next demand wave, field travel time, and nearby alternatives. Use fixed minimum counts as a safe pilot baseline, then add time-to-empty or time-to-full forecasts after the data is reliable. Every alert should create an owned task with acknowledgement, action, and recovery evidence.
Restocking and rebalancing solve different problems. Restocking adds charged, serviceable power banks from a depot or removes units for maintenance. Rebalancing moves inventory between stations so one site gains ready units or empty return capacity without increasing the fleet. A field visit may do both, but the SaaS should record the reason because the long-term remedies differ.
A station with low ready inventory faces a borrowing stockout. A station with few working empty slots faces a return lockout. Treating both as “low stock” confuses the route plan. GBFS provides a useful shared-mobility precedent by exposing available vehicles and available docks as distinct states [1]. The hardware is different, yet the operating lesson is direct: create two alert families.
Start with fixed-count thresholds
For a new network, forecasting may be too fragile. Begin with a warning and a critical threshold for each station class. For example, a compact station might warn when ready units or working empty slots fall below two; a larger station may require a higher absolute buffer. These are illustrative settings, not universal rules.
Define four states:
- Borrow warning: ready units are approaching the minimum service buffer.
- Borrow critical: a stockout is imminent or already present.
- Return warning: working empty slots are approaching the minimum return buffer.
- Return critical: a full-station failure is imminent or present.
Exclude disabled slots and ineligible power banks from the counts. Add persistence to avoid noisy tasks caused by a single delayed message, but do not delay alerts so long that the response window disappears. The threshold design must reflect telemetry frequency and reliability.
Convert counts into time
A count becomes actionable when combined with flow and response. Estimate:
time to limit = current usable buffer / recent net consumption rate
For borrow risk, net consumption is rentals minus returns. For return risk, it is returns minus rentals. Use a conservative rate from comparable peak intervals, not a whole-day average. If three ready units remain and the station is losing one net unit every ten minutes, the team has less than thirty minutes before stockout. If travel and access require forty-five minutes, dispatch is already late.
Set the warning far enough ahead to cover alert delay, acknowledgement, route insertion, travel, venue access, and service work. Keep a critical fallback based on absolute counts in case the forecast fails. Record which rule fired and whether the predicted state occurred.
Prioritize by service risk
Field capacity is limited. Primary research on docked bike-sharing observes that operators must prioritize because stations can become empty or full and rebalancing resources cannot always serve every site [2][3]. Another multi-system study found that rebalancing patterns depend on time, station context, and the purpose of the network [4]. These findings support a ranked queue rather than first-in, first-out.
A practical priority score can include:
- predicted minutes to stockout or full state;
- number of recent failed borrow or return attempts;
- distance and verified availability of alternative stations;
- venue criticality and support impact;
- expected peak before arrival;
- travel time, access window, and inventory carried;
- whether one visit can resolve several nearby tasks.
Do not let a commercial priority label silently override safety or customer-return risk. Make the weighting visible and review it with operations.
Choose the correct field action
An alert should recommend an action, not merely display red. For low ready inventory, options include moving charged units from a nearby overstocked station, adding depot inventory, increasing the initial load before the next peak, or adding capacity. For low return capacity, remove or redistribute units, preserve more empties after service, or redirect returns to a verified nearby station.
If the state is caused by offline telemetry, disabled locks, charging failure, or incorrect slot mapping, inventory movement is not the first fix. Create a maintenance task and protect the customer journey. A station can report “full” because two empty physical bays are digitally unavailable.
Close the operational loop
Every dispatched task should contain station identity, reason, current state, recommended target, inventory to carry or remove, access instructions, and evidence required at completion. The field worker should scan or confirm unit identities, record before-and-after counts, flag faults, and provide a timestamped completion state. The backend should verify recovery from station telemetry rather than relying only on a manual “done” tap.
Track alert quality: alerts acknowledged, false or stale alerts, time to acknowledgement, time to recovery, tasks completed before failure, emergency visits, repeated alerts after service, and unavailable minutes. Review thresholds by station and venue class. A restaurant lunch pattern, a gym class schedule, a hotel checkout wave, and a transport arrival bank should not share one unexamined threshold.
Plan regular work and exceptions separately
Forecasted route work should handle predictable imbalances before opening, lunch, classes, checkout, or events. Real-time dispatch should handle deviations such as unexpected demand, faults, delayed returns, or a missed visit. If every task is an emergency, the baseline loading and route schedule need redesign. If every route is fixed, the network cannot respond to real variation.
The mature operating model combines both. It uses a planned target inventory, observes ready units and working empties in near real time, predicts when the buffer will fail, ranks tasks by customer impact and response feasibility, and confirms recovery through telemetry. That is more useful than a dashboard full of red icons and more honest than claiming software can eliminate stochastic demand.
Evidence date and limits
Evidence reviewed through 2026-08-09. The following limits are part of this buyer guide:
- Threshold examples are pilot settings, not values prescribed by the cited standards or studies.
- Bike-sharing research is an operational analogy and does not establish shared-power-bank demand or route economics.
- Employment, access, safety, transport, privacy, and customer-remedy procedures require local review. Verify target-country requirements before publication and deployment.
- No staffing level, response time, cost reduction, or uptime result is guaranteed.
Related CoreCharge guides
- power bank rental software features
- shared power bank rental software integration checklist
- venue deployment checklist rental charging stations
- products 24 slot.html
- Previous guide in this capacity cluster
- Next guide in this capacity cluster
Sources
1. MobilityData - General Bikeshare Feed Specification (GBFS) (accessed 2026-08-09). available rental inventory and available docks can be represented as separate station states. 2. Maria Clara Martins Silva, Daniel Aloise, and Sanjay Dominik Jena - Data-driven prioritization strategies for inventory rebalancing in bike-sharing systems (accessed 2026-08-09). limited rebalancing resources require prioritization of imbalanced stations near peaks. 3. Benjamin Legros - Dynamic Repositioning Strategy in a Bike-Sharing System: How to Prioritize and How to Rebalance a Bike Station (accessed 2026-08-09). stochastic flows create empty/full station risks and motivate dynamic decisions about where and how much to move. 4. Cyrille Medard de Chardon, Geoffrey Caruso, and Isabelle Thomas - Bike-share rebalancing strategies, patterns, and purpose (accessed 2026-08-09). rebalancing is time- and context-dependent, and station priorities should align with system purpose.