← All case studies

Case study

Replacing a decade of legacy workarounds with a unified operations platform.

The situation

A thirty-year-old construction company running on a software stack that had grown by accretion. Sage 300 CRE held the financial truth — payroll, AP, job cost, equipment cost, general ledger — but most operations lived outside it. Timesheets were captured by foremen in spreadsheets and re-keyed. Equipment hours were paper-tracked, then entered weekly. DVIR inspections were filled out on clipboards and reviewed at end-of-day, if at all. A telematics platform was deployed across the fleet, but the data sat in a vendor portal that nobody outside the safety manager opened.

Each operating question — which crews are working today, what's our equipment utilization this week, which drivers failed inspection yesterday, what's our open AP by vendor — required pulling data from three or four systems by hand. The company had survived this way because the people were good, the margins were healthy, and the team knew the workarounds. But three forces converged:

• A new CFO arrived with a mandate to modernize and a finite patience for IT-by-spreadsheet.
• The COO needed real-time fleet visibility for safety and dispatch decisions, not weekly PDFs.
• The parent family office wanted a five-year capital plan with defensible ROI for whatever platform investment came next.

The company didn't need another point solution. It needed someone to design the platform end-to-end, defend the architecture to the C-suite, and then build it.

What we did

Work proceeded in three concurrent tracks over the first six months.

1. Strategy and financial case

A five-year ROI model with named ranges, three pricing scenarios, and sensitivity analysis on the variables the CFO actually cared about — payroll processing hours, equipment utilization, accounts-payable cycle time. The model survived multiple rounds of pressure from the family office's outside CPA without changes to the underlying assumptions. It was used to gate the architecture decision and is now the operating budget reference for ongoing technology spend.

2. Integration architecture

A layered architecture — presentation (BI, CRM, custom apps) reading from a single integration layer that pulled from systems of record (Sage) and operating systems (the field-data products, telematics, fleet maintenance). The integration backbone was selected after live diligence with the vendor: schema walkthroughs, latency questions, hosting and security review, reference customers. The decision and its alternatives were documented for the CFO so the choice could be defended.

3. Custom platform build

A purpose-built operations platform on Salesforce was deployed in parallel:

• Ten custom objects modeling drivers, vehicles, inspections, fuel/idle telemetry, and incident records
• Fourteen Lightning Web Components, including a fleet map with division filter, driver and vehicle detail pages with trend charts and event timelines, and a fuel-and-idle analytics module
• A DVIR module with defect line items and severity-aware routing
• Telematics API integration via a Named Credential and Apex sync classes, with scheduled background refresh
• Lightning App and record-page assembly so operations leads could open the platform and have one place to work

Permission sets, demo data sanity checks, and walk-through screenshots were produced before any user training began.

Outcome

By the end of the first phase:

• Fleet visibility — the COO and dispatch had a live map of 250+ pieces of equipment, filterable by division, replacing the weekly PDF.
• DVIR digitization — inspection results, including defect detail, surfaced to dispatch and safety within minutes of submission instead of end-of-day.
• A defended architecture — the integration backbone was approved at CFO and family-office level, with documentation the company can use to onboard future vendors or internal hires.
• A funding case that held up — the five-year ROI model was used as the basis for board approval of the platform investment.
• An ongoing relationship — the engagement transitioned from a discovery-and-build sprint into a monthly retainer for continuing platform work, integration maintenance, and stakeholder support.

The platform is being expanded in subsequent phases (yard-dwell analytics, equipment cost-to-job rollups, negative-reporting workflows). The same person who drew the architecture is still writing the code.

What was true about this engagement

A few patterns from this work that show up in most Licorne engagements:

• The strategy work and the build work were not handed off. The person presenting the integration architecture to the CFO was the same person writing the Apex sync class two days later.
• Vendor diligence was treated as buyer's work, not vendor's pitch. Every infrastructure choice was made after live demos against a written list of must-asks, with the alternatives documented.
• Change management was political work, not just training. Operational gatekeepers and reluctant IT staff were brought along as owners of the new system, not steamrolled by it.
• NDAs were the start of the relationship. Nothing in this case study identifies the client by name, and nothing will without their explicit permission.

Licorne Consulting LLC engagements are typically not made public. This case study is presented in anonymized form. For references or a more specific conversation about whether Licorne is a fit for your situation, get in touch.