Shared Power Bank Pilot Guide 2026: A 30/60/90-Day Validation Plan for 50–100 Stations

Contents

Key Takeaways

Introduction: A Working Sample Is Not a Validated Business

1. What Is a Shared Power Bank Pilot—and What Must It Prove?

2. Build the Pilot Charter: Decisions, KPIs, Data Rules and Owners

3. Pass the Market Readiness Gate Before Deployment

4. Design a Representative 50–100-Station Pilot Network

5. Complete End-to-End Go-Live Acceptance

6. Standardize Venue Onboarding, Activation and Team Responsibilities

7. Execute the 30/60/90-Day Validation Plan

8. Build and Read the Day-90 Pilot Evidence Pack

9. Make a Go, Adjust or Stop Decision—and Prepare the Exit Plan

10. Scale a Validated Model Without Overextending

Common Shared Power Bank Pilot Mistakes

Frequently Asked Questions

How Bajie Charging Supports Pilot Readiness

Conclusion: Turn the Pilot into a Decision System

Key Takeaways

• A sample proves that a product can work; a commercial pilot tests whether the complete operating model can work in a real market.

• Bajie Charging recommends that projects planning for commercial scale consider a 50–100-station range for meaningful validation. This is a planning reference, not a universal minimum order or success threshold.Bajie Charging50–100

• The 90-day framework is a management and review cycle. It does not promise profitability, payback or a predetermined operating result.90

• The pilot must test more than rental volume: venue quality, network usefulness, payment completion, device availability, operating workload, merchant cooperation and traceable costs all matter.

• KPIs, data definitions, owners and stop conditions should be agreed before deployment. Changing the rules after seeing the results weakens the evidence.KPI

• The final output should be a documented Go, Adjust or Stop decision—not a collection of dashboard screenshots.

Introduction: A Working Sample Is Not a Validated Business

A shared power bank pilot is a controlled commercial deployment designed to test whether a proposed operating model can work under real market conditions. It connects venues, users, rental stations, power banks, software, local payments, support and field operations—and turns their performance into evidence for a scale, adjustment or stop decision.

For clarity, this guide uses station to mean a rental cabinet or docking unit and venue to mean the business location where one or more stations are installed. A power bank is the portable battery rented by the end user. Keeping these terms separate is important: 50–100 stations does not mean 50–100 individual power banks, and one venue may contain more than one station.

The guide is intended for operators, regional partners, investors and project teams that have moved beyond general market research and are preparing a real deployment. It does not replace country-specific legal advice, payment-provider approval, supplier due diligence or detailed software selection. Those workstreams should already be underway; the purpose here is to show how to validate the complete business system before committing to wider expansion.

Bajie Charging recommends that commercially ambitious projects consider a range of 50–100 stations when planning a representative market validation. The appropriate number may be lower or higher depending on city size, venue access, operating budget, return-network design and the teams ability to support the fleet. It is not a universal minimum, a purchase requirement or a guarantee of market success.

Likewise, the 30/60/90-day structure is a practical planning and review rhythm. Some markets may need a longer observation period because of seasonality, payment onboarding, venue contracting or low initial awareness. Ninety days should be treated as a disciplined decision window—not as a promised route to profitability or payback.

Four Stages That Should Not Be Confused

The central question is therefore not, Did the station power on? It is, Do we have enough reliable evidence to approve the next level of investment?

Request a project review

1.What Is a Shared Power Bank Pilot—and What Must It Prove？

A commercial pilot is a time-bounded, scope-controlled test of the complete business proposition. It should be large enough to expose differences between venue types, user journeys and operating conditions, yet contained enough for the team to investigate failures, make recorded changes and limit risk. Its purpose is learning and decision-making—not generating an attractive but incomplete headline number.

1.1 Prove That a Real User Need Exists

The pilot should test whether people experience a charging need in the selected environments and whether the rental service solves that need with acceptable effort. A high-footfall location is not automatically a high-demand location. Users must notice the station, understand the offer, accept the pricing and terms, complete payment and feel confident that they can return the power bank.

This is why rental count alone is insufficient. Low usage may indicate weak demand, but it may also reflect poor visibility, confusing instructions, an unsuitable payment journey, unavailable power banks or staff who were not trained to support the launch. The pilot must separate a demand problem from an activation or execution problem.

1.2 Prove That the Venue Mix and Network Design Are Useful

The pilot should compare more than venue categories. It should also examine the precise in-venue position, operating hours, dwell time, power and network conditions, staff cooperation, nearby return options and the stations role in the wider network. Two restaurants in the same district can perform very differently if one station is visible near a waiting area while another is hidden away from the customer journey.

Not every valuable station will be the top rental producer. Some locations mainly generate rentals; some make returns convenient; some close a coverage gap; and some create visibility that supports nearby stations. A credible pilot therefore evaluates both individual station performance and the health of the local rental-and-return network.

1.3 Prove That the Complete User and Payment Journey Works

A payment integration that succeeds in a demonstration environment is not yet a proven commercial payment flow. The pilot must verify what the end user sees before payment, how authorization or collection is handled, whether the station releases the correct power bank, when billing stops, how refunds and failed orders are managed, and whether the operator can reconcile transactions accurately.

The same standard applies to language, currency, pricing disclosure, receipts, support messages and return instructions. A technically connected journey can still fail commercially if it is unclear, unfamiliar or incomplete for local users.

1.4 Prove That the Fleet Can Be Operated Reliably

The project team needs evidence that stations remain online, rentable power banks are available, returns are recorded correctly, exceptions reach the right owner, and field interventions remain manageable. Empty stations, full stations, failed releases, damaged assets, late returns and data mismatches are not edge cases to ignore; they are part of the operating model that the pilot is designed to expose.

Operational viability also includes the workload behind the dashboard: venue visits, redistribution, cleaning, replacement, merchant communication, support tickets and escalation. A network that appears active but requires unsustainable manual intervention is not yet ready to scale

1.5 Prove That Venue Acquisition and Merchant Cooperation Can Be Repeated

Shared power bank expansion depends on more than equipment supply. The pilot should track the venue-development funnel—from identified prospect to qualified venue, agreement, installation, activation and continued cooperation. It should record why venues decline, why signed locations fail to launch, how much work onboarding requires and whether merchants are willing to retain, expand or recommend the service.

If the commercial model relies on a venue pipeline that cannot be repeated at a reasonable operational effort, strong performance at a few exceptional locations may not translate into a scalable business.

1.6 Prove That Performance and Cost Can Be Measured Consistently

The pilot does not need to promise a standard return on investment. It does need to establish whether rental activity, payment fees, venue-related costs, connectivity, field operations, refunds, maintenance and asset exceptions can be captured using consistent definitions. Without traceable inputs, a scale decision becomes an assumption disguised as a forecast.

The Six Proof Questions

Before any station is deployed, these questions should be converted into written hypotheses. A useful hypothesis states the expected condition, the evidence required, the observation period and the decision it will inform. Restaurants will work is too vague; selected restaurant formats can support a repeatable rental-and-return journey under the agreed activation and operating conditions is testable.[Request a project review]

2. Build the Pilot Charter: Decisions, KPIs, Data Rules and Owners

The most useful pilot document is often not a large presentation. It is a one-page Pilot Charter that makes the projects purpose, scope, evidence rules and decision authority explicit. It keeps sales, operations, software, payment, finance and management teams from evaluating the same pilot with different assumptions.

2.1 Start with the Day-90 Decision

Write down the decision the review team must make at the end of the cycle. The result should normally fall into one of three categories:

•Go:Approve a controlled next phase with a defined scope, deployment ceiling and unresolved items that remain under monitoring.

•Adjust:Continue validation only after specified changes are completed, assigned and retested within an agreed period.

•Stop:Pause expansion because a material demand, payment, compliance, safety, operational or economic assumption has not been supported.

A Go decision is not approval for unlimited expansion. An Adjust decision is not permission to keep changing the project without control. A Stop decision is not necessarily a declaration that the entire market is impossible; it may mean that the tested proposition, configuration or operating approach is not ready.

2.2 Define the Scope and Boundaries

The charter should identify the country, city, pilot districts, target user groups, venue categories, station count, planned deployment waves, rental entry points, payment methods, operating model and review dates. It should also state what is outside the pilot, such as additional cities, unapproved payment methods or venue formats that will not be tested in this cycle.

The 50–100-station range should be treated as a configurable design choice. The charter should record why the selected quantity is sufficient to compare the planned venue and network conditions—and why the project team has the capacity to support it. Choosing a number merely because it sounds substantial does not make the pilot representative.

2.3 Create a KPI Dictionary Before Launch

A KPI is useful only when everyone calculates it the same way. For every measure, define its business purpose, formula, numerator, denominator, source system, inclusion and exclusion rules, reporting timezone, currency, review frequency and owner. If a term such as active station, successful rental or payment completion is not defined, teams can produce conflicting results from the same underlying events.

The charter should cover at least six KPI groups without imposing universal public thresholds:

1.System availability:station connectivity, rentable inventory and incident recovery.

2.User and payment journey:rental starts, payment attempts, completed payments, successful releases, completed returns, refunds and exception orders.

3.Venue and network performance:station activity, venue-type differences, in-venue position, cross-station returns and empty/full patterns.

4.Operating workload:field visits, redistribution, tickets, maintenance, replacement and resolution time.

5.Merchant development:qualified venues, agreements, installation, activation, retention and reasons for loss or delay.

6.Economic traceability:recorded rental activity and the directly attributable payment, connectivity, venue, field-service, refund, maintenance and asset-exception costs.

Targets, if the project uses them, should be approved privately in the charter based on the target market and business model. They should not be borrowed from an unrelated country, venue mix or supplier claim. A pilot can be well managed without publishing a universal rental target, payment success rate, return-on-investment figure or payback period.

2.4 Protect the Validity of the Data

The data rules should be agreed before the first live transaction. Test orders, staff demonstrations, duplicate records, cancelled transactions and approved refunds must be identifiable. The project should use a consistent timezone, currency conversion rule and reporting period. Data gaps and manual corrections should be logged rather than silently overwritten.

Observations should include weekdays and weekends as well as relevant peak and non-peak periods. Public holidays, exhibitions, extreme weather, temporary promotions, outages and other abnormal events should be labelled so that a short-lived spike or disruption is not mistaken for normal demand.

When a location, price message, payment route, station configuration or activation method changes, record the date, reason, owner and expected effect. Whenever practical, change one major variable at a time. If several variables are changed together, the team may improve the result but lose the ability to explain why.

2.5 Assign Owners and Decision Rights

Pilot responsibilities may be combined in a small team, but the accountability itself must remain visible. One person may hold several roles; one critical task should not have several unnamed owners. A simple RACI model—Responsible, Accountable, Consulted and Informed—helps prevent gaps between the operator, venue, software provider, payment provider and equipment supplier.

2.6 Define Risk Limits and Stop Conditions

The charter should state the approved pilot budget, contingency allowance, maximum station count, maximum permitted exposure and conditions requiring immediate pause. These conditions may include unresolved safety issues, inability to complete or reconcile payments, material privacy or data-control failures, repeated critical faults, or a lack of operational ownership.

Exit principles should also be agreed at the beginning: who owns the equipment, how unresolved orders and refunds will be handled, what happens to venue agreements, how data will be exported and how stations will be relocated or removed if the pilot is paused. A project that cannot exit responsibly is not fully controlled.[Request a project review]

Minimum Contents of the Pilot Charter

Once the charter is approved, changes should be version-controlled. The goal is not to freeze learning; it is to distinguish a planned adjustment from an undocumented change in the rules.

3. Pass the Market Readiness Gate Before Deployment

A pilot should not begin merely because equipment has arrived. Before installation, the project team should pass a documented Market Readiness Gate covering commercial authority, payment readiness, infrastructure, venues, operations and evidence ownership. A delay at this stage is usually less costly than collecting 90 days of unusable data from a deployment that was never truly ready.

3.1 Confirm Commercial and Local Compliance Readiness

Identify the entity that will contract with venues, the entity that will contract with payment providers and the party responsible for end-user terms, privacy notices, refunds, consumer complaints, imports and local tax treatment. These responsibilities may be divided among several parties, but they cannot remain ambiguous.

3.2 Confirm Payment and Settlement Readiness

Payment readiness begins with the operators commercial eligibility, not with a logo displayed on a website. Confirm that the intended merchant entity can apply for and use the required payment method, receive settlement in the relevant currency, meet provider review requirements and operate the planned authorization, collection, refund and reconciliation flows.

The operator, payment provider, software provider and any other settlement party should agree who owns each step: account application, credentials, integration, testing, dispute handling, refund approval, reconciliation, data retention and incident escalation. Payment is supported is not a sufficient readiness statement unless account ownership and operational responsibilities are clear.

At this stage, confirm at minimum:

• Merchant account eligibility and application status.

• Supported payment methods, transaction currency and settlement currency.

• Authorization, capture or direct-charge logic relevant to the rental model.

• Refund, cancellation, dispute and reconciliation procedures.

• Ownership of credentials, transaction data and operational communication.

• Test and production environments, approval status and go-live dependencies.

3.3 Confirm Technical and Infrastructure Readiness

Each planned venue should be checked for stable power, suitable network connectivity, safe installation conditions and the ability to keep the station accessible during operating hours. Connectivity assumptions should be verified on site; coverage shown on a general map does not guarantee reliable service inside a specific venue.

The digital service layer must also be production-ready. Depending on the chosen user journey, this may include domain ownership, application accounts, web rental pages, SMS or email delivery, map services, support channels, reporting access, correct timezone and currency configuration, local-language content and user-facing legal pages. All production credentials should have named owners and controlled access.

A representative pilot needs confirmed locations, not a spreadsheet of hopeful leads. The readiness review should show how many venues have been qualified, how many have agreed to participate, how many have approved installation and power use, and how many have a named on-site contact. The planned mix should be diverse enough to test the hypotheses in the charter without becoming so fragmented that the team cannot support it.

For every approved venue, record the proposed in-store position, operating hours, power and network checks, installation permission, responsible contact and expected role in the network. If the majority of locations are still unconfirmed, the project is not ready for a representative rollout.

3.5 Confirm Operating and Support Capacity

The team should be able to receive alerts, inspect stations, communicate with venues, redistribute power banks, replace faulty assets, handle user issues and escalate software or payment incidents. The readiness gate should name the responsible people, operating hours, escalation path, evidence to collect and the conditions that require on-site action.

Spare parts and replacement planning should match the chosen configuration and local logistics reality. The objective is not to publish a universal spare-parts ratio; it is to ensure that the pilot will not become unmeasurable because a known operational dependency was ignored.

3.6 Confirm Evidence Ownership and Review Rhythm

Before launch, confirm who will review device health each day, who will review KPI results each week, how incidents are classified, where supporting records are stored and who approves corrective changes. Day 30, Day 60 and Day 90 review meetings should already be scheduled, with required inputs and decision owners listed.[Request a project review]

Market Readiness Gate Checklist

Ready means the required evidence is complete and no material dependency remains open.Conditional means a limited deployment may proceed only if the condition, owner, deadline and containment measure are documented.No-Go means the pilot should not begin until the blocking issue is resolved and retested.

At minimum, unresolved production payment access, inability to present correct user terms, unsafe installation, missing venue permission, absent data access or no accountable incident owner should block live deployment. Starting anyway may create activity, but it will not create dependable evidence.

Passing the Market Readiness Gate does not mean the business has been validated. It means the project is finally ready to begin a valid test.

4. Design a Representative 50–100-Station Pilot Network

A commercial pilot should resemble the network you may eventually operate. It should not be a collection of identical stations placed wherever space happens to be available. A representative pilot includes different venue types, in-venue positions, demand patterns, return behaviors and operating conditions. Its purpose is to reveal which parts of the model can be repeated—not merely to generate activity during a short launch period.

For projects intended to grow into a city-level network, Bajie Charging recommends considering 50–100 rental stations as a meaningful commercial validation range. This is a planning reference, not a universal minimum. The appropriate size depends on the target city, available venues, payment readiness, operating budget, return-network design and the number of stations the local team can support properly.

4.1 Define the Pilot Boundary Before Choosing Locations

Begin by drawing a clear geographic boundary: one business district, one hospital cluster, one nightlife area or another area that the team can inspect and support consistently. A compact network usually produces clearer evidence than the same number of stations dispersed across an entire city, because customers have a better chance of finding a convenient return point and operators can compare locations under more consistent market conditions.

The pilot boundary should document the assumptions that may affect interpretation. These include the target users, operating hours, typical dwell time, local transport patterns, seasonal events, payment method, rental entry point and the intended return model. If these conditions change during the pilot, the change must be recorded rather than treated as normal performance variation.

4.2 Build a Venue Portfolio, Not a Single-Scenario Test

A useful pilot compares several venue categories that are relevant to the local market. Restaurants and cafés may test table turnover and mealtime demand; bars and nightlife venues may reveal late-hour charging needs; hospitals may test long dwell times and urgent-use situations; shopping centres, hotels, transport locations and events may produce different visibility, return and staffing patterns. The goal is not to include every possible category. It is to include enough meaningful variation to identify a repeatable venue profile.

Do not allocate the entire pilot to whichever venue type is easiest to sign. Convenience in business development is not the same as market representativeness. At the same time, avoid spreading only one or two stations across too many categories, because the result may be too sensitive to individual venue quality. Each venue group should be large enough to compare patterns without pretending that a small sample represents the whole market.

4.3 Assign Each Station a Network Role

Not every station should be judged only by the rentals it originates. A station with modest outbound demand may still make the network more usable by receiving returns, filling a coverage gap or increasing brand visibility. Assigning a network role before deployment helps prevent useful support nodes from being removed simply because their individual rental count is lower than that of a high-demand location.

Evaluate both the station and the surrounding cluster. A return-support node may be commercially valuable because it reduces friction for several nearby rental-demand nodes. Conversely, a high-rental station that repeatedly becomes empty may disappoint users unless the surrounding network and redistribution plan can support it.

4.4 Test the Exact Position Inside Each Venue

Restaurant, hospital or shopping centre is not a complete location record. The exact position inside the venue can materially change visibility, access and rental behaviour. A station near an entrance may receive heavy foot traffic but little dwell time; a station near a waiting area, reception desk, cashier, food court or restroom route may be noticed when the charging need is more immediate. The best position must be verified in the target venue rather than assumed from the venue category alone.

For every installation, record the position description, power source, network conditions, customer sightline, surrounding signage and a time-stamped photograph. If the station is moved, record the date, reason and expected effect. Otherwise, performance before and after the move will be mixed together and the team will not know which location actually produced the result.

4.5 Match Station Configuration to the Operating Environment

Configuration should follow the operating hypothesis. Consider expected traffic, dwell time, available floor or counter space, operating hours, power and connectivity conditions, accessibility, the need for on-station instructions, and whether the rental journey requires a screen, QR entry, contactless payment or another approved interface. The pilot should test a manageable number of configurations so the team can learn from differences without creating unnecessary technical complexity.

Document why each configuration was selected and what it is intended to prove. If a station underperforms, the team should be able to distinguish between weak demand, poor placement, unsuitable capacity, an unclear rental interface and an operational failure. Without that context, replacing equipment may hide the real problem rather than solve it.[Request a project review]

5. Complete End-to-End Go-Live Acceptance

A station is not ready for customers merely because it powers on, appears online or releases a power bank during an office demonstration. Commercial acceptance must test the complete journey under the actual merchant account, currency, pricing rules, network and venue conditions that will be used in the pilot. It must also test what happens when a step fails.

Use a controlled test plan with an expected result, actual result, evidence, owner and status for every case. Screenshots alone are not sufficient for important exceptions; retain the relevant order reference, payment status, device event, refund or reconciliation evidence and final resolution. Personal and payment data should be minimized or masked in the acceptance record.

5.1 Validate the Complete Customer Journey

Test the journey from discovery to completion: finding the station, understanding how to rent, reviewing the price and terms, initiating payment, receiving authorization, releasing the correct power bank, creating the order, returning at an allowed station, stopping billing and receiving a completion notice or receipt. Where the service supports return at a different station, test that journey in both directions between real pilot locations.

Confirm that the status shown to the user, device and administration system remains consistent. A payment authorization must not be treated as a completed rental if the power bank was not released, and a physical return must not leave an order charging indefinitely because the return event failed to synchronize.

5.2 Validate Pricing, Billing and User Disclosure

Before payment, the customer should be able to understand the applicable currency, billing unit, any free period, deposit or pre-authorization, maximum charge if used, overdue or non-return rules, and how to obtain support. The wording must be consistent across the rental page, app, station interface, receipt and customer-service materials. If more than one language is used, review the meaning in each language rather than relying only on a machine translation.

Test billing at relevant boundary conditions, including the start of billing, the transition between billing units, a normal return, an approved maximum-charge scenario and a corrected or refunded order. The purpose is not to publish a universal pricing model; it is to prove that the operator's approved pricing logic is displayed and calculated consistently.

5.3 Test Payment, Refund and Reconciliation Exceptions

Successful payment is only one test case. The acceptance plan should also cover a declined payment, user cancellation, network timeout, duplicate submission, delayed callback, authorization without release, release without a correctly created order, repeated charge concern, refund, partial or full reversal where supported, disputed transaction handling and a mismatch between the payment provider and the operating platform.

Reconciliation should follow one test transaction from the customer's payment through the payment provider, rental order and operator report. Confirm that transaction references, currency, amount, fee treatment, refund state and settlement status can be matched without exposing restricted provider data to people who do not need it. Any discrepancy must have a named owner and a documented resolution path before broad release.

Payment availability and compliance depend on the target market, merchant entity and provider approval. The pilot plan should therefore treat payment readiness as a project-specific acceptance condition, not as a global assumption based on a previous integration.

5.4 Simulate Power, Network and Device Exceptions

Test controlled loss and recovery of power and connectivity. Verify how the station reports its status, what the user sees during an interruption, whether incomplete actions are safely closed, how queued events synchronize after recovery and whether the administration system shows the correct final state. Also test a non-responsive slot, an unrecognized power bank, a failed release and a return that is physically accepted but not immediately reflected online.

The recovery process matters as much as the fault. Record whether the issue can be diagnosed remotely, whether an on-site visit is required, what evidence the field team must collect and how the case is closed. A pilot that only records the number of faults cannot show whether the future operating model is manageable.

5.5 Test Empty Stations, Full Stations and Fleet Imbalance

Simulate a rental-demand station with no available power banks and a return station with no available slot. Confirm what the customer is told, whether the system directs the user to an alternative location, and whether the operator receives enough information to act. Where return-anywhere operation is enabled, test how inventory moves across the network and how an incorrect station inventory is corrected.

Track how often redistribution is required, why it is required and how much field effort it creates. A station may be technically healthy while being commercially unavailable because it is repeatedly empty or full. Fleet balance is therefore both a customer-experience measure and an operating-capacity test.

5.6 Validate Overdue, Non-Return, Damage and Support Handling

Use approved test accounts and controlled scenarios to confirm overdue reminders, non-return rules, customer contact paths, order review, asset status and any authorized billing action. Also verify the workflow for a damaged power bank, an unusable cable, a disputed return and a device that appears in the wrong station inventory. The objective is to validate the workflow, not to create artificial charges against real customers.

Run at least one end-to-end support exercise that begins with a realistic user report and ends with a recorded resolution. It should test intake, evidence collection, ownership, escalation, customer communication, any refund decision and case closure. A support channel that exists on paper but has never been exercised is not yet part of a validated operating system.

5.7 Set a Formal Go-Live Gate

Classify every acceptance finding as closed, accepted with a documented limitation, or blocking. Safety, compliance, payment ownership, incorrect billing, uncontrolled data exposure and failures that can leave a customer charged without a usable rental should not be normalized as pilot issues. They require explicit resolution or a management decision to delay the affected function or deployment.

Request a project review

6. Standardize Venue Onboarding, Activation and Team Responsibilities

Consistent onboarding turns a collection of installations into a comparable pilot. Every venue should receive the same minimum commercial confirmation, installation record, staff briefing, customer guidance and on-site acceptance. Without a standard process, a difference in performance may reflect how well one venue was launched rather than the quality of the market itself.

6.1 Complete a Venue Readiness Record

Before installation, confirm the venue agreement, approved placement, power and connectivity, operating hours, access for maintenance, equipment security, venue contact and responsibility for routine observations. Record any restriction, such as limited access after closing, a requirement to move the station during events or a shared power outlet. These details can later explain downtime or support delays.

Create an asset record for each station containing its unique identifier, venue, exact position, installation date, configuration, software version where relevant, initial inventory, time-stamped photographs, local contact and on-site acceptance result. The record should be updated when a station is moved, replaced or materially reconfigured.

6.2 Perform the Final Test at the Actual Venue

The final acceptance transaction should occur where the station will operate, using the actual network and customer-facing materials. Confirm that a user can see the station, understand the instructions, complete the approved payment path, remove a power bank and return it successfully. Also verify that the venue staff know what they should—and should not—attempt when a customer asks for help.

Do not ask venue staff to troubleshoot restricted payment data, open equipment or make refund promises. Give them a short escalation guide: how to identify the station, what basic checks are permitted, what evidence to collect and which support channel to use.

6.3 Activate the Location Before Judging Demand

Low activity does not automatically mean low demand. The station may be difficult to see, the rental instruction may be unclear, the price may not be visible before payment, the QR entry may be obstructed, or venue staff may have moved the station away from the agreed position. The team must first establish that the location was properly activated before classifying it as a weak market.

Use consistent customer-facing materials across comparable venues. These may include a concise rent–use–return instruction, visible pricing and return guidance, supported payment indicators and a clear support route. Where venue staff are expected to introduce the service, record that operating condition rather than mixing assisted and unassisted demand.

When a location appears weak, conduct an activation audit before relocating it. Check visibility from the main customer route, access to the station, power and online status, available inventory, price and instruction clarity, QR or payment access, staff awareness and any unrecorded movement. Only then decide whether to improve, move or remove the station.

6.4 Define Responsibilities with a RACI Matrix

A pilot can be operated by a lean team, and one person may hold more than one role. What matters is that every critical activity has one accountable owner. Use RACI to show who is Responsible for doing the work, Accountable for the outcome, Consulted before a decision and Informed after an action.

This example must be adapted to the actual project. If the operator, software provider, payment provider and venue have different responsibilities, document those boundaries explicitly. Avoid shared accountability such as the team will handle it, because it often leaves refunds, outages or asset losses without a decision owner.[Request a project review]

7. Execute the 30/60/90-Day Validation Plan

Ninety days is a practical planning and review cycle, not a promise that every market can be proven or made profitable within that period. The schedule creates discipline: first stabilize the system, then compare and adjust the operating model, and finally retest the changes and prepare a decision. Seasonal demand, long-term hardware life and nationwide scalability may require evidence beyond the pilot.

7.1 Deploy in Controlled Waves

Do not activate all stations simultaneously unless the project has already demonstrated that the team can support the full release. Begin with a manageable wave across representative venue types. Close blocking payment, device, data and support issues; then release the next approved wave. The size of each wave should be determined by support capacity and readiness, not by a fixed public percentage.

Keep the planned venue mix across the waves. If the first wave contains only the easiest locations, its results cannot confirm that the broader network is ready. Each release should have a dated asset list, completed acceptance records and a clear owner for open observations.

7.2 Pre-Launch: Establish the Baseline

Before Day 1, approve the Pilot Charter, geographic boundary, venue and network-role matrix, payment path, pricing rules, data definitions, RACI, support route, acceptance checklist and deployment-wave plan. Train the internal team and venue contacts, prepare permitted spare parts and field materials, and confirm how changes will be recorded.

The baseline should show the condition at launch: which stations are live, where they are positioned, which inventory is present, which customer path is active, and which known limitations remain. Without this baseline, later improvements or failures cannot be attributed reliably.

7.3 Days 1–30: Stabilize the System and Close Critical Gaps

The first phase asks whether the service works consistently in real conditions. Monitor station online status, available inventory, completed rental and return journeys, payment and refund exceptions, order-device consistency, empty/full incidents, support cases and venue compliance with the agreed placement. Confirm that data is being collected according to the definitions established before launch.

Prioritize safety, incorrect billing, payment ownership, failed release after payment, return disputes, uncontrolled data exposure and recurring device failures. Do not hide these issues inside average performance metrics. Record the root cause, containment, owner, corrective action and retest result for each material case.

Avoid rapid expansion during this phase. Early novelty, staff-assisted rentals or an event may create activity that does not represent steady demand. The output of Days 1–30 should be a stability report and a list of conditions that must be closed or monitored before broader comparison.

7.4 Days 31–60: Compare, Adjust and Control Variables

Once critical operations are stable, compare venue categories, exact in-venue positions, network roles, customer entry paths and support workload. Review distributions rather than relying only on averages: which stations originate rentals, which receive returns, which repeatedly become empty or full, and whether activity is concentrated in only a few exceptional venues.

When changing a weak station, adjust one major variable at a time wherever practical—for example, improve signage, then observe; change the in-venue position, then observe; revise the venue or configuration only with a new dated record. If price, placement, equipment and promotion all change together, the team cannot know what caused the result.

Record both the intervention and the exposure period. A relocated station should not be compared as if it had operated in the new position from Day 1. Keep pre-change and post-change data separate, document any event or unusual traffic, and identify which result still needs a longer observation period.

The output of Days 31–60 should be an adjustment register, a venue and network comparison, an updated risk list and a small number of clearly stated hypotheses to retest in the final phase.

7.5 Days 61–90: Retest the Model and Prepare the Decision

The final phase is not a last-minute attempt to improve every metric. It is a controlled retest of the changes made during the middle phase. Confirm whether corrected payment and device issues remain closed, whether relocated or reactivated venues produce more reliable evidence, whether fleet balancing is manageable, and whether venue partners and the local team can sustain the operating routine.

Separate conclusions into four categories: validated, conditionally validated, not yet validated and requiring next-stage validation. A 90-day pilot may support a controlled expansion decision, but it usually cannot prove annual seasonality, long-term battery degradation, nationwide system capacity, long-term venue retention or performance in a different country and payment environment.

The output should be a Day-90 evidence pack that management can audit: the actual deployment list, venue and network performance, payment and reconciliation evidence, KPI definitions, exception and corrective-action register, operating workload, venue feedback, actual project costs within the approved internal scope, remaining risks and a recommended Go, Adjust or Stop decision.

Request a project review

7.6 Maintain a Fixed Operating Rhythm

The exact frequency should reflect project scale and risk, but the review rhythm must be defined before launch. Routine checks maintain service availability; weekly reviews connect field observations to data; formal phase reviews prevent unresolved issues from drifting into expansion.

Every change should answer five questions: What changed? Why was it changed? Who approved it? When did it take effect? What evidence will determine whether it worked? This simple discipline prevents a pilot from becoming a series of undocumented reactions and makes the final expansion decision more credible.

8. Build and Read the Day-90 Pilot Evidence Pack

A shared power bank pilot should end with more than a dashboard screenshot or a revenue total. The Day-90 Pilot Evidence Pack should show what was tested, what changed during the pilot, what the data can support, and which questions remain unresolved. Its purpose is to give the operator, management team, investors and suppliers one consistent basis for a scale decision.

8.1 What the evidence pack should contain

8.2 Read the distribution, not only the average

Averages can hide a weak network. A small number of high-performing venues may lift the overall result while most stations remain inactive. Review the median, the spread between venue types, weekday and weekend patterns, and the concentration of rentals and returns. Mark test orders, downtime, temporary events and abnormal traffic separately so they do not distort the result.

Do not judge every station by rental volume alone. A return-support or coverage station may produce fewer rentals but reduce full-station events, make return-anywhere service practical, and support nearby demand nodes. Evaluate the station's role in the local network before relocating or removing it.

8.3 Separate conclusions by evidence strength

8.4 What a 90-day pilot cannot prove

A 90-day validation period can reveal important operating patterns, but it normally cannot prove full-year seasonality, long-term battery degradation, multi-year merchant retention, nationwide support capacity or performance in a different country. It also cannot guarantee that future payment, regulatory or market conditions will remain unchanged. These limitations should appear in the executive summary—not in a footnote.

The final evidence pack should therefore end with a one-page decision summary: the original assumptions, the most important findings, unresolved risks, decision recommendation, conditions for the next phase and accountable owners. This converts pilot data into an auditable management decision.

9. Make a Go, Adjust or Stop Decision—and Prepare the Exit Plan

The Day-90 meeting is not a presentation meeting; it is a decision gate. The team should compare the agreed success criteria with verified evidence and choose one of three outcomes. Avoid creating a fourth category such as continue and see without a defined scope, owner or review date.

A Go is permission to scale in stages—not permission to abandon controls

When a pilot passes, convert each validated finding into a deployment standard: approved venue profile, placement rule, hardware and software configuration, payment flow, installation checklist, merchant onboarding, support process and KPI definition. Set a maximum size for the next wave and review it before entering a second city or materially different market.

An Adjust decision requires a controlled retest

Change as few major variables as possible at one time. If price, placement, payment flow and venue type are all changed together, the team cannot know which change produced the result. Record the baseline, the modification date, the expected effect and the retest window before interpreting the new data.

Prepare the exit plan before it is needed

An exit plan protects the customer experience and business relationships if the project pauses. It should define how open orders, refunds and settlement differences will be handled; how merchants will be notified; who will remove and transport equipment; how station, user and transaction data will be exported or retained; how accounts and integrations will be closed or transferred; and how assets, signage and spare parts will be reconciled. Contractual responsibilities must follow the signed agreement and applicable local requirements.

Request a project review

10. Scale a Validated Model Without Overextending

Scaling does not mean ordering more stations and distributing them more widely. It means replicating a defined operating system under controlled conditions. Before adding volume, confirm that the team can repeat venue acquisition, installation, payment onboarding, monitoring, field service, reconciliation and merchant support without losing data quality or response discipline.

Scale density before geography

In many city launches, increasing density around validated demand nodes creates more value than placing isolated stations across a large map. A denser network can improve return convenience, reduce redistribution pressure and make the service easier for users and merchants to understand. Compare the value of strengthening the current area with the cost and complexity of entering a new district.

Revalidate when a material condition changes

A successful pilot should not be copied without review when the project enters a new country, uses a different payment system, changes the user journey, adopts a materially different station configuration, targets a new venue category or relies on a new operating team. Each material change creates a new assumption and should receive its own acceptance test and decision gate.

Before approving the next wave, ask four questions: Are the validated conditions still present? Can the team support the larger network? Are payment, data and merchant controls ready for the new scope? What evidence will trigger the next Go, Adjust or Stop decision? If these questions cannot be answered, the project is adding exposure rather than building scale.

Common Shared Power Bank Pilot Mistakes

1.Testing only a few isolated devices.This can confirm basic functionality, but rarely tests venue differences or network behavior.

2.Using only one venue category.A narrow sample cannot show which demand environments are repeatable.

3.Launching before payment and refund acceptance is complete.A successful test payment is not the same as a validated transaction lifecycle.

4.Changing several variables at once.The team loses the ability to identify cause and effect.

5.Judging stations only by rental revenue.Return-support and coverage nodes may create network value that a single-station ranking misses.

6.Ignoring device moves and downtime.Unrecorded changes make before-and-after comparisons unreliable.

7.Expanding before critical exceptions are closed.Additional volume multiplies unresolved payment, support and operational problems.

8.Ending with data but no decision.A pilot without a documented Go, Adjust or Stop outcome becomes an open-ended expense.

Frequently Asked Questions

1. Is 50–100 stations a mandatory pilot size?

No. It is a planning range Bajie Charging recommends considering for operators who want to test multiple venue types and network behavior before a larger rollout. The appropriate number depends on the city, venue access, operating capacity, payment readiness, budget and future scale. A station means a rental cabinet or service point—not an individual power bank.

2. Does a shared power bank pilot have to last exactly 90 days?

No. The 30/60/90-day structure is a practical planning and review framework, not a universal rule or performance promise. Projects affected by seasonality, payment onboarding, venue access or regulatory requirements may need a different period. Define the review cycle before launch and explain any extension.

3. What is the difference between a product sample and a commercial pilot?

A sample can verify whether the station, app, payment flow and return process work in a controlled test. A commercial pilot examines real venues, real users, local payments, operational exceptions, merchant cooperation and network behavior. Passing a sample test is a prerequisite—not proof that the business model is ready to scale.

4. Should all pilot stations be deployed at the same time?

Usually, phased deployment is easier to control. It allows the team to close critical payment, software, installation and training issues before exposing the full pilot network. Keep the phases comparable and document activation dates so the reporting window remains accurate.

5. Which venue types should be included?

Select a representative mix based on the target city and business model—for example, food and beverage, nightlife, retail, hotels, healthcare waiting areas, transport or events. Do not force every category into the pilot. Include only venues the team can onboard, support and compare with sufficient consistency.

6. Which KPIs matter most during the pilot?

Use a balanced set: station availability, the user and payment funnel, successful release and return, empty/full conditions, venue activity, redistribution workload, support incidents, merchant retention and actual operating costs. Define every KPI before launch. There is no responsible universal threshold for all countries and venue types.

7. How should local payment integration be validated?

Test the complete transaction lifecycle in the target market: pricing disclosure, currency, payment approval and failure, station release, return, final billing, refund, reconciliation and exception handling. Technical connectivity alone does not confirm merchant approval, settlement availability or compliance. These must be verified for the customer's entity, country and chosen provider.

8. How do we decide whether to scale after the pilot?

Compare the pre-agreed decision criteria with the Day-90 Evidence Pack. Scale only when critical risks are closed, reliable evidence supports replication, and the team can operate the next wave. If evidence is incomplete, choose Adjust and retest; if critical risk or an unsupported operating model remains, choose Stop and execute the exit plan.

How Bajie Charging Supports Pilot Readiness

Bajie Charging can support the pilot preparation path across station hardware, OEM/brand customization, user-facing rental journeys, management software, payment integration coordination and go-live testing. The objective is to help customers define a workable project scope and verify it before larger deployment—not to replace the operator's local market, merchant, legal or financial responsibilities.

For software and localization, Bajie Charging has delivered 300+ customized apps and can support localization in up to 120 languages. Its platform architecture is designed for million-device online capacity. Actual functions, languages, deployment architecture, data requirements and acceptance criteria must still be confirmed in the project scope.

For payments, Bajie Charging maintains an integration pool covering 100+ payment channels. This does not mean every channel is immediately available to every customer. Country coverage, merchant eligibility, business entity, currency, settlement, refund capability, provider approval and technical certification must be verified before go-live.

Manufacturing and delivery support is backed by a 4,000 m² factory. After deployment, after-sales requests can be received 24/7, and eligible hardware is covered by a three-year warranty; coverage, exclusions, response arrangements and spare-part responsibilities are subject to the signed contract and the applicable support policy. These capabilities support project execution, but they do not guarantee market demand, profitability or a specific pilot outcome.

Request a project review

Related project planning pages

• How to Start a Shared Power Bank Business in 2026

• Shared Power Bank Software and App Guide

• Shared Power Bank OEM Supplier Due-Diligence Checklist

• Shared power bank hardware configurations

• Rental software and App platform

• Local and cross-border payment integration

• Go-live and after-sales support

Recommended information for a pilot readiness review

• Target country, city and intended launch area

• Planned pilot quantity and longer-term deployment goal

• Available venue types and confirmed venue resources

• Preferred rental journey: app, H5/QR code, POS/NFC or a combined pathAppH5/POS/NFC

• Required local payment methods and current merchant-account status

• Branding, language, software and data requirements

• Target schedule, project team and local support resources

Request a Shared Power Bank Pilot Readiness Review

Conclusion: Turn the Pilot into a Decision System

A successful shared power bank pilot is not the one with the most optimistic chart. It is the one that produces reliable evidence, closes critical exceptions and makes the next decision clear. Define the assumptions before procurement, validate the complete user and payment journey, compare venues and network roles, record every material change, and end the 90-day cycle with a documented Go, Adjust or Stop decision.

The real value of a 50–100-station pilot is not the number itself. It is the ability to turn a proposed business model into a tested operating standard—one that management can scale deliberately, adjust with evidence or stop before unresolved risk becomes expensive.

Requestable planning resource:Shared Power Bank 90-Day Pilot Validation Scorecard

Includes the Pilot Charter, readiness checklist, deployment register, go-live acceptance checklist, KPI dictionary, issue log, Day-90 Evidence Pack and Go/Adjust/Stop decision sheet.

Share your target market, venue plan, payment requirements and pilot scope with Bajie Charging to prepare a project-specific readiness review.

July 27, 2026