Build a marketing tool from a ChatGPT chat

Your next ChatGPT marketing tool does not start as a software project. It starts as a conversation about a process nobody has written down.

I am Adam Stewart. I work with founder-led Australian teams through Digital Bond, and the pattern is the same: the campaign calendar still lives in a spreadsheet and three Slack threads. The lead tracker is “almost in the CRM.” The client portal has been on the list since last winter.

None of those problems starts as a build. It starts as a process that only exists in someone’s head.

The useful change is this. The first working version can begin as a conversation. You describe the job. You attach the messy files. You get something you can click, share, and argue with.

That is the idea. Not a product recap. A shorter distance between “we should have this” and “we can test this.”

Why does the marketing-tool backlog never move?

Most internal-tool conversations die in the same place.

Someone names a platform. Someone else names a different platform. A developer is “too expensive for an internal thing.” A no-code build is booked for next quarter. The spreadsheet survives another month because it is already open.

The cost is not only delay. The cost is that the process stays implicit.

Who is allowed to see the pipeline?

What does “ready to launch” mean?

Which fields are true, and which are theatre?

If you skip those questions, any interface will reproduce the confusion in a nicer font.

Faster building does not remove the work of defining the process.

I will say that again, because this is the part people skip when the demo looks easy.

If the source spreadsheet is confusing, the new tool will be a prettier version of confusing.

If nobody agrees on the workflow, the model will make assumptions.

If the information is outdated, the finished thing will be outdated too.

If you do not yet have a named loop, stop here and read you don’t have an AI problem. A ChatGPT marketing tool will not invent the process for you.

What does it mean to start as a conversation?

You sit down with the real materials.

The spreadsheet. The onboarding doc. The email thread where the exceptions live.

You tell the model who the tool is for, what they should be able to see, what they should be able to do, and what success looks like.

You ask for the smallest version that would replace the current mess.

Then you click through it like a slightly hostile new employee.

Is it easier than the process it replaces?

Does it use information you can trust?

Would the intended user know what to do next?

Does it remove work, or just move it?

If the answer is no, you did not fail. You found the missing rule in an afternoon instead of a quarter.

ChatGPT can now turn some of those conversations into a private site or a lightweight app you can share. Other tools will do a version of the same thing. I do not care which logo you use. I care that you test the process before you commission a cathedral.

Which internal tools are worth building this way?

A client project tracker.

A campaign calendar.

An internal request portal.

A reporting view one person currently rebuilds by hand.

A searchable resource hub for the team or for clients.

A simple tool that walks someone through a repeatable process.

These are marketing objects, even when they do not look like campaigns.

A calendar that other people can run is how content stops depending on you.

A lead tracker that stays true is how follow-up happens when you are on site.

A client portal that answers the usual questions is how you stop leaking hours in “just checking in” emails.

The goal is not to build an AI app for everything. It is to turn the small operational problems slowing your business down into simple tools you can test.

Define the process before you generate the interface

Before you ask any model to build, write six lines.

Who is this for?

What should they be able to see?

What should they be able to do?

What information does the tool need?

What information should be excluded?

What does a successful result look like?

If you cannot answer those, you are not ready to build. You are ready to have a meeting.

AI should do work in this context. It can draft the structure, sort the messy inputs, and show you a first version.

It should not publish the portal to clients, send the status email, or spend against a campaign because the interface has a button. A person still reviews content, access, forms and behaviour first.

Start with one low-risk object. A weekly campaign status page is safer than a customer-facing portal on day one.

Try this

Build a private first version of a tool for this process.

Intended users: [who]
Main outcome: [what they should accomplish]
I have attached the current spreadsheet / doc / thread.

Before you build, review the material and list:
- conflicting or outdated information
- what users must see
- actions they should be able to take
- sensitive information to exclude
- decisions that still need a human

Then create the simplest usable version. Do not add features that are not required for the core workflow. Do not publish anything. I will review content, access, forms and behaviour first.

When you are done, answer four questions:
1. Is this easier than the process it replaces?
2. Does it use information we can trust?
3. Would the intended user know what to do next?
4. Does it remove work, or move it?

Read the pre-build list before you look at the pretty bit. That list is the project.

If that prototype needs to become a reliable lead, CRM or follow-up loop, the marketing automation consultant page explains the implementation path.

How do you know the tool earned its place?

A tool that everyone opened once is a demo. A tool that retired a spreadsheet is a system.

Did the campaign actually get planned without a chase?

Did the lead get a next step the same day?

Did the client find the answer without emailing you?

I use a simple score when I try these with founders.

Ready to use.

Needs correction.

Needs escalation.

If everything needs escalation, you built a toy. If everything is ready to use and nobody changed their week, you built a dashboard for theatre.

A short page with the real dates will beat a clever app that guesses.

What this is not

This is not “fire the developer.”

Some tools should still be built properly, with permissions, logging and a person who can fix them at 11pm.

This is not “let the model invent how we work.” You invent how you work. The model helps you see it faster.

This is not a reason to connect an agent to every folder you own. A folder holds more than the one document. An inbox holds more than the one thread. Give the smallest access the task needs, and decide how you will check what it did.

I have watched enough demos to be bored by the ones that look magical and cannot survive a real client name.

I’ll take a plain tracker the team actually opens.

My honest read

My honest read: if a marketing tool has been on the backlog for months, the blocker is usually an undefined process, not a missing platform. Do not commission software until a conversation-built version has been used for a fortnight.

The guardrail is access and approval. Private first. Human review before anything client-facing. No send, publish or spend without a person.

What to do this week

Choose one process that currently lives across a spreadsheet, a doc and an email thread.

Write the six lines. Run the prompt. Use the first version internally for a fortnight.

If it earns its place, then decide whether it needs a sturdier home.

The Digital Bond scorecard can help you choose the system constraint worth turning into a tool first.

If you want to build that first version with other founders, using your actual files, that is what AI Systems Lab is for. The point is not more apps. The point is one small problem that stops slowing you down.