A chauffeur operations system that keeps people in control

Define the job of a chauffeur operations system

Map a booking before choosing screens. Who checks the request, makes the assignment and owns a cancellation? If staff disagree, adding features will digitise that disagreement. Start with an agreed handover and a reliable source for the current instruction. The services overview helps distinguish a public enquiry website from an internal operating tool.

The example here is an internal MVP covering generic bookings, assignment, permissions and manual WhatsApp link generation. It is not a customer case study or evidence of operational results. The detailed controls below are proposed acceptance requirements, not a claim that every capability has been implemented. Live tracking, payment processing and route optimisation are outside the demonstrated scope. Choose the decision a supervisor needs to make, then identify the minimum supporting functions.

Agree on the booking record and state changes

Specify the minimum useful record: a booking reference, service time and timezone, necessary meeting information, request type, current state and responsible owner. Separate concise operating instructions from sensitive notes. Do not collect identity documents simply because a form could accommodate them. Prototypes and demonstrations should use entirely synthetic records, not lightly disguised customer data.

Draft, confirmed, assigned, completed and cancelled are possible states, not a ready-made policy. Define who may move between them and what evidence is required. Opening a message cannot establish driver acceptance. Ask how a correction appears to the next person on duty, and how cancellation reasons are retained under the agreed retention policy. Clear definitions matter more than coloured status badges.

Keep assignment and reassignment accountable

A coordinator needs to check availability, vehicle suitability and realistic time between commitments before assigning a driver. In this proposed scope, that is a manual operational check, not an assertion of automatic conflict detection or live routing. Decide who can approve an exception and how the reason should be recorded.

Reassignment creates another responsibility: someone must inform the previous driver as well as the replacement. Changing a name on a screen does not retract instructions already sitting on a phone. Specify who owns that communication and where the current assignment is verified.

For production, request handling of concurrent edits, a clear warning when a record has changed and an appropriate change history. These controls require implementation and testing; they are not implied by a polished internal demonstration. Include a shift handover in acceptance testing so unfinished decisions cannot disappear between coordinators.

Set access rules around necessary information

Propose a role matrix before granting accounts. A supervisor administers access, a coordinator handles authorised bookings, and a driver sees only information needed for assigned work. Agree separately on viewing addresses, exporting records and cancelling requests. Hiding a button is not access control: production permissions must be enforced server-side and tested through direct attempts to access an unauthorised record.

Trip details can reveal sensitive personal routines. Explain the collection purpose, permitted users, retention period and correction or deletion process under applicable obligations. Permission to coordinate a journey is not blanket marketing consent. Include staff departure and access recovery in handover procedures.

Use test identities for these checks. If analytics are added later, keep booking details and contact information out of events, and define consent requirements before enabling non-essential tracking.

Understand the manual WhatsApp boundary

A generated link does not send a message. A person selects the recipient, prepares brief text, opens WhatsApp, checks the number and content, and presses send. Opening the link proves neither delivery nor reading nor acceptance of an assignment.

This internal MVP has no official WhatsApp API integration and does not use WhatsApp Business Platform. Automated sending, scheduled messages and automatic delivery or read receipts are not implemented. A later official integration would need separate scope, approvals, access policies and operating-cost decisions. It is not an unstated feature of the current button.

Keep prefilled text minimal because link contents may be copied or retained in history. Do not embed customer identities, detailed addresses or secret access tokens. Confirm the recipient and appropriate consent for the channel. Avoid groups that expose trip information to people who do not need it.

Rehearse an exception with fictional records

Entirely fictional scenario, not a customer incident: a coordinator creates a test booking, assigns a test driver and prepares a WhatsApp link. The requested time changes before sending. The coordinator must review the record and message again; the previously prepared link does not know that the booking has changed.

If the driver also changes, nominate someone to contact both parties manually and verify the authoritative instruction. If the booking is cancelled, test how that decision remains understandable rather than simply clearing it from view.

Now rehearse a connection failure. Who holds the approved follow-up list, and how will changes be reconciled afterwards? These are design questions, not claims of implemented offline synchronisation. Real identities and invented performance figures are unnecessary for finding contradictions in a workflow.

Write observable acceptance checks

Ask the supplier to mark each requirement as demonstrated, proposed or excluded. Apply the same distinction when reviewing work examples; an internal demo is not proof of live customer operations.

• Create and correct a test booking, checking required fields and errors.
• Assign and replace a driver, identifying the communication owner each time.
• Test each role, including an unauthorised direct-access attempt.
• Open a WhatsApp link without recording a fictional sent or delivered status.
• Rehearse concurrent edits, cancellation and shift handover against agreed requirements.
• Specify data ownership, export, backup and restoration, identifying unfinished capabilities.

Pilot a limited workflow with synthetic data before approving production use. Do not substitute promises of eliminating every mistake or unmeasured time savings for testable acceptance criteria.

Choose a scope rather than a feature label

Tech Corners Establishment is based in Jeddah and was founded by Zeyad AlQahtani, a software engineer and University of Jeddah graduate. A website that receives enquiries and a system that coordinates staff are different deliverables.

• Launch: a scoped brochure website from 1,000 SAR, delivered in days depending on scope and content readiness; not an internal operations system.
• Growth: a broader custom-designed website with agreed growth requirements, from 4,500 SAR, with a planning window of 3–5 weeks.
• Systems: a custom system or app MVP with agreed functions, from 15,000 SAR, with a planning window of 6–12 weeks.

Review the packages and document permissions, integrations, handover, support and recurring costs. A free prototype explores the main workflow with test data; it is not a free production system. Discuss your workflow or browse the journal. For the journey before a booking arrives, read the guide to local visibility for Jeddah businesses.