What an AI systems consulting engagement actually looks like for an SME

Most SME owners hearing the phrase “AI systems consulting” want to know one thing: what will actually happen in the room, and what does the team have to carry. This is the short version. Four stages, usually three to six elapsed weeks for the first useful system, and a working software outcome the team owns at the end.

The shape of the work

An engagement is not a fixed-price feature build, and it is not advisory by the hour. It is a small, focused piece of consulting plus implementation aimed at one system: the first place inside the business where better context and a useful AI workflow will change what the team can get done.

The shape changes with the business, but the work keeps the same bias. Find the useful first system, build enough to prove it in real work, and keep people in control.

Stage one: diagnose

Diagnose is the part most consulting projects skip or rush. It is a structured look at the business outcome, the current workflow, the people involved, and the context the work depends on. The output is a short written brief that names the pressure point, the decision points worth keeping human, and the data and tools the system will rely on.

• Workshops with the owner and the team carrying the work today.
• A walkthrough of the real workflow, not the version on the org chart.
• A look at the data, documents, and tools the work already runs on.
• A short written brief, agreed by both sides, before any code is written.

If the right next step turns out to be smaller, sharper, or not AI at all, this is the stage where that is said. Diagnose usually takes one to two weeks of elapsed time and a modest amount of team attention.

Stage two: design

Design shapes the first useful system. That means inputs, data sources, review points, failure modes, and what success should look like for the people actually using it.

The design is not a wireframe deck. It is a working description of how the system reads the world, what it produces, where a person checks it, and what happens when something goes wrong. The point is to make the system legible to the team before anything is built.

Stage three: ship

Ship is the build. Lucumo writes the software, connects the relevant tools, and gets the first version into real use. The standard is usable enough for real work rather than a detached demo. That bar is deliberately set above “proof of concept” and below “polished product”.

For most engagements, ship takes two to four weeks of elapsed time. The team is not asked to run a parallel internal project. The work lands as a usable system, not as new backlog.

Stage four: adopt

Adopt is where many AI builds quietly die. A system that nobody uses is worse than no system at all, because it leaves a trail of disappointed expectations behind it.

Adopt is a short, intentional handover plus a follow-on period where Lucumo helps the team fold the system into the operating rhythm, improve it from real use, and decide what should come next. The engagement ends when the team can run, change, and explain the system without Lucumo in the room.

What the team has to do

Honest answer: less than most internal projects, but not nothing. The team needs to carve out time for the diagnose workshops, to be reachable during ship for the small decisions only they can make, and to actually use the system once it lands. If a team is too busy to do those three things, the system will not stick, and an honest engagement will say so up front.

What you get at the end

• A working software system the team uses for real work.
• A written brief describing the workflow, the system, and the decisions baked into it.
• Adoption support so the system is operated by the team, not by Lucumo.
• A clear view of what the next useful system could be, if there is one.

If that shape sounds like the right kind of help for the work in front of you, the next step is a short enquiry. A human reads it and replies within one to two working days.