Real problems. Real results.

Context

The Situation

A field service business had built up its scheduling operation over the years using an older software tool. The system worked — barely — but all the rules about how jobs were scheduled lived inside the software in ways that only one person understood. There was no documentation, no way to make changes safely, and no process for keeping the system up to date.

Problem

One Change Away from Breaking

Any time someone needed to update the scheduling rules, they risked breaking the whole operation. Errors had accumulated quietly over the years that nobody had caught. The business was fully dependent on one person's knowledge of how everything worked — and if that person was unavailable, so was the system.

What We Did

A Scheduling System That Works Without a Safety Net

• Built a new scheduling system that automatically prioritizes jobs based on rules — rules that now live in one easy-to-update location instead of being buried and scattered throughout the software.
• Added a system that automatically recognizes and categorizes each type of job, with a safety net for anything unusual and a report that flags gaps for the operations team to review.
• Built in automatic safeguards to prevent jobs from being scheduled too soon — no manual checking required.
• Found and fixed errors that had quietly built up over time — things causing the system to behave unpredictably — all without interrupting the day-to-day operation of the business.
• Put in place a clear process for making future updates safely, along with documentation so any changes can be understood and made by someone other than the original author.

Context

The Situation

A field service operation had accumulated years of scheduling rules across their system — rules about which jobs get scheduled, when, and how often. These rules had been added piecemeal over time and never organized. The result was a system that was difficult to understand, difficult to manage, and difficult to change without breaking something.

Problem

Rules Nobody Could Manage

The rules governing how jobs were scheduled were spread across hundreds of individual entries, each one separate, each one requiring manual maintenance. When something needed to change, there was no clear place to go — you had to find and update entries in multiple places, and hope you didn't miss any. The scheduling tool also had its own limitations that made certain kinds of updates impossible to do in the standard way, and those workarounds had never been written down.

What We Did

Fewer Rules, Better Coverage

• Rebuilt the scheduling rules from the ground up — reducing over 230 individual entries down to fewer than 100 organized categories that cover the same ground more reliably and consistently.
• Replaced a system where each job type had its own separate rule with a cleaner approach where job types are grouped into categories — making it much easier to understand what the system will do and why.
• Found a practical solution for a limitation in the scheduling tool that was preventing certain updates from working at all — and documented it clearly so the same approach can be used in the future.
• Restructured the rules so that when something needs to change, there's one place to go instead of dozens.
• Wrote plain-English documentation explaining the logic, the limitations, and how to work within them — so the next person who touches the system isn't starting from scratch.

Context

The Situation

A music industry organization needed a better way to manage guest lists across multiple shows, bands, and internal teams. As the operation grew, the informal process — requests coming in through different channels, managed by different people — was becoming harder to control and easier for things to fall through the cracks.

Problem

No System, No Visibility

There was no central place to submit, review, or approve guest requests. Members submitted requests however they could. Staff had no unified view of who was approved, what capacity remained for each show, or what had changed and when. As show volume increased, the informal process became a real operational risk.

What We Did

A Purpose-Built Tool for the Way They Actually Work

• Designed and built a complete guest list management system from the ground up — built around how this specific organization actually operates, not a generic off-the-shelf solution.
• Built a mobile-friendly portal for members to submit guest requests for any show — adding their guests, specifying details, and tracking the status of their submissions without having to contact anyone.
• Built a separate admin view where staff can see all requests in one place, approve or decline them, track how many spots remain for each show, and manage credentials — all from a single screen.
• Set up three levels of access — members, admins, and staff — so each person sees only what they need to, with no overlap or confusion.
• Made every action reversible: nothing is permanently deleted, every change is recorded with a timestamp and who made it, and staff can edit anything directly without navigating to a separate page.