Symentic Technologies

BlogBusiness & Strategy

What's in an AI Workflow Blueprint — and When We Tell You Not to Build

Seven deliverables, one fixed fee, and a real chance the answer is 'don't build'. What the Blueprint actually produces, and why we would rather tell you no early.

Most custom software goes wrong before anyone writes a line of code.

It goes wrong when a system is built from a feature list instead of from the work. Someone writes down what the new software should have — a dashboard, a customer portal, stock alerts — and a developer builds exactly that. Six months later the team is still using the spreadsheet, because the feature list described what people asked for, not how an order, job or request actually moves through the business.

The AI Workflow Blueprint exists to put things in the right order: understand the workflow, design around it, and only then decide whether to build. This article sets out exactly what it contains, what it costs, and the situations where its honest conclusion is that you should not build anything at all.


What happens in the session

The Blueprint starts with a 60–90 minute discovery session. It is not a sales call, and it works best with the right people in it.

  • Bring the person who does the work, not only the person who signs off. The owner knows why the process exists; the person processing orders knows what actually happens at 4pm on a Friday.
  • We follow one real thing end to end — an order, a job or a request — from the moment it arrives until it is finished and invoiced. Every tool it touches, every person it passes through, every copy and paste.
  • We ask about the exceptions. "What happens when the customer changes the quantity?" "What if the supplier is out?" Exceptions are where the spreadsheet grew its extra tabs, and where most of the time goes.
  • Screens are shared. Seeing the actual spreadsheet, inbox and systems is worth more than any description of them.

The seven deliverables

After the session you receive a written Blueprint with seven parts.

1. Current workflow map

Every step, tool and handoff in the workflow as it runs today, and who does each one. Many owners have never seen their own process drawn out; it is often the most useful page in the document, whatever you decide afterwards.

2. Bottlenecks and automation opportunities

Where the time goes, where errors enter, and where work waits for a person who is busy with something else. Each opportunity is marked as something to automate, something to simplify, or something that should deliberately stay human.

3. Proposed system and suggested modules

The shape of a Custom Operations System for your workflow — typically some combination of orders, customers, purchasing, inventory, a dashboard and email or AI automation — and how it connects to the tools you are keeping, such as your accounting package.

4. Basic UI / prototype

A clickable outline of the key screens. You see the proposed system before committing to a build, and the people who will use it can say "that's not how we do it" while changing it still costs nothing.

5. Estimated savings

Built from your numbers — order volumes, time per step, error rates you have told us about — with every assumption written down so you can challenge it. It is not an industry-average return-on-investment figure; if the numbers you give us do not support a build, the estimate will say so.

6. Implementation phases

The build broken into phases, each one usable on its own. A common first phase is orders, customers and a dashboard; purchasing, inventory and automation follow. You are never asked to fund the whole thing from a cold start.

7. Fixed-price proposal

A fixed price for the first phase, with the later phases estimated. Initial builds are typically £3,000–£10,000. Fixed-price because you should know what you are committing to; if you want to understand how development estimates are built in the first place, we explain the arithmetic here.


Where the AI comes in — and where it doesn't

"AI" is in the name for two specific reasons, and it is worth being precise about both.

How we build. We use AI-native development, which shortens the time it takes to build and change software. That is what makes a custom system realistic on an SME budget and timeline rather than a multi-month agency project.

What goes into your system. Where it earns its place, AI handles specific, bounded steps: reading an order out of a customer's email, drafting a reply for a person to check, sorting incoming requests. The Blueprint names exactly which steps, and — just as importantly — which should not be automated. Anything where a mistake is expensive keeps a human approval in the loop.

What it is not: a chatbot bolted onto your website, or a promise that software will run your business unattended. If a step is better handled by a simple rule, the Blueprint will propose a simple rule.


When we tell you not to build

A discovery process that always concludes "build" is a sales process. These are the answers that mean you should not commission a custom system — and when we find them, the Blueprint says so plainly.

  • A good off-the-shelf tool already fits. If your process is standard and an existing product handles it without a spreadsheet alongside, buy the product. We will say which kind of tool to look for.
  • The process is not stable yet. If the way you work is still changing month to month, software will freeze it at the wrong moment. Settle the process first.
  • The numbers do not work. If the time and errors a system would remove are worth less than it costs to build and run, it is not worth doing — however appealing it looks.
  • The problem is not software. Sometimes the bottleneck is a missing role, an unclear responsibility or a supplier issue. No system fixes those.
  • Nobody can own it. A new system needs someone inside the business to champion it for its first few weeks. Without that person it becomes one more tab.

A Blueprint that ends in "don't build" still leaves you with a map of your own workflow, a list of the bottlenecks and a clear reason for the decision. That is a better outcome than a system nobody uses.


What it costs, and what happens to the fee

The introductory price is £500–£1,000, and it is free for selected early customers. If you go ahead with a build, the Blueprint fee is credited toward development.

If you do build, you own the result: code, infrastructure and documentation. Why that matters — and why paying for software does not automatically mean owning it — is covered in You Paid For It. In Most Countries, That Doesn't Mean You Own It.


How to prepare

You will get more from the session if you do four things beforehand:

  1. Pick one workflow. The one that causes the most friction, not the whole business at once.
  2. Find three real examples of it — including one that went wrong.
  3. List the tools involved, subscriptions included, and the spreadsheets that sit between them.
  4. Decide what "better" means. Fewer hours? Fewer errors? Customers who stop chasing? A clear target makes the savings estimate honest.

For a worked example of what this looks like in one sector, see Your Wholesale Order Book Is Still Email and Excel and our wholesale and distribution page.

When you are ready, book a Blueprint session or simply show us your workflow. You can also read more about how we build custom operations software for growing businesses.

Keep reading

Business & Strategy

You Paid For It. In Most Countries, That Doesn't Mean You Own It.

Public registers only work where you can read the filings. Here is the version that works in any jurisdiction: the ownership default that surprises most buyers, the five things an assignment clause has to settle, and the hand-back drill you run at 25% of the build.

Symentic Team12 min read