AI consulting services: what you should get in the first 30 days

In the first 30 days, AI consulting services should give you a mapped workflow, a written definition of a correct output, a set of real test cases, a thin working slice connected to at least one real system, a list of risks with owners, and a clear decision to proceed, change scope, or stop.

That is a higher bar than many engagements set. A month is long enough to replace assumptions with evidence, and short enough that stopping is still cheap. If the first month ends with only interviews and a strategy document, you have paid for a description of the problem, not progress on it.

Why the first month often disappoints

AI consulting sits awkwardly between strategy and engineering. Strategy work is easy to deliver in documents, and documents feel like progress. Engineering work is harder to show early, because the first useful artifact is often a small, unglamorous pipeline that reads real data and produces checkable output.

The result is a common pattern. Weeks one and two are interviews. Week three is a workshop. Week four is a roadmap with a long list of opportunities ranked by estimated impact. Nothing has touched a real system, so every estimate in the roadmap is still a guess.

There is a second cause: unclear access. Many engagements lose their first two weeks waiting for credentials, sample data, or a meeting with the one person who knows how the process really works. That is not the consultant's fault, but a good engagement plan anticipates it and front-loads access requests.

What teams often get wrong when buying AI consulting

Buyers often ask for too much in the first month and get too little. A request to find all the AI opportunities in the business produces a broad map. A request to prove whether one workflow can be improved produces a decision. The second is almost always more valuable as a starting point.

Another mistake is accepting a demo as a milestone. A demo built on sample data, with no permissions, no error handling and no record of what it did, proves the model can generate plausible text. It does not prove the workflow can run. Ask for milestones that include a real input source and a reviewable output.

A third mistake is leaving evaluation undefined. If nobody writes down what good looks like, the engagement drifts toward whatever impresses in a meeting. Evaluation criteria belong in week one, not at the end.

A practical 30-day structure

The exact shape depends on the workflow, but a useful first month for AI consulting services usually moves through four stages.

Week one: map and access

• Walk through the target workflow with the people who run it, including exceptions and workarounds.
• Collect real examples: inputs, current outputs, and the cases people describe as difficult.
• Request system access with production-like permissions, not an administrator account.
• Write a first definition of a correct output, reviewed by the process owner.

Week two: evaluate the approach

• Build a small test set from the real examples, with expected outputs or grading notes.
• Compare candidate approaches, which may include rules, retrieval over your documents, a general model with good instructions, or a combination.
• Identify which inputs are sensitive and how they will be handled.

Week three: build a thin slice

• Connect one real input source and one real output destination.
• Add logging so every run can be reconstructed: input, output, version, and reviewer decision.
• Put a human approval step in front of anything that writes to a customer-facing system.

Week four: measure and decide

• Run the thin slice against the test set and a batch of fresh cases.
• Document failure types, not just a pass rate, and which ones are fixable.
• Produce a decision memo: proceed, change scope, or stop, with the effort drivers for the next phase.

The decision memo is the most important artifact of the month, so it is worth being specific about what it contains. At minimum it should state the recommendation in one sentence, the evidence behind it drawn from the test set and the logs, the failure types that remain and whether each is fixable, the data or access problems discovered, the risks that need an owner, and the effort drivers for the next phase. It should also say what was not tested, so nobody reads more certainty into the result than the month produced.

Implementation considerations

The thin slice should be real but disposable. It exists to answer questions: can the data be read reliably, does the approach produce acceptable output on real cases, and where does it break? It does not need a polished interface. It does need honest logging, because the logs are the evidence behind the decision memo.

Keep model configuration out of the code path where possible. Models, regions, and instructions change more often than the surrounding logic. If switching a model requires a code change and a redeploy, teams tend to stop experimenting early. A configuration layer that can be changed and rolled back without a release makes the evaluation stage much cheaper.

Plan for provider failure from the start. External model providers time out, rate-limit and occasionally return errors. The thin slice should show a clear, human-readable failure state and retry transient errors within limits, rather than hanging or presenting a confident answer that was never generated.

Finally, agree on ownership before the month ends. Someone on your side should understand how the slice works, where its configuration lives, and how to read its logs. If the engagement ends and nobody can operate what was built, the first month has created a dependency rather than a capability.

Trade-offs

Building a thin slice in the first month costs more than a pure discovery phase. It also produces evidence that discovery cannot. For workflows that touch real customers or real money, that evidence is usually worth the extra effort. For purely exploratory work across many departments, a shorter discovery phase may be the right first step.

Narrow scope trades breadth for confidence. Focusing on one workflow means you will not have a complete opportunity map after a month. You will have a validated answer for the workflow that mattered most, and a much better sense of what the others will cost.

Fixed-scope first months are easier to budget but can push a consultant to deliver the planned artifact even when the evidence suggests a different direction. A small amount of flexibility, agreed upfront, lets the engagement follow what the test cases reveal.

Lessons from ImadDhin work

The following are code-level observations from the portal's own AI features and the public FoCoCo case study. They illustrate the engineering concerns that should appear in a first month; they are not client outcomes.

In the portal's agent workspace, model name, region and base instructions are read from remote configuration rather than hard-coded. That makes it possible to compare or roll back models without redeploying the site. The same agent separates free and paid capability at the server route, so a gated feature cannot be unlocked by changing the browser.

The agent also maps provider failures to a specific user-facing error message instead of silently falling back to its static introduction text. That detail sounds small, but it is exactly the kind of behavior a demo skips and production needs: a visitor should know the request failed, not receive a greeting that looks like an answer.

The FoCoCo case study shows the other end of the spectrum: a product engineered end to end across a phone app, a web app, a shared backend and real-time voice. Work at that scale is not a first-month deliverable. It is what a good first month should make possible, by settling data, evaluation and ownership questions early.

Common mistakes to test for

• Check whether the thin slice reads real data with the permissions it will have in production.
• Feed it the difficult historical cases operators remember, not only representative ones.
• Simulate a provider timeout and confirm the failure is visible and understandable.
• Confirm that every output can be traced to its input, model version and instructions.
• Verify that nothing writes to a customer-facing system without the agreed approval step.
• Ask someone on your team to change a configuration value and roll it back without the consultant present.

When a simpler solution is better

Not every problem needs a consulting engagement. If you already know the workflow, have the data in one place, and need a single well-defined feature, a scoped build may be faster than a discovery-led month. The six-step project brief is often enough to start that conversation.

Likewise, if an off-the-shelf tool already handles the workflow and your team can configure it, paying for custom AI consulting is hard to justify. The first month should include an honest comparison with buying, and it is a good sign when a consultant recommends the cheaper option.

Ask for evidence, not a roadmap

When you evaluate AI consulting services, ask what you will be able to see, run and decide at the end of the first 30 days. A mapped workflow, real test cases, a thin working slice and a decision memo give you something to act on, whichever way the decision goes.

Explore AI automation consulting, see how engagements are structured, or discuss your first month in a 30-minute call.