How do you use one system built in Microsoft 365 to make the case for the next?

Evidence, not a pitch

A colleague wants to buy a project management platform. The demo was good, the vendor is keen, and the IT lead’s objection sounds like the IT team protecting its turf.

An IT lead we work with was in exactly that spot recently. They didn’t argue the licensing or send a comparison table. They told their colleague to go and look at a system we’d already built in their tenant, which their own people already use.

That’s the strongest case there is for the second system: the first one, working. It moves the conversation from “could Microsoft 365 do this?” to “it already does something like this, so what would this one need?” Your colleague can open it, click around, and ask the people using it what they think. No vendor demo offers that.

But it only works if the first build was made to be evidence. Most aren’t.

Why the first build costs the most

The first system built in a tenant carries costs the second one doesn’t. Someone has to work out the site structure, the permission model, how identity flows from HR into access, and how the system talks to anything outside Microsoft 365. Done properly, all of that is built once.

Access is a good example. An Entra ID group whose membership follows the staff record will add and remove people automatically as their attributes change, so a new starter in the right department gets the right access without a ticket. (Dynamic membership needs Entra ID P1.) Set that up for the first system and the second one inherits it.

I put it this way to a client recently, when they asked why the first quote was the biggest: “This is the most costly exercise to get started… we’re not going to be building everything from the ground up. We have our foundation there.” Every build after it is a smaller quote, because it stands on the same groups, the same lists and the same connections.

That’s also why the first build should be chosen carefully. Pick one that leaves something reusable behind, not one that sits on its own.

What makes a build count as proof

Three things turn a finished system into evidence for the next one.

Someone outside the project uses it

A system only the requesting team has seen is a claim. One that a director, a coordinator or the CEO opens without being asked is proof. At Local Government Procurement, the CEO picked up the OKR tracker from the guide built into it, without asking a question.

It has a number

Hours back, a report nobody assembles any more, an audit finding closed. “It’s working well” won’t survive a committee. A figure tied to a named process will. If you don’t have one yet, work out what the manual version cost and compare.

It came in as promised

A build that arrived on scope and on price is evidence that the next one will. One that ran over is evidence too, of the opposite.

Two that did it

Achieve Australia’s work with us grew one system at a time. A review of its Azure estate found environments nobody had turned off and reserved capacity bought for a workload that had been retired. Fixing them cut the monthly bill by 40%, more than $40,000 a year. That recovery led to a workshop with the C-suite, and the engagement expanded from there.

One piece of that work is the onboarding and offboarding pipeline: one request that provisions accounts, licences, groups and devices, which gave back 120 hours a month and $126K a year. Then came NDIS claim routing, which sends each notification to the right admin without anyone opening a mailbox. Each successful build created internal advocates for the next one.

Local Government Procurement came at it from the other side. It had bought and abandoned two off-the-shelf OKR tools before the tracker built on SharePoint lists went from prototype approval to an organisation-wide soft launch in under a month. The weekly executive report now builds itself, and anyone who joins LGP gets access automatically.

Building the case for the next one

If you have one system working and want the second approved, here’s the order we’d go in.

1. Start with the number from the first. Put it in the opening line of the paper, not an appendix.
2. Name what’s already built. List the groups, sites, lists and connections the new system reuses. A committee reads that list as money already spent and not spent again.
3. Show it, don’t describe it. Send the doubters to the live system and to the people who use it.
4. Leave out what you can’t defend yet. If a phase depends on a decision nobody has made, quote it separately. One IT lead we work with cut a second phase from their own business case for exactly that reason, so the first could go to committee on its own.
5. Run the honest test. Some processes should go to a platform. The five build-or-buy tests will tell you which.

Where to go from here

If you have the first system and want help scoping the second, that’s what a Custom Operational Apps conversation is for. We’ll look at what’s already in the tenant and tell you what the next build reuses.

If you haven’t built anything yet, start with The SharePoint Audit. It shows what the first build would stand on, and whether it’s ready to carry a second.