Don’t Build a Ferrari to Deliver Pizza: Right-Sizing Tech for Your Service Chain
By Tim Fagan, Senior Manager, Trace Consultants
There’s a particular kind of meeting I’ve seen play out across Australia and New Zealand—health, aged care, local government, facilities, retail, hospitality, field service, you name it.
Someone throws a slide on the screen titled “Future State Platform”. It’s glossy. It’s ambitious. It has a lot of arrows. And it usually ends with a single, quiet sentence from someone who actually runs the day-to-day service:
“Will this help the team get through Monday?”
That question is the whole point of this article.
Because many organisations don’t have a technology problem. They have a right-sizing problem.
They’ve been sold a Ferrari when what they needed was a dependable way to deliver pizza—hot, on time, without losing the driver, the map, or the customer’s address along the way.
The key takeaway is simple: avoid over-engineering. Build pragmatic tools that solve actual problems rather than buying bloated enterprise suites. But the execution—choosing what to keep simple, what to standardise, and what to scale—is where things get interesting.
This is a practical guide for leaders in Australia and New Zealand who are responsible for service outcomes: response times, quality, safety, compliance, customer experience, workforce productivity, and cost-to-serve. It’s for the people who don’t get points for “digital transformation” in a slide deck—only for services delivered, customers helped, and teams that aren’t drowning.
What do we mean by “service chain”, and why does tech right-sizing matter?
If supply chains move products, service chains move outcomes.
A service chain includes the end-to-end flow from:
- demand intake (calls, online requests, referrals, work orders)
- triage and prioritisation
- scheduling and dispatch
- service delivery (in-person, remote, clinical, technical, advisory)
- documentation and compliance
- billing, claims, and funding validation (where relevant)
- feedback, rework, and continuous improvement
Right-sizing technology matters because service chains are human-heavy and exception-heavy. Unlike manufacturing lines, services deal with messy reality: no-shows, urgent escalations, incomplete information, changing needs, workforce availability, and customers who don’t describe their problem in neat dropdown menus.
When technology is oversized, it doesn’t just cost more. It often creates friction—slower work, more workarounds, more training, and less confidence in data. Then teams quietly revert to email, spreadsheets, whiteboards, and “just call Jason, he knows how it works”.
And the organisation ends up running two systems:
- the expensive one, and
- the one people actually use.
How organisations end up buying Ferraris
Over-engineering rarely comes from stupidity. It comes from understandable pressures:
1) Fear of being “left behind”
The board asks what competitors are doing. Vendors talk about AI, automation, “single pane of glass”, and end-to-end suites. Nobody wants to be the executive who chose the “small” option.
2) Procurement processes reward certainty, not suitability
A traditional RFP tends to favour big suites with long feature lists. “Yes” answers score well, even if those features will never be adopted (or shouldn’t exist in your operating model in the first place).
3) People confuse standardisation with value
Standardisation can be brilliant—when it removes waste and improves outcomes. But standardising the wrong process just makes the wrong thing consistent.
4) IT and risk teams want to reduce tool sprawl
Fair enough. But forcing every service use case into one monolithic platform can be like insisting every vehicle in Australia must be a road train.
5) Vendors sell platforms; teams live workflows
A platform is only as good as the day-to-day behaviours it enables. Most service teams don’t wake up wanting a platform. They want fewer repeat jobs, fewer admin steps, fewer angry calls, and fewer “who owns this?” moments.
The hidden cost of “bigger than we need”
A few data points help anchor why this matters:
- McKinsey’s survey work highlights that organisations often capture far less value than expected from digital transformations, and sustaining benefits is hard—particularly when building new digital businesses.
- Flexera’s State of the Cloud research continues to show cost optimisation is a persistent priority—because cloud and SaaS efficiency doesn’t happen automatically just because the tech is modern.
- Zylo’s SaaS Management Index reporting (via PRNewswire) points to significant wasted spend on unused licences, highlighting how common “shelfware” becomes when tools outpace adoption.
- And there’s a human cost: poorly executed initiatives contribute to “transformation fatigue” and burnout risks, especially when training and communication lag.
None of this is an argument against investment. It’s an argument against confusing investment with impact.
In service environments, the real cost drivers are often:
- time lost to rework and chasing information
- delayed triage and scheduling
- poor handovers
- weak demand visibility
- inconsistent service standards
- admin load on frontline teams
- duplicated data entry across systems
- poor exception management (the “edge cases” that are actually everyday reality)
If new technology doesn’t materially reduce those frictions, it’s not transformation—it’s decoration.
The “pizza test”: a quick way to sanity-check tech decisions
Here’s a simple test I use in workshops:
If you’re trying to deliver pizza, what do you actually need?
A fast vehicle, a reliable route, a clear address, a warm box, and a way to confirm delivery.
You don’t need:
- a carbon-fibre chassis
- a V12 engine
- a telemetry team
- a bespoke racing dashboard
- a pit crew
Translated to service chains:
You need
- clear demand capture
- prioritisation rules that match your service promise
- scheduling that reflects constraints (skills, travel, SLAs, safety)
- visibility for customers and frontline staff
- simple, reliable documentation
- good exception handling
- management reporting that people trust
You don’t need (by default)
- every module in an enterprise suite
- deep customisation that breaks upgrade paths
- a “single platform” mandate that ignores reality
- 18-month implementations before anyone sees value
- workflows built for “perfect data” that doesn’t exist
Seven principles for right-sizing service-chain technology
1) Start with the service promise, not the software
“What do we promise customers—and what do we need to consistently deliver it?”
For example:
- same-day response for safety-critical issues
- two-hour clinical turnaround for certain pathways
- fixed appointment windows for vulnerable customers
- first-time fix for priority assets
- rapid triage and clear next steps even when you can’t fix immediately
Technology should enforce and enable that promise—not replace it with generic workflows.
2) Fix the flow before you automate it
If your intake process is unclear, your triage rules are inconsistent, and your handovers are broken, automation will simply move bad work faster.
Right-sizing often means doing the unglamorous work first:
- process mapping that reflects reality (including exceptions)
- role clarity (who owns what, when?)
- simple standard work
- minimum viable data fields (not “everything we might want someday”)
3) Design for adoption, not for demos
The best service tech is the one people actually use at 7:30am.
Adoption is shaped by:
- clicks and screens (cognitive load)
- mobile usability (especially for field and facility teams)
- speed (latency kills trust)
- training effort (time off the floor is expensive)
- how exceptions are handled (real work)
4) Prefer configuration over customisation
Custom code is a liability. Sometimes it’s necessary—but treat it like debt that must be serviced.
A practical rule:
- Configure if it stays within supported patterns and can be upgraded.
- Customise only when it protects a genuine differentiator or compliance requirement—and you’re willing to own the lifecycle cost.
5) Integrate lightly, but integrate intentionally
Over-integration is a common Ferrari symptom: “We must connect everything to everything on day one.”
Instead:
- identify the few integrations that remove major friction (e.g., identity, asset registers, customer master, billing triggers)
- sequence integration in phases
- keep data ownership clear (one system owns the truth for each domain)
6) Build a minimum lovable workflow (MLW), not a “future-state masterpiece”
MVP is often discussed. In service chains, I prefer minimum lovable workflow: a workflow that is not only functional, but genuinely makes people’s day easier.
If it doesn’t reduce effort or confusion, it won’t stick.
7) Prove value early—then scale what works
A right-sized approach should show tangible improvement in weeks, not years:
- faster triage
- fewer handover failures
- better schedule adherence
- fewer status-chasing calls
- clearer workload visibility
- reduced admin burden
Once the value is real, scaling becomes easier because stakeholders want it.
Common signs you’re building a Ferrari
If you recognise a few of these, you’re not alone.
- The requirements document is 200 pages, but nobody can explain the top 5 workflows.
- Every stakeholder gets their “must-have” field, so the form becomes unusable.
- The program is measured by milestones delivered, not service outcomes improved.
- You’re implementing 12 modules when 2 would address 80% of pain points.
- You’re redesigning the whole operating model inside the tool.
- Training is “we’ll do it later” (it won’t happen properly later).
- Reporting is complex because underlying data definitions aren’t agreed.
- The frontline team quietly maintains a spreadsheet “because it’s faster”.
When an enterprise suite is the right answer
Right-sizing isn’t “small for the sake of small”. There are plenty of cases where a bigger platform is the right call, including:
- high transaction volumes across multiple regions and entities
- complex regulatory environments with strict audit trails
- significant integration requirements that need strong governance
- major service standardisation benefits (e.g., multi-site, multi-brand)
- safety-critical environments where workflow control is non-negotiable
- mature organisations with strong process discipline and product ownership
The difference is intent and sequencing.
A right-sized enterprise approach still:
- rolls out in thin slices (workflow by workflow)
- protects upgrade paths
- keeps customisation tight
- anchors everything to service outcomes
Ferraris are great. Just don’t use them for pizza runs.
A practical right-sizing framework (that works in the real world)
Here’s a simple way to structure decisions without getting trapped in ideology:
Step 1: Map your service chain and pain points
Capture:
- volume and demand patterns (including peaks)
- top failure points (handover, scheduling, rework, compliance gaps)
- where customers complain and where staff waste time
- what “good” looks like (service promise + KPIs)
Step 2: Prioritise use cases by value and complexity
Plot use cases on a grid:
- High value / low complexity: do these first (quick wins, fast adoption)
- High value / high complexity: plan properly (phased delivery, strong ownership)
- Low value / low complexity: only if it’s cheap and removes irritation
- Low value / high complexity: avoid (this is where Ferraris are born)
Step 3: Decide the “right tool shape” for each layer
You generally need a mix of:
- workflow tooling (intake, triage, scheduling, dispatch, case management)
- data and reporting (definitions, dashboards, operational control)
- integration and identity (secure access, minimal duplication)
- automation (rules, alerts, nudges—only once basics work)
Step 4: Build the implementation plan around adoption
Include:
- process changes and role clarity
- training that matches real work (not generic platform training)
- support model (who helps when things go wrong?)
- feedback loop from frontline to product owner
Step 5: Measure benefits in service terms
Not “users onboarded”. Not “modules deployed”.
Measure:
- service responsiveness and backlog
- first-time resolution / rework rates
- schedule adherence
- customer effort (status chasing, repeat calls)
- admin time
- staff satisfaction and turnover risk signals
What right-sized tech looks like in ANZ service organisations
Across Australia and New Zealand, service chains often share a few realities:
- geographically dispersed operations (metro + regional)
- workforce constraints and skill mix challenges
- high compliance expectations (especially in government, health, aged care)
- legacy systems that can’t be replaced overnight
- service expectations rising faster than budgets
Right-sizing tech in this context usually means:
- modular modernisation rather than big-bang replacement
- workflow-first improvements before platform expansion
- low-code and lightweight automation where it accelerates outcomes
- a relentless focus on time-to-value and frontline usability
How Trace Consultants can help
Right-sizing technology isn’t just a “systems” job or a “process” job. It sits in the overlap of:
- service strategy
- operating model design
- process engineering
- technology architecture
- vendor selection and commercial discipline
- change management and adoption
- benefits realisation
That overlap is exactly where programs succeed or fail.
At Trace Consultants, we help organisations avoid the Ferrari trap by staying grounded in service outcomes and practical delivery. Typical ways we support clients include:
1) Service chain diagnostic and opportunity assessment
We map the end-to-end service chain, quantify where time and effort are being lost, and identify the smallest set of changes that will shift performance meaningfully—often before a tool is even selected.
2) Use-case definition and workflow design
We translate business problems into clear use cases and “minimum lovable workflows” that frontline teams can validate quickly.
3) Technology right-sizing and roadmap
We help you decide what needs an enterprise platform, what can be handled with lighter tooling, and what should be fixed in process and governance instead of software.
4) Vendor selection and fit-for-purpose procurement
We support vendor shortlisting, evaluation, proof-of-concept design, scoring models that reward usability and adoption (not just feature lists), and commercial negotiations that protect you from shelfware.
5) Implementation support that protects time-to-value
We help structure delivery into thin slices, build operational readiness (training, support, ownership), and keep customisation disciplined.
6) Benefits tracking and continuous improvement
We set up measurement that matters—service outcomes, cost-to-serve drivers, and staff experience—so investment stays tied to real-world value.
Importantly, we don’t come in assuming the answer is always a big platform—or always a light one. We’re solution-agnostic. The goal is the right tool, for the right job, delivered in a way your teams will actually adopt.
A final thought: practical beats perfect
If you’re leading service operations, you already know this: customers don’t care what platform you bought. They care that you show up, solve the problem, and keep them informed.
So before you sign up for the Ferrari, ask the pizza questions:
- What’s the job we’re actually trying to do?
- What’s the smallest workflow that materially improves service?
- What will frontline teams stop doing because this tool makes it unnecessary?
- How will we measure success in service terms, not IT terms?
- What are we willing to not build?
Right-sized technology isn’t about lowering ambition. It’s about aiming ambition at the things that actually move the needle.
And if you’re staring at a big decision—platform replacement, workflow redesign, automation investment, vendor selection—Trace can help you cut through the noise and build something your service chain will thank you for.
Because the real win isn’t owning a Ferrari.
It’s delivering the pizza—hot, fast, and profitably—every single day.
