From Demo to Live: What a Procurement Portal Actually Takes

Most AI demonstrations are shown and never handed over. You watch a polished ninety seconds, you have no way of checking what was real, and the questions you actually wanted to ask go unanswered. So here is the opposite. Both files are below, and so is a plain account of what it would take to make one live — which is a great deal less than people assume.

Take the files

These are single, self-contained HTML files. You do not need to install anything: download, double-click, and they open in your browser. The data belongs to a fictional charity, Video Gaming Support, which does not exist.

The two files differ in one practical respect. The portal is completely self-contained and will run with no internet connection at all. The dashboard is not, because it draws its charting library from the web as it opens, so you will need to be online or the charts will come up blank.

What is real and what is illustration

The decision logic is genuinely running. Enter a value and the portal applies the thresholds — under £5,000 to the budget holder, £5,000 to £25,000 needing three written quotes, £25,000 to £100,000 a mini-competition, above £100,000 a full tender — and reshapes the form accordingly, each route carrying its own approver and turnaround. That rules engine is the part that would survive into a live system unchanged.

Everything else is illustration. Nothing is saved and nothing is sent. The reference number counts upward and resets whenever you reload. The tracker returns the same answer whatever you type into it. The dashboard figures are written into the file rather than drawn from a finance system.

That is not a defect, it is the point. A demonstration exists to settle whether the process design is right before anyone spends money on it. Wiring it up first and discovering afterwards that the thresholds were wrong is the expensive order to do this in.

The version most charities should actually do

Here is where I think a lot of advice goes wrong, mine included until recently. Say "procurement system" and everyone reaches for a request database, a workflow engine and a reporting layer, and the whole thing becomes a project with a business case attached. For an organisation raising twenty or thirty purchase requests a month, that is a considerable over-build.

I am not describing something theoretical. I created a night security patrol system for a London charity on exactly this pattern — a set of forms the officer works through, and a report that arrives by email at the end of the shift. It is live, it is used every night, and there is no database behind it. It works because the process was right, not because the technology was clever.

Two practical notes if you go this way.

• Make the submission reliable. The simplest approach hands off to the sender's own email client and relies on them pressing send, which is fine for one known person on one known device and less good for two hundred staff, some of whom will quietly fail to send. Most static hosting services include form handling that captures the submission on their side and emails it to an address you nominate, which removes that dependency entirely. Ask whoever hosts your site what they offer before reaching for anything more complicated.
• Drop the request tracker. Answering "where has my request got to" needs stored state, and stored state is what turns this into a system. In an organisation of this size the honest answer is to ask the team or look at the email thread, and that is a perfectly reasonable answer.

What you get for that is not a compromise. Requests arrive in a consistent format, with the routing rules already applied, in one findable place, with the decision recorded in a thread you can produce a year later. Auditors accept email approvals every day of the week. It is most of the value for a small fraction of the effort.

The dashboard, and a word of caution

If you work in Claude Cowork, the dashboard is the easy half. It can be a live artifact — a persistent, interactive dashboard that pulls from your connected applications when you open it and refreshes itself, rather than something anyone has to rebuild. For a finance director who wants a current view of procurement without asking anybody for a report, that is genuinely the answer, and it removes the need for a separate reporting tool.

The caveats are real and worth stating rather than glossing. Live artifacts require a paid Claude plan, they run in the desktop application only, and they live on the machine where they were created. On the Pro and Max plans they cannot be shared at all; on Team and Enterprise they can be shared, but only inside your organisation, and whoever opens one sees it through their own connections to the underlying data. So it is an excellent personal tool for the person running finance, and it is not a reporting surface you can put in front of trustees.

If you are not working that way, a grouped view or a spreadsheet over the submissions will tell you more than you would expect, and somebody can assemble a fuller picture periodically. Be honest with yourself that this is a manual dependency: it works for as long as there is a person who does it.

The thing I would not rush into is a full reporting tool. Power BI is the obvious candidate in a Microsoft environment, and it is the only part of any of this that carries both a licence cost and a genuine skills requirement — and those skills are scarce across the charity sector. Live with something simple for six months first. A fair number of organisations discover they never needed more.

What actually deserves your attention

None of the questions worth arguing about are technical. Each of these has caused a real disagreement in a real finance function, and each is far cheaper to settle on a demonstration than on a live system.

• Are the thresholds still right? Most delegated authority schedules were set years ago and have never been revisited against inflation or against what the organisation actually buys now.
• Who genuinely approves, as opposed to who the policy says approves? If those answers differ, automating the policy version simply routes work to somebody who does not do it.
• What happens when the rules are not followed? Emergency purchases and retrospective orders are the real test, and a process with no honest answer for them gets bypassed within a month.
• Does finance or procurement own this? Ownership decides who chases, who reports, and who answers when compliance slips.
• What does compliant mean here, and who reports the number? If nobody is accountable for it, any dashboard becomes decoration.

Answer those and you have the specification. Skip them and you will have automated a process nobody agreed to, which is worse than the spreadsheet you started with, because now it looks authoritative.

When you would outgrow this

Email stops coping at some point, and it is worth knowing where. Volume is the obvious trigger — several hundred requests a month is more than a mailbox should carry. The others are needing reliable status for people who ask constantly, needing requests linked to purchase orders in the finance system, or a governance requirement that approvals sit somewhere less editable than a mailbox.

At that point, in a Microsoft environment, the answer is a list to hold the requests, a form to feed it, and an approvals flow to route and chase them. That is standard configuration in a platform you already pay for rather than software development, and a competent administrator will recognise all of it. It is worth knowing that path exists. It is not worth taking before the simple version has shown you what you actually need.

Why publish the gap

I could have shown the video, let the portal look like a finished system, and left the questions hanging. Plenty of AI demonstrations are presented exactly that way, and it is one of the reasons finance people have learned to distrust them.

Being precise about where a demonstration stops is what makes the rest of it believable. If I tell you the routing logic is real and the notifications are not, you have a reason to trust me when I tell you what the routing logic does. The profession runs on that instinct — say what you know, say what you have assumed, and mark the difference clearly.

So take the files. Change the thresholds to your own and see whether the routes still make sense. If they do, you have learned something useful about your own process for the cost of ten minutes. If they do not, you have learned something considerably more useful.

Notes and caveats: Both files are demonstrations created for a fictional charity, Video Gaming Support, using invented data — no real organisation's information appears in either. They are provided as they are, for you to look at and adapt, with no warranty and no support attached, and they are not suitable for use as a live system without the work described above. The thresholds shown (£5,000 / £25,000 / £100,000) are illustrative and are not a recommendation for your organisation; your delegated authority levels are a matter for your trustees. Claude plan features and Microsoft licensing both change regularly, so confirm the current position before relying on anything stated here — this page reflects July 2026. Nothing here is legal, procurement, tax or data protection advice, and if you adapt these files and connect them to real data you are responsible for the resulting governance position.