Skip to content

Evidence-backed work

Practical systems work carried into production.

Across five documented cases, Jeremy diagnoses the operating problem, makes proportionate business and technical decisions, delivers the change, and remains accountable after launch.

What the collection demonstrates

Jeremy diagnoses, delivers, and stays accountable.

Together the cases show repeatable strength in process diagnosis, system decisions, delivery, communication, adoption, and continuing ownership—not a claim to master every underlying platform.

01

Understand the real work

Trace roles, rules, records, handoffs, exceptions, and the decision people need to make.

02

Choose proportionately

Improve an existing platform, connect systems, build a focused layer, or redesign the workflow itself.

03

Carry it through

Test, launch, explain, monitor, correct, and leave clearer ownership behind.

Five complementary cases

From enterprise rescue to a measured service redesign.

The cases are ordered to show range without losing the common thread: useful systems must fit the operation and survive contact with real work.

01 · Enterprise system rescue

Rebuilding the missing operating layer without discarding completed work.

Jeremy preserved the GIS foundation, learned an unfamiliar CMMS, rebuilt its operational structure, launched it by July 21, 2023, and continued extending it.

Organizational scope: approximately 100 employees; not a verified active-user count.

Read the Cityworks case

02 · HR systems modernization

Turning a payroll-adjacent HRMS into governed employee workflows.

After vendor installation and basic configuration, Jeremy led operating design, customization, integration, testing, rollout, support, reporting, and the roadmap.

Approximately 95–100 employees in scope; no unverified savings or active-use claim.

Read the HRMS case

03 · Custom application

Finding an unassigned paper burden and building around the full outcome.

A role-aware training application moved from proactive discovery through a live parallel pilot, a production rule correction, and continuing support.

Reporting moved from more than an hour to minutes by firsthand estimate; current production is Apps Script and Sheets.

Read the training check-in case

04 · Operational visibility

Giving approximately 75 people useful queue context during the shift.

A lightweight internal dashboard turned automated Avaya exports into team views that supported coverage, status checks, resource movement, and anomaly awareness.

Written historical evidence records refresh improving from approximately 120 seconds to approximately 5 seconds.

Read the Queue Site case

05 · Customer experience

Redesigning call flow across routing, capacity, employee states, and adoption.

Jeremy used telephony data and workflow mapping to implement a three-stage model, measure its first result, and support the team through months of adoption.

Average wait: 55.8-second pre-change average across 18 workdays versus 9 seconds on one first measured post-change day, which had lower call volume.

Read the call-flow case

What this means for a client

You do not need to arrive with a software specification.

A recurring bottleneck, scattered record, confusing handoff, underused platform, or reporting burden is enough to begin. The first job is to understand the operation and define a useful outcome.

The recurring pattern is not “build custom software.” It is choose and deliver the right level of change.

Which part of your operation feels harder than it should?

A rough, non-confidential description is enough to identify the likely first step.

Start with one process