Start with the process, not the tool
The most common opening message we get is some form of “I can see how fast things are changing, but I don't know where to begin.” If that is roughly where you are, you are in the normal place, and the first move is smaller than it looks.
It is not choosing a product. Nearly every project that goes badly started by picking the tool, and it went badly for the same reason every time: the tool arrived before anyone had agreed what it was supposed to do.
The first move is picking one process that matters and writing down how it actually runs today. Not how it is supposed to run. How it runs, including the bit where someone re-keys it into a spreadsheet on a Friday.
Four things, in this order, before you buy anything
- Pick one process, and make it one that costs you something. If it stopped tomorrow, somebody would notice. That is the test.
- Write down how it works now, end to end, including who touches it, what they open, and where it gets re-typed. Most people find something in this step that can be fixed without any software at all, and that is a good outcome rather than a wasted one.
- Write down what ‘better’ would look like as a number. Hours, days, error rate, how often it is late. If you cannot state it, you will not be able to tell whether the project worked, and neither will anyone you pay.
- Only then look at what to build. By this point the question has changed from what AI should we get to what would have to be true for this specific thing to run itself, which is answerable.
The cheapest way to find out whether it is worth it at all
Steps one to three cost you an afternoon and no money, and they are worth doing whether or not you ever buy anything. They are also the thing any competent supplier will ask you for, so doing them first puts you in a much stronger position in every conversation that follows.
If you would rather have a second opinion on which process to pick, that is what our assessment does. Ten minutes, and the written result is yours.
What not to do first
- Do not start with a company-wide rollout. The failure is expensive and, worse, it teaches everyone in the business that this does not work.
- Do not automate a process nobody agrees on. You will encode one person's version of it and make the disagreement permanent.
- Do not take a prototype as evidence of a timeline. Something impressive built in a week is genuinely impressive and tells you almost nothing about running it in the business.
- Do not buy the platform before the problem. The licence renews whether or not anybody used it.