Every implementation goes wrong in the same place. Not in the code, and not in the demo. It goes wrong in the gap between what an owner knows about their business and what they manage to say out loud about it.

After a couple of hundred of these, we have noticed that owners tend to arrive in one of seven ways. None of them is the wrong way. But each one needs something different from us, and something different from you, and knowing which one you are saves weeks.

"I am busy. Make the billing work."

You have a business to run and no interest in a meeting about screens and databases. That is entirely fair, and it is the most common way owners come to us.

What this needs from you is not time. It is access to the person who actually does the work: whoever raises the bills, enters the purchases, chases the payments. We will learn the workflow from them and come back to you only when something needs a decision that only an owner can make. Your part is the decisions. Ours is the rest.

"Talk to my brother, he understands computers."

Also fair, and also common. Somebody in the family is the technology person, and you would rather they handled the technical side.

One thing is worth saying. Your technical person can judge whether something is built properly. They cannot judge whether it matches how your shop actually trades, because they are not the one trading. If the requirements come only from them, the result is usually sound software that fits a business slightly different from yours.

So let them take the integrations, the hardware and the infrastructure. Keep the part about how purchases, billing, stock and payments really work for yourself, or for whoever does that work daily.

"I have looked at twenty systems already."

Then you have sat through more demonstrations than most of the people giving them, and you can probably drive half those products better than their salespeople. That is genuinely useful to us, and it changes what the first conversation should be.

There is no point showing you a feature list. You have seen feature lists. The question worth asking is the opposite one:

After looking at twenty systems, what was still unsolved?

Whatever you name there is the actual requirement. Everything else is already a solved problem in any decent product, ours included.

"I already have three trials running."

Install another if you want to. But four trials in, the screens start to blur, and it gets harder to tell the products apart rather than easier. Everything begins to look like everything else, and the decision gets postponed again.

There is a way to make trials decide something. Before you start the next one, write down the five things your business does that matter most. Not features — situations. For example:

• How a purchase gets made and recorded
• What happens when goods arrive and the bill does not match
• How a sale gets billed on a busy evening
• How you know what a customer still owes
• How you decide what to reorder

Then put every product through those five, in that order, using your own items and your own numbers. The question stops being "does this have a lot of features" and becomes "can this handle the way we actually work". Only the second question has an answer.

"I know what I need. I cannot explain it."

This one is more common than owners expect, and it is not a failure of expression. You have run the business for years, and most of it now happens without conscious thought. Being asked to describe a workflow is like being asked to describe how you walk.

So do not describe it. Show us one real transaction, start to finish: how the enquiry arrives, how the order is raised, how you purchase, how the goods come in, how it gets sold, how the money is collected, and what normally goes wrong along the way. We will ask the questions as we go.

Half an hour watching a business trade tells us more than a twenty-page requirement document, and it is far less work for you.

"Meet me weekly, but finish what we discussed."

This is a good way to run a project, and the condition attached to it is the right one.

It works like this. We agree a small set of things for the week. We build them. You look at what was actually built, not at a plan for it. Then we agree the next set. Build, review, adjust, repeat.

The alternative is a requirements phase that keeps growing, where each meeting adds more than it settles and the first thing discussed is still not built three months later. A short cycle with something finished at the end of it keeps that from happening.

"I will know what I need once I start using it."

This is probably the most honest of the seven, and the one most owners end up in eventually. You can watch demonstrations all week, and then use the software for two days and realise your business does one step completely differently.

That is normal, and it is not a sign the requirements were gathered badly. Some things only become visible under real use.

The way to handle it is to get the fundamentals right first — products, purchases, stock, billing, customers, payments, reports — and then start trading on it. As real situations come up, keep a running list, sorted honestly:

Must have → Important → Useful later → Interesting idea

That list is what stops one fear from stalling an entire project: what if I need something later that the software cannot do? No product can predict every future requirement, and any vendor who claims otherwise is guessing. The better question is whether the system can be changed as the business changes, and who will do that work.

Most owners are several of these

You might be the first type on a Monday morning, the third during a demonstration, the fifth when we ask about your workflow, and the seventh two weeks after going live. That is not inconsistency. It is what happens when a real business meets a real implementation.

None of this is about categorising customers. It is about removing the one thing that actually delays projects, which is two sides being sure they understood each other when they did not.

If you know which of these sounds most like you, say so at the demo. We will start there instead of starting with a feature list.