Building better marketing tools with AI and your own business data

Most businesses already have plenty of data. The difficulty is getting it into a form that helps people make decisions.

Sales sit in a till system. Online orders live in Shopify. Stock and purchasing information might be held in OrderWise. Advertising costs sit in separate platforms, while targets, forecasts and working assumptions are scattered across spreadsheets.

Meanwhile, people spend hours moving information between systems, checking figures and producing reports.

Using tools such as Codex and Claude, it is becoming more practical to build software around those processes. That could mean a simple tool that removes a repetitive task, or a connected suite supporting budgeting, forecasting, product decisions and marketing delivery.

The possibilities are broad. The starting point is understanding the business well enough to decide what is worth building.

Start on site with the people doing the work

I would begin by spending time with the business and following its processes.

How does an enquiry become an order? What happens when someone buys in store rather than online? How do teams check stock, plan promotions and decide where to invest marketing budget?

Speaking to the people doing the work often reveals more than looking at a dashboard.

Someone might download three reports every morning and manually combine them. A marketing team might promote products without knowing their availability. A sales team might record valuable enquiries in a spreadsheet that nobody else sees.

These are practical starting points: repeated work, missing information and decisions made with an incomplete picture.

Collect the data and identify the bottlenecks

The next step is to establish what information exists, where it comes from and how reliable it is.

A retailer might have transaction data in its till system, orders and customer records in Shopify, and stock, purchasing or fulfilment information in OrderWise. A service business might rely more heavily on a CRM, booking platform and enquiry records.

Alongside those business records, we can assess advertising reports, website analytics, Search Console data and the spreadsheets people already use.

The questions are straightforward:

• What information do we collect?
• What useful information are we missing?
• Where do people enter the same information twice?
• Which tasks take too long or frequently go wrong?
• Which decisions are delayed because someone is waiting for a report?

Not every bottleneck needs new software. Sometimes the answer is a clearer process or a consistent field in an existing system. Where a tool would help, we now have a concrete problem to solve.

Design the architecture and a shared language

Once the problems are understood, we can design how the information should flow.

For example, a hypothetical retail reporting tool could bring together online orders from Shopify, store transactions from a till system, stock information from OrderWise and advertising costs from Google Ads.

The available connection might be an API, a scheduled export or a controlled file import. That depends on the systems, their versions and the access available.

Before combining anything, we need a shared language—a data taxonomy.

What counts as an order? Does revenue include VAT? How are refunds handled? Does the same product have different identifiers across systems? Are categories and sales channels named consistently?

These definitions determine whether the combined picture is useful.

The architecture also needs to establish which system owns each record, how often information updates, who can access it and what happens when a connection fails. If a tool displays yesterday’s stock, the user should be able to see that.

This work gives the suite a dependable foundation.

Turn the findings into a specification

The specification connects the business problem to the tool we intend to build.

It should describe who uses it, what they need to do, which information they need and what a successful outcome looks like.

“Build a forecasting dashboard” leaves too much unanswered.

A more useful brief might be:

Allow the commercial manager to compare three monthly spending scenarios using recent sales, planned promotions and editable assumptions. Show the expected cost of sale, identify missing inputs and save the scenario for review.

That gives us a workflow to design and an outcome to test.

The specification should also cover exceptions. What happens when a product cannot be matched? When an order is refunded? When a data import is incomplete?

Codex and Claude can help develop the software from that specification, but the quality of the brief matters enormously.

Build the suite around useful decisions

With that foundation in place, the range of possible tools is extensive.

A business could build a daily trading view combining store and online sales. A budget planner could compare spending against turnover and flag when the plan needs attention. A stock-aware marketing tool could identify products being promoted despite limited availability.

Other possibilities include a forecasting workspace, a product opportunity explorer, a feed quality checker, a social creative workflow or a project manager that turns performance findings into assigned actions.

For a service business, the same approach could connect enquiry sources, appointments, sales outcomes and delivery capacity.

There is no need to build everything at once. Start with a useful module, validate it and expand as the business sees value.

The ambition can be broad while the first release stays focused.

Train the team and make it part of the working day

A tool needs to fit the people using it.

That means testing it with the team, explaining the figures and showing how it supports their decisions. Users should understand where the data comes from, how current it is and which assumptions they can change.

Training also reveals weaknesses in the design. If someone repeatedly exports a report to finish the job elsewhere, the workflow may be missing something.

Clear ownership matters too. Who checks data quality? Who reviews alerts? Who maintains the business rules?

The goal is to make the process easier to use and more dependable.

Improve it as the marketing strategy develops

The suite should evolve with the business.

A new showroom may introduce different reporting needs. A larger product range may require a better category structure. A shift towards paid social might create a need to connect creative activity, enquiries and sales over longer periods.

We can add new connections, revise rules and improve workflows as those needs emerge.

We can also keep a record of changes in marketing investment and compare them with business outcomes. That helps us investigate what happens when we increase or reduce activity across paid search, organic search, social and display.

Patterns provide useful direction. Establishing causation still requires appropriate tests and consideration of other influences, such as promotions, seasonality and stock.

Each iteration should help the business make a better decision or remove a real obstacle.

What could you build around your business?

AI-assisted development opens up possibilities that previously felt too expensive or too difficult to justify.

You can build around the systems you already use and the processes your team actually follows. The limits depend on data, access, budget and the reliability the tool needs—but the scope is much wider than another dashboard.

Businesses can explore this themselves. Start with one recurring frustration, understand the process behind it and define what a better version would look like.

If you would rather have help, this is where I come in: analysing the business on site, identifying gaps and opportunities, designing the data flow and specification, then developing the tools, training the team and improving the suite as the strategy evolves.

Book a consultation to discuss your business processes and tools.