How Veloworx works in practice
The homepage shows what changes in your day. This page shows how it is built: how planning works, what is kept on the job, what the customer sees of it, and what comes out at the end of the month.
Chapter 1 · Planning the booking
Veloworx plans in capacity, not in time slots.
That is the difference to an ordinary appointment calendar. Four inspections and one major service are not the same as five inner-tube changes, even though both are five appointments. A grid of equally sized slots cannot represent that, which is why it ends up either overfull or half empty.
You record how long each service takes per bike type, and set how much work may come in per day. What the customer is offered as an available appointment is calculated from that.
- Your own service catalogue with a duration per service and bike type
- Capacity per day instead of a rigid grid
- Booking and cancellation deadlines you set per service
Chapter 2 · Intake and work
From intake on, every job has a state.
At intake you record the bike, the job and what was agreed, all in one place. From then on the job has a state everyone can see, and Veloworx records every change automatically.
Nobody has to reconstruct what happened to a bike any more. It is on the job.
- Status from booked through in progress to ready for pickup
- Internal comments on the job itself, from a computer or a phone, by voice input if you prefer
- Automatic history: who changed what and when, without anyone keeping minutes
- Time tracking per job, the basis for the planned-versus-actual comparison in reporting
Mobile, as evidence rather than a claim
Comments, status changes and time tracking work on a phone exactly as they do on a computer. This is not an extra for the road, it is the normal case: most entries happen at the bike, not at a desk.
Chapter 3 · Coordination with the customer
What was agreed sits on the job.
The customer's answer to a question or an approval does not land in someone's inbox. It lands on the job, timestamped and readable by everyone on the team.
That answers the question asked most often on a workshop floor: what exactly did we promise this customer? Whoever picks the job up does not have to ask anyone.
- A status page for the customer, no account and no password
- Questions and approvals documented on the job, with a timestamp
- The customer can write from there, and the message lands on the job as well
- Feedback after pickup and inspection reminders, switchable per workshop
Channels
Notifications go out by email. SMS and WhatsApp follow through the same platform.
Chapter 4 · Planning
Planning beyond the single day.
The month view shows, for every day, how much capacity is already committed and how much is still open. That lets you plan weeks ahead instead of discovering each morning what the day brings.
For days with a lot of drop-offs and pickups there is a dedicated view showing when things come in and go out.
- Month view with utilisation per day
- Dispatch view for drop-off and pickup
- A view per role: intake, workshop and management each see what they need
Chapter 5 · Reporting
Numbers that come out of the work itself.
Veloworx evaluates what accumulates anyway: planned and actually needed time, labour units, parts revenue. There is nothing extra for you to record.
That answers the questions at the end of the month that otherwise stay a gut feeling. How full was the month really? Did we misjudge our time estimates, and where?
- Evaluation by day, week and month
- Planned versus actual per job and per employee
- Billed labour units per hour
- CSV export, plus a print view
The planning improves by itself
From the recorded actual times, Veloworx proposes more realistic estimates. The longer you use it, the more accurately it plans. And the less often work is left over in the evening that would have fitted into the morning.
In progress: evaluation by service and by capacity segment. In other words, which type of appointment actually pays off.
Chapter 6 · Security
The server decides who may see what.
Access rights are not a question of the interface at Veloworx. A mechanic is not shown their colleagues' jobs because those jobs are never delivered to their device in the first place. What you cannot see is not hidden, it is not there.
- Role-based access rights, enforced server-side
- Encrypted data transfer
- Continuous updates to the systems in use
- Designed for GDPR compliance, with all service providers inside the EU
Security as ongoing work
Security is not a checkbox you tick once. We keep the systems we use current, choose service providers carefully, and assign responsibilities clearly.
Chapter 7 · Embedding
Booking runs on your own website.
Your customers stay where they already are. Booking is either its own page under your address, or a widget in the middle of your existing website. No second presence, no third-party portal, no break in the flow.
The widget picks up the fonts and colours of your site and grows with the space you give it. It goes in with one line of code, and your agency handles the rest in a few minutes, or you do it yourself.
- Your own booking page under your address, or a widget in your existing website
- Look and colours adapt to your visual identity
- Installed with a short embed snippet, no rebuild of your website
- Works on a phone exactly as on a computer