What we built, and what it moved.

On the customer side, that meant slow quote-to-booking cycles, repeat calls for the same trip details, and no consistent way to handle anything beyond a standard route. A corporate client asking for a multi-stop move with timing constraints would sit in a queue while someone manually checked vehicle availability, driver hours, and pricing.

On the manager side, leadership was flying blind in patches. Utilization lived in one report, on-time performance in another, and customer complaints in a shared inbox nobody owned. Depot managers had local workarounds. HQ had weekly slides that were already stale by the time they were presented.

Feedback was the other leak. Post-trip surveys went out manually — sometimes. Responses came back days later, if at all. By the time someone flagged a recurring issue with a route or a driver, the pattern had already cost them repeat business.

They didn't need a flashy platform. They needed customer workflows that could run without constant hand-holding, and a single place where managers could see what was actually happening across the fleet.

We split the work into two tracks that had to stay connected: customer-facing automation on one side, and managerial visibility on the other.

L1 handled the high-volume, predictable stuff: trip requests with fixed parameters, status lookups, reschedules, and basic availability checks. If a customer already gave origin, destination, date, and load type, the system moved the booking forward without a human retyping it.

L2 picked up everything L1 couldn't safely close: multi-leg routes, contract pricing exceptions, tight delivery windows, and fleet reallocation. It didn't try to replace dispatch judgment — it gathered context, ran checks against vehicle and driver constraints, and handed managers a ready decision, not a blank form.

We built a dashboard around metrics the operations team already cared about, not vanity numbers: OTIF (on-time in-full) by route, depot, and customer segment; fleet utilization; deadhead ratio; quote-to-booking time; first-contact booking completion; and CSAT with complaint recurrence tied back to specific routes and time windows. Every view was meant to answer a decision — reassign capacity, fix a problematic route, coach a depot, or repair a broken handoff.

We automated post-trip feedback collection and routing. Responses were tagged by trip, vehicle class, and depot. Negative signals triggered review queues instead of dying in a spreadsheet, and recurring themes — late arrivals on a corridor, loading delays at a recurring pickup — surfaced weekly without anyone combing through forms.

Booking-desk load dropped enough that the same team could handle roughly 2.3× inquiry volume without adding headcount. Depot leads moved from stale end-of-week slides to using the dashboard daily for morning standups. The bigger shift was cultural: customer issues stopped disappearing into individual inboxes, and feedback actually looped back into scheduling and route planning.

Managers kept project context in WhatsApp threads, email chains, and site-visit notes. The lab team got updates late or not at all — a concrete-mix question needing a same-day answer would sit until someone forwarded a screenshot. When a supplier delay hit, the site found out after crews were already mobilized.

Project knowledge existed — drawings, BOQs, approval history, vendor quotes, site logs — but it was scattered. A junior engineer asking "what did we finalize for façade spec on Block C?" meant paging three people. Senior managers had no lightweight way to check alignment without calling a meeting.

On the business development side, the team was drowning in opportunity noise. Tender notices arrived from portals, contacts, and forwarded PDFs. Qualifying a lead meant manually opening documents and guessing fit. Good opportunities were missed because they arrived late; weak ones ate prep time anyway.

The slowest part of bid prep was always the same: getting from 2D tender drawings to a usable quantity position. Someone had to sit with architectural and structural sheets, run manual takeoffs, and build a draft Bill of Quantities before pricing could even start. Off-the-shelf tools existed, but none matched how this company structured BOQ sections, described line items, or handed work from BD into estimating.

We approached this as three connected systems — live project coordination, upstream business development, and a custom drawing-intake layer that fed the BD desk.

AI workflows sat across the conversation and data layers, not inside a dashboard nobody would check on site. When a manager flagged a spec question or approval blocker, the workflow pulled relevant context and routed it to the lab queue with the right background attached — not a bare "please advise." Material-chain triggers linked BOQ line items to procurement status and site readiness, so a slipped cement delivery on a job with a pour in 48 hours escalated to the site lead and procurement instead of waiting for a weekly call.

A tiered-access knowledge base let anyone query by role and depth — a supervisor pulling today's approved drawing revision, a PM pulling full change history — with answers tied to indexed source records, not chatbot fluff. It deployed on WhatsApp, because that was already where managers, engineers, and coordinators talked. No new login, no training deck.

The engine continuously ingested market signals from public and licensed sources, normalized them into one opportunity feed, and scored each lead for fit against active sectors, geography, project size, and delivery capacity. Duplicates were collapsed and low-fit noise filtered before it hit anyone's desk. Each qualified opportunity arrived as a structured brief — scope summary, key dates, contract band, compliance flags, relevance score — so BD managers worked a daily prioritized queue instead of a raw dump. The team still made every bid/no-bid call.

A custom drawing-intelligence tool, tuned to this company's measurement conventions, read 2D tender sheets, identified measurable elements by trade section, and ran automated takeoff against their BOQ structure — substructure, superstructure, finishes, MEP allowances, external works — with standard units and descriptions aligned to how their bills are normally issued. Output was a draft BOQ ready for QS review, a takeoff abstract, and a scope summary. When a qualified tender landed with drawings attached, the workflow kicked off automatically and produced a full tender-intake bundle, so estimators started from a reviewed draft and spent their time on rates, risk, and exclusions — the work that actually wins or loses a bid.

Site teams stopped treating the lab as a black box. BD went from reactive inbox-clearing to working a ranked pipeline — fewer random leads, more time on winnable ones. The drawing tool didn't replace the quantity surveyor; it removed the blank-page problem. Bid meetings started with quantities on the table instead of a promise to "have the BOQ by Thursday."

The workforce was all over the map: drivers with high turnover, dispatch coordinators on rotating shifts, sales reps onboarding every quarter, and a small technical team keeping the platform alive. Everyone touched the ERP differently, and almost nobody had a clean path to learn it. Three problems kept showing up.

ERP complexity at the field level. Drivers and floor staff struggled with fueling and fleet modules — wrong entries, missed steps, duplicate logs. A bad fuel-stop record didn't stay a training issue; it showed up as dispatch delays, reconciliation headaches, and compliance flags downstream.

Training ate senior time. Experienced sales managers and ops leads hand-held new hires through playbooks and walkthroughs for hours every week — time taken directly out of revenue work and route planning.

One manual for everyone. Static PDFs and slide decks treated every role and pace the same. Sales reps skimmed, drivers never opened them, technical staff needed depth the manuals didn't have. Engagement was low and performance inconsistent across depots.

We built a custom AI-augmented learning platform that worked as a 24/7 tutor — role-aware, source-backed, and tied to how the company actually operated.

We indexed the full internal library — ERP manuals, module guides, sales playbooks, safety protocols, dispatch SOPs — into a retrieval-backed Q&A layer. Employees could ask plain questions like "How do I log a fuel stop?" and get step-by-step answers with source references. If the answer wasn't in the knowledge base, the system said so — which mattered on compliance-sensitive workflows.

Different curriculum tracks by function: sales got outreach simulations and CRM/playbook drills tied to their real motion; drivers got interactive ERP navigation and fueling-compliance walkthroughs on mobile-friendly modules; technical staff got deeper maintenance, troubleshooting, and escalation paths. Same platform — different entry point, depth, and certification bar.

The system tracked where each user struggled in real time — failed items, repeated help requests, slow steps — and adjusted difficulty, surfacing extra practice when someone stalled on fuel logging or dispatch handoffs. Fast movers weren't forced through remedial slides; people who needed reps got them without waiting for a manager to notice.

Tests were generated from the same source material, scored instantly with qualitative feedback on gaps rather than a bare pass/fail. Leadership got a readiness dashboard — completion by role, module-level weak spots, certification progress, and heatmaps of where live-ERP errors still clustered after training. The loop closed between what we taught and what still broke in production.

Onboarding shifted from a manager-led bottleneck to a mostly self-serve path with checkpoints. Drivers cleared ERP certification before their first solo route instead of learning through mistakes, and training became something people actually used mid-shift when they hit an edge case — not a one-time orientation event.

Requests came in everywhere: tenant emails, WhatsApp voice notes to the building supervisor, front-desk scraps, calls straight to contractors who'd worked the building before. The same AC fault could get reported three times through three channels before anyone treated it as one incident.

Leases didn't help. HVAC response times differed from plumbing; common-area issues followed another clock; some retail tenants had after-hours clauses, office tenants didn't. PMs kept PDF lease extracts in personal folders and guessed at obligations under pressure. Breaches surfaced when tenants threatened to withhold rent — not when the clock actually started.

Contractors often showed up blind: no fault history, no prior ticket on the unit, no record of the part replaced six weeks ago on the same floor. Repeat callouts were common, and so were disputes over who was responsible — landlord, tenant fit-out, or shared services.

They didn't need a tenant-facing app tenants wouldn't use. They needed intake that respected lease terms, stopped duplicate chaos, and gave PMs a live picture of what was breaching, what was about to breach, and what kept breaking in the same units.

We built a maintenance SLA engine that sat between tenant intake and contractor dispatch — lease-aware, channel-agnostic, and tied to unit history.

Requests were normalized from email, WhatsApp, web forms, and front-desk entry into one ticket structure — building, unit, category, urgency, tenant contact. Voice notes and messy messages were parsed into structured fields with a human confirm step when confidence was low. Duplicate detection ran against open tickets on the same unit and category, so three reports of one leak became a single incident with a timeline, not three dispatches.

Each unit was linked to active lease terms. When a ticket landed, the engine pulled the relevant obligation — response window, resolution target, after-hours rules, landlord vs. tenant flags — and stamped a countdown. A retail HVAC item with a 4-hour clause got a different clock than a next-business-day office plumbing job. Where leases said "reasonable time," PMs set building-level fallback rules once instead of re-debating every ticket.

Tickets sorted by time remaining, repeat-fault weighting, and tenant tier. Approaching breach escalated to the assigned PM; breached tickets surfaced on a dedicated view with elapsed time and a blocker reason — contractor acceptance, access denied, parts delay, responsibility dispute.

On dispatch, contractors received an auto-built brief: unit history, prior tickets on the asset, current photos and notes, access instructions, and a lease-responsibility summary — pushed through the channel they already answered, not a portal they'd never open.

Property managers got a building-level operations view: live SLA breaches with age and owner, mean time to first action by building and trade, repeat-ticket rate by unit, contractor response lag, a responsibility-dispute queue, and upcoming lease-driven risk. Every view answered a decision — reassign, call the tenant, escalate to legal, or flag a building-systems problem worth capex review.

Complaints about silence dropped sharply — PMs started seeing breaches hours before the clock ran out instead of learning about them from angry emails. The repeat-fault view even caught a cooling-tower issue across one retail floor that had been treated as isolated tenant problems for months: one capex conversation replaced a dozen band-aid callouts.