Building a Custom GPT for procurement market reporting

There is a big difference between giving a team access to AI and building an AI tool around the way they actually work.

That was one of the key lessons from a recent Node9 project with a UK hospitality procurement consultancy.

The requirement wasn't simply to "use AI". The business wanted a practical way to support the creation of market reports and related procurement content.

The interesting part of the project was not choosing an AI model. It was working out how to turn an existing business process, specialist knowledge and quality expectations into something AI could support reliably.

Starting with the work, not the technology

Procurement market reporting involves more than asking AI to summarise a few articles.

The output needs context.

It needs to understand the audience, the relevant procurement categories, how the business communicates with clients, what sources should be relied upon and how recommendations should be presented.

It also needs to know its limits.

So rather than starting with automation, the first version focused on building a controlled internal assistant around the existing reporting process.

The result was a Custom GPT within ChatGPT designed specifically around that workflow.

What the assistant was designed to do

The assistant supports the team with draft:

• UK hospitality procurement market reports
• Monthly and ad hoc category updates
• Client-facing updates
• Board-level summaries
• Internal market notes
• Email briefings
• LinkedIn articles
• Category commentary

That gives the team one AI-assisted workflow that understands the context of the work rather than starting from a blank chat every time.

A Custom GPT is more than a prompt

One of the useful lessons from this project was how much of the work sits around the AI itself.

The GPT needed a clear operating framework.

That included detailed instructions covering behaviour, tone, evidence handling, uncertainty and review requirements.

A structured knowledge pack was created covering areas such as brand voice, report structure, source policy, procurement category taxonomy, recommendation frameworks and example report structures.

Conversation starters and example prompts were added to make common workflows easier for users.

The assistant was then tested against sample scenarios and refined before handover.

None of those things are particularly exciting compared with showing an impressive AI demo.

They are, however, the things that make an AI tool more useful in day-to-day work.

Human review was designed in from the beginning

Another important decision was what the assistant wouldn't do.

The system was designed to create draft material, not autonomously publish reports or replace subject-matter review.

All outputs require human review before being sent to clients, published externally or used commercially.

That distinction matters.

For a specialist business, the objective should not necessarily be removing the expert from the process.

AI can instead help with the work around that expertise: gathering information, structuring drafts, creating different versions of content and giving the expert a stronger starting point.

The judgement still sits with the people who understand the market and the client.

We deliberately kept the first version focused

It is tempting with AI projects to design the final system on day one.

We didn't.

The first MVP was deliberately built without external Actions or automated publishing.

Its job was to prove the core workflow first: could the assistant produce useful drafts, follow the right structure, reflect the right tone and operate within sensible source and review rules?

More advanced capabilities could then be considered separately, including structured data retrieval, wider integrations or potentially a dedicated application.

But those were not prerequisites for proving whether the basic idea worked.

That is an approach I think more businesses could benefit from.

What this project reinforced for me

AI adoption does not always need to begin with a large platform, complicated integration project or custom application.

Sometimes a focused internal tool is enough to test the idea.

But "simple" does not mean throwing together a prompt and hoping for the best.

The useful work is understanding the process around it.

What does the user need to produce? What knowledge does the AI need? Which sources can it rely on? What should happen when information is missing? Where does human judgement need to remain? Who approves the final output?

Those questions are much more important than making the AI appear clever.

Start with a useful workflow

This project is a good example of the kind of AI work that can make sense for SMEs.

Start with a defined business process.

Understand the people doing the work.

Give the AI the right context and boundaries.

Keep human oversight where judgement matters.

Then test whether it is genuinely useful before adding more technology around it.

That is a much more practical way to approach AI adoption than starting with the question:

"What can we automate with AI?"

A better question is:

"Where could AI make an existing piece of work easier or more useful without losing the judgement that matters?"

That is usually where the more interesting opportunities start.

---

This article describes a Node9 client project at a high level. Client identity, private data, supplier information and commercially sensitive information have been intentionally omitted.