Business Operations

Built for the people who run operations, not commissioned by the IT department looking in.

A meaningful part of my career started inside an operations function, not inside an IT team. That distinction matters: tooling built by requirement from planners and managers who actually run day-to-day operations tends to look and behave differently from tooling built by an IT department's best guess at what operations needs. Delivery is provided directly by Jamie Page on a 100% remote basis.

Where this experience comes from

Inside Lloyds Banking Group's operations, as sole developer, I built a workforce-planning and capacity-management tool from scratch in Excel/VBA, addressing fragmented spreadsheet-led planning and inconsistent forecasting across operational teams. It began as a site-level fix for one team's planning problem and grew into tooling used across most of UK Group Operations. I gathered requirements directly from the planners and managers who'd be using it — not from a specification handed down by IT — ran stakeholder demonstrations, and supported rollout, training and adoption across multiple UK sites.

That work taught me something a purely technical career doesn't: operational stakeholders don't want the most elegant architecture, they want a tool that fits how their team actually works on a Tuesday morning. Getting that right meant sitting with planners, watching how they used their existing spreadsheets, and building something that replaced the spreadsheet's flexibility without replacing its familiarity.

Typical challenges

• Workforce planning or capacity-management tooling that has outgrown its original spreadsheet or ad-hoc design
• Forecasting or scheduling processes that are inconsistent across teams or sites because there's no shared tool behind them
• Systems built for operations that were specified by IT rather than by the people using them day to day, and it shows
• Tooling with low adoption because it doesn't fit how the operational team actually works
• Rollout, training and adoption support across multiple sites or teams
• Systems where the operational context — who uses this, when, and under what pressure — is at least as important as the code itself

Where I draw the line

This experience is building and delivering the tooling operations teams rely on, not setting operational strategy or process design from scratch. I'd expect any operations engagement to work the same way: I build what your operational leadership has identified as the gap, informed by direct conversations with the people who'll use it — I don't arrive with a generic process-improvement framework and apply it regardless of context.

How PageTech helps

• Workforce planning & capacity-management tooling
• Requirements gathering directly from operational stakeholders, not just IT specifications
• Rollout, training and adoption support across sites or teams
• Replacing spreadsheet-led processes without losing the flexibility that made the spreadsheet work
• Documentation and knowledge transfer

The aim isn't to sound bigger than a founder-led practice is. It's to bring the same habit of building for the people actually using a system — not just the spec — to whatever operational tool you need built, replaced or improved.

Explore related areas

Explore Operational Systems · Explore Banking & Financial Services · Explore Workflow Engineering

Discuss an operations challenge

If your operations team is working around a spreadsheet that's outgrown itself, or a tool that was built without asking the people who'd use it, a short conversation is usually the best place to begin. Delivery is 100% remote.