Running the technology ecosystem for a multi-location business.
Turning unowned tools, ad-hoc support, and vendor sprawl into a technology environment the business could rely on.
- Locations
- 9
- Scope
- M365, POS, A/V, SaaS
- Support
- Ticketed & tracked
- Tool sprawl
- Reduced
Everything worked until it didn't — and then nobody owned it.
Microsoft 365, ParPOS terminals, back-of-house hardware, in-store A/V, and dozens of SaaS subscriptions had accumulated over years without a single owner. Renewals auto-charged, licences sat unassigned, and store-level issues were escalated by whoever happened to be available.
Support was slow because there was no intake path, and technology decisions were reactive because nobody had a full picture of what we were already paying for.
Inventory first, then standardize where it pays.
I started with a full inventory: every tool, owner, cost, renewal date, and who actually used it. That alone surfaced duplicate subscriptions and licences assigned to people who had left.
I set up a single support intake so store teams had one place to report issues, and I standardized hardware and configuration across locations so a fix at one store applied everywhere. Where standardizing would have cost more than it saved, I left things alone deliberately rather than for consistency's sake.
On the vendor side, I consolidated relationships, renegotiated at renewal with usage data in hand, and built a simple roadmap so leadership could see what was coming instead of being surprised by it.
A predictable environment instead of a reactive one.
Employee support got measurably faster because requests had a path and common issues had documented fixes. Onboarding and offboarding became a checklist rather than an improvisation.
Tool sprawl shrank, renewals stopped being surprises, and technology decisions started being made against a roadmap and real usage data instead of the loudest current problem.
Fund the documentation as part of the work.
A lot of operational knowledge lived with me longer than it should have. Building the runbooks alongside each fix — rather than as a separate later project — would have made the whole function less dependent on one person.
- Microsoft 365
- Microsoft Teams
- ParPOS
- Olo
- Endpoint & hardware management
- SaaS & vendor management