Planning a Shared-device Project: 8 Questions Before Development
Clarify venue, hardware, billing, payment, operations, and acceptance boundaries before building a shared-device service
Start with the operating problem
Shared-device projects often begin with “we need a QR rental system.” The real outcome, however, depends on where equipment is placed, who maintains it, where users return it, how exceptions are resolved, and how revenue is settled.
Before development, align the project team around the following eight questions. They directly influence hardware, platform architecture, implementation schedule, and commercial scope.
1. Where will devices operate?
Hospitals, malls, scenic areas, and transit hubs have different traffic, networks, power, opening hours, and venue rules. Define the first venues, indoor or outdoor conditions, local connectivity, and whether equipment can move across zones.
Choose a representative pilot site and complete the full user, device, and field-operations workflow before defining rollout standards.
2. Who supplies and maintains the hardware?
For existing hardware, prepare communication protocols, state definitions, commands, error codes, upgrade methods, and test units. For new hardware, align enclosure, power, communication, lock control, and production testing.
Also define where software support ends and when the hardware vendor or field team becomes responsible.
3. How does a service start and end?
A typical journey includes scan, sign-in, authorization, payment, device execution, usage, return, and settlement. The critical details vary: power banks require slot and battery recognition, wheelchairs require return-zone rules, care beds need overnight billing, and amusement equipment needs positive start confirmation.
Define success, failure, timeout, and user cancellation at every step.
4. Are billing rules complete?
Clarify starting price, free period, billing unit, cap, packages, cross-day rules, and discounts. If deposits are involved, define no-deposit eligibility, refund timing, and exception handling.
Keep pricing configurable in the platform rather than hard-coded into devices or applications so venues can operate different strategies.
5. Which parties are involved in payment and settlement?
Beyond user payment, consider refunds, reconciliation, merchant revenue, platform fees, and settlement cycles. Hospital departments, venue operators, agents, and equipment owners may need different data scopes and revenue rules.
Map the movement of funds and order-state transitions early to prevent later differences between financial and system definitions.
6. Which operating roles are required?
Common roles include headquarters, regional operations, venue managers, merchants, customer service, and field technicians. Define which devices, orders, and reports each role can see and which actions it can perform.
Remote unlock, refunds, price changes, and bulk upgrades need stronger permissions and audit records.
7. Who detects and resolves exceptions?
List the failures that most affect service: offline devices, payment without execution, failed return, low inventory, lock faults, and orders that never close. The platform detects and alerts, customer service handles user communication, and field teams resolve hardware issues. The escalation path must be explicit.
Test exception workflows during pilot acceptance rather than testing only the happy path.
8. What defines a successful pilot?
Acceptance should cover more than feature completion. Include technical, business, and operations metrics such as online rate, rental success, payment-to-execution success, incident closure time, complaint rate, and field inspection workload.
A recommended delivery rhythm
- Discovery and site survey: confirm workflows, device conditions, and responsibilities.
- Minimum closed-loop integration: connect payment, command, order, and return on a few devices.
- Live pilot: validate connectivity, traffic, and field operations in a real venue.
- Data review: improve the product based on success rates, incidents, and feedback.
- Scaled rollout: standardize device configuration, deployment checklists, and training.
The objective is not a one-time software delivery. It is a repeatable operating system. The earlier teams clarify field responsibility, exception handling, and data definitions, the easier the rollout becomes. Compare delivery scopes for shared power bank systems, shared wheelchair systems, and shared care bed systems.
