Fleet bike list
Every bike on the account shows its serial, status and battery health in one list.
A delivery company running a fleet of e-bikes needs to know which bikes are down, which batteries are due a test and which repairs are waiting for approval. SIZ Group builds a customer portal for electric bicycle repair shops that keeps those records in one secure place for fleet managers, campus staff and individual riders.
A fleet of delivery bikes creates a steady workload for a small shop. Bikes go out in the morning and come back with a flat, a sticky brake or a battery that drained overnight. The fleet manager needs to know which bike is off the road and when it will return, and that answer can change several times in a single day.
Battery records make this trade different from a typical repair desk. A pack carries a charge history, a capacity test result and a replacement date, and a repeat failure often traces back to a charger or a usage pattern rather than the bike itself. Keeping that history beside each serial number helps the shop spot the pattern before the fleet loses another rider's shift.
Campus fleets and property managers share bikes among many people, so the portal needs a way to show who reported a fault without exposing personal details to the whole group.
The operations manager wants fewer status calls and clearer approvals, and will judge the portal on whether a bike can be tracked from fault report to return without picking up the phone. The portal should show the fault report, the approved work, the parts status and the expected return date for each bike.
A demo should walk through a single bike from report to invoice, and show how a delivery lead approves a repair within a set spending limit. It should also show what the operations manager sees across the whole fleet on one page, since that view is where the planning happens.
A fleet manager opens the portal on a phone at the start of a shift and sees a list of bikes, with a red status on two of them. She taps the first bike and sees the battery test from last month, the fault a rider reported that morning and a note that a controller has been ordered.
She approves the estimate with a note that the repair should wait until the controller arrives, and the portal confirms the approval to the shop. Later she downloads the month's invoices filtered by serial number, and the accounts team pays from the same record without asking for a second copy.
Every bike on the account shows its serial, status and battery health in one list.
Riders or leads report a problem with a photo, and it attaches to the right bike automatically.
Estimates can be approved in one tap, within the spending limit set for each approver.
Capacity tests, charge cycles and replacement dates sit with each pack for long-term tracking.
Invoices break down labor and parts by bike, so the accounts team can match each charge to a return.
Each bike shows an expected return date that updates when a part arrives or a test is complete.
Demand for fleet repairs tends to climb as daylight lengthens and riders put in more miles, and it eases in the coldest months when bikes sit in storage. The portal should be ready for the spring and early summer peak, when more bikes return with worn brakes, tires and batteries that have been worked hard.
Campus fleets slow down during term breaks, and a property manager may hold bikes back until a new tenant arrives. The portal can show a seasonal calendar for each account, so the shop and the customer both know when a return surge is likely, and it can flag bikes that have sat unused for a long stretch.
The shop needs an account list, the bikes on each account by serial number, and the battery records it already holds. Each bike should have its model, motor type, battery pack and any past repairs, even if some of that history currently lives in notebooks or in a spreadsheet kept on the bench.
Roles and approval limits need to be agreed too. A delivery lead might approve routine tire and brake work, while battery replacements go to the operations manager. Payment terms and invoice contacts should be recorded per account so the portal sends the right document to the right person.
Watch how many repairs are approved in the portal instead of by phone, how many bikes return to service and how many status calls reach the front desk in a day. Those are operational records the shop already keeps, so the baseline can be set before launch.
Repeat battery failures and average days off the road are also worth tracking, because they show whether the records are helping the shop prevent problems. If repeat failures fall, the portal has moved the shop from reacting to planning.
Yes. A small group can have one account with a few bikes and one approver, and the portal stays simple. The fleet features are there when they are needed, not forced on an account that only needs a single repair.
Only the people the shop has given access to. A delivery lead can see the bikes they manage, while accounts staff see invoices. The shop decides what each role can view, and battery records can be limited to approvers.
The report can be submitted through a link the shop sends, with the bike serial and a photo. The report is attached to the bike, and the fleet manager sees it in the same list as the other bikes on the account.
Yes. The portal can display the charging and storage guidance the shop gives its customers, and it can show a warning when a bike is flagged for a battery problem. The shop writes the wording, so it matches its own procedures.
It can hand invoices and payment records to the accounting tool the shop already uses. The portal does not change the accounting itself. It keeps the customer copy of each invoice in one place.
Tell us how your fleets, approvers and battery checks work today, and we will plan the portal around them. The proposal comes with a written scope and price.