Simon Manley

An online booking system for my website

I wanted a real-time booking system for my website — something that would talk to a live calendar and show available slots in my workshop on the fly.

Running my sites on WordPress means having access to a massive plugin ecosystem. But while there are plenty of off-the-shelf booking tools I could have shoehorned into place, I hated the compromises they forced on me. They were either bloated, rigid, or didn’t handle data the way I wanted.

The only real solution was to build one from scratch — right now, I have the luxury of time while preparing to open my new workshop. Ordinarily taking on a project like this wouldn’t have been an option.

What’s the goal?

My requirements were straightforward, a customer should be able to book their vehicle in for a service or repair seamlessly, without needing to pick up the phone. They should automatically receive a confirmation email, complete with a secure link to make amendments or cancel if circumstances change.

As simple as that initial concept sounds, the moment I started mapping out the logic, the rabbit hole deepened. I realized just how many moving parts I had to account for to make it robust:

• Data footprint: How much info do I actually need from a customer without making the form exhausting?
• The backend stack: Writing the core PHP scripts to process requests and pairing them with clean JavaScript to make the user interface smooth.
• Capacity control: Capping the maximum number of daily bookings so I don’t accidentally swamp the shop.
• Scheduling windows: Defining how far in advance someone can book. 30 days? A full year?
• Security: Protecting the endpoints from relentless spam bots.

Then came the logistical rules that every shop owner has to wrestle with:

• Can someone book a slot for the same day?
• Is there a hard afternoon cutoff time for booking a slot for tomorrow morning?
• What is the cancellation threshold before a booking is locked in?

Collecting Information

It’s a delicate balance. As a diagnostician, I want as much data up front as possible. But as a web user, I know that massive, multi-page forms are friction points that make people abandon the page.

The goal became minimizing the input fields to keep it lightning-fast, while still capturing the critical vehicle specifics needed to ensure I don’t order the wrong parts before the car hits the lift.

Choosing a calendar

Normally, I live out of Google Calendar — it syncs across devices and works flawlessly on mobile. However, embedding or syncing it directly with the site’s front-end introduced a bottleneck. The API calls slowed down page rendering; it took too long to pull and calculate open slots in real time.

I also wanted tighter control over the presentation and notification behavior. I ultimately bypassed Google entirely and integrated calendar.js. It’s incredibly lightweight, renders instantly, handles pre-booked slots locally, and gives me full remote access from my phone or any browser where I can log into my WordPress dashboard.

Email handling

Reliable transactional email is non-negotiable for a booking system. I configured the system to route notifications through the Gmail API. It’s exceptionally robust, maintains high deliverability rates, and keeps crucial confirmation and amendment links out of the customer’s spam folder.

Growing into a garage management system

This is where scope creep became a beautiful thing. Once the basic booking functionality was working, I saw the broader potential. If a customer is already feeding the database their vehicle details and a description of the issue, that data shouldn’t just sit in an email — it should be the foundation of a live job card.

Now, when a car is in the workshop, I have the customer’s exact notes right beside me digitally. From there, I built out a clean, checkbox-driven digital service card to tick off inspection items and log defects as I progress through the physical work.

Suddenly, the job card transformed into a unified workspace combining customer intake, active diagnostic checks, and a running parts list. Naturally, the next evolutionary step is integrating the invoicing engine.

Expanding into invoicing means expanding the background architecture. I’ve begun building out a custom parts database, separating diagnostic labor tiers, and factoring in localized sales tax rates. The ultimate output is a comprehensive, multi-page PDF summary — spanning across all service sectors — that can be printed or emailed straight to the client.

The Ultimate Diagnostic Knowledge Base

As the job card infrastructure solidified, I realized I had the perfect foundation for something I’ve wanted for years: a completely proprietary Diagnostic Trouble Code (DTC) and Technical Service Bulletin (TSB) system.

Think of it like a professional scan tool database, but customized with my own institutional knowledge. When a specific fault code pops up on a vehicle, the system doesn’t just pull up a generic definition — it surfaces my own historical notes, scope waveforms, and fixes from when I solved that exact issue in the past.

I quickly moved from a simple text-based data structure to a relational setup capable of handling rich media. If a code is queried, the system displays the core fault definition alongside a dedicated section for uploaded scope screenshots, scanner logs, factory wiring diagrams, and downloaded PDFs.

I’ve already migrated a massive amount of historical data into the system, and parsing through years of handwritten work notebooks is an ongoing project. But the beauty of this self-hosted setup is its organic growth — it’s designed to scale as I work, becoming exponentially more powerful with every complex diagnostic job I close out.

While I still love the tactile feel of scratching down initial diagnostic thoughts in a notebook with my Fisher Space Pen, those records are now scanned to PDF and preserved permanently in the database. What started as a simple web calendar has evolved into the central brain of my workshop’s operations.

As of now it’s in place at https://smauto.net/booking/ on initial testing.