One owner-led service business, three years in use
A website, CRM, staff workflow and customer lifecycle built as one system.
The business has a team, consultations, deposits, multi-step client work and repeat visits. Its website, forms, conversations, calendar, payments, staff tasks and customer follow-up used to require people to carry information between systems. I built the missing connections and business rules, then kept extending them as the operation changed.
The business name and industry are withheld. The workflows and figures are real, taken from the systems in use.
Each tool worked on its own, while the handoffs still depended on people.
Enquiries arrived through calls, forms and social messages. Appointments lived in a calendar, payments in the till, client details in the CRM, and several staff members handled different parts of the work. Each tool could do its own job, but the next action still depended on somebody noticing a change and carrying the information across.
The pieces run as one system the owner can rely on
Every source feeds one event and data layer. Business rules read that layer and decide what happens next, whether that is a CRM update, a staff task, a customer message or a report.
Technical implementation
Digital front door
A custom Next.js website, built and owned outright
A custom CMS and admin dashboard for day-to-day edits
Pages, sections, blog, media library and navigation, all editable
Image processing built into the upload path
Booking, consent, intake and feedback forms
Dual delivery on every form: webhook first, email as a fallback
SEO: metadata, structured data and a sitemap
Enquiry and booking operations
Contact matching and source retention on every enquiry
One queue for new work, so nothing sits unassigned
Forward-only stage movement, never backwards
After-hours acknowledgement while the business is closed
Stale lead detection before a lead goes cold
Conversation-aware human tasks, read from the real thread
Consultation follow-up when a consult never became a booking
Deposit checking against the calendar and the till
No-show recovery with a rebooking message
Daily and morning briefs for the team
Event-driven customer care
Pre-service email based on the actual booking
A durable wait, then a status re-check right before the send
Cancellation and time-window conditions that stop a send outright
Aftercare triggered by a completed cashout and the service type
Review request held to quiet hours, with a cooldown against repeat asks
Email status tracked through delivered, opened and clicked
Terminal handling for unsubscribed contacts and contacts with no phone number
A loyalty offer with rules, timing and an audit trail.
An eligible completed transaction can issue one single-use code. The code has a delayed activation date, a six-month expiry and a reminder before it expires. A database constraint prevents more than one active code for the same customer. A redeemed code does not immediately create another one, so the program cannot turn into a permanent discount on every visit.
The issuance email is recorded against the code. Delivery, open and click events move the email status forward in the admin system, while negative states remain visible. Expiry, redemption and reminders are written to an audit trail. Feature flags can stop issuance or messaging without dismantling the rest of the workflow.
Safeguards
Eligible transaction check
Service and touch-up exclusions
One active code per customer
Anti-loop rule after redemption
Delayed activation
One-shot expiry reminder
Idempotent issuance
Audit records
Email engagement state
Staff support and content operations
A shared task queue, not one employee's personal list
Staff-facing AI assistance that never messages a customer directly
Finished work can become approved content
Image cleanup, caption, crop, alt text and publishing, handled automatically
Staff approval required before anything cross-posts
Idempotency that prevents the same post publishing twice
Reporting
Source attribution on every customer
Revenue written back onto the record from completed sales
Response time, conversion and automation actions, tracked together
A monthly report, not just a live dashboard
LTV, CAC and a guarded LTV:CAC ratio
Signed report links instead of open dashboards
On-demand delivery as a PDF or through Telegram
Data backfills run with a dry-run, validation and API throttling
The exception handling is part of the build.
A retryable failure is told apart from a reason the action should be skipped
Duplicate protection works between runs, not just within one
Quiet hours are recalculated right before a send, not just when it was queued
Long waits end by re-checking the real status, not by assuming nothing changed
Failures that survive retries generate an alert instead of failing silently
Tasks have timeouts and bounded external calls
A dry-run is used before a new sweep is turned on
Automated and human activity are not treated as the same signal
Three years of numbers
Not one good month picked out. This is the whole run, from the business's own records.
What the system did in a single month
A missed call at 12:00. An automatic text back by 12:02. Nobody at the front desk touched it, and the customer replied within the hour instead of calling the next business.
Reviews, tracked end to end
These figures describe the business in which the system operates, not a claim that software alone produced every sale, customer or review. The system handles consistency, response and follow-up, while the offer, demand, owner and team still determine the result.
You do not need all of this at once.
The first project should fix one workflow that repeatedly loses time, money or customer trust. The scorecard will help identify which one.
Check your bottlenecks