Key Takeaways
- Start from one workflow that costs real time every week, not from a tool.
- Give the month a fixed shape: agree success, map the work, prototype one use case, then decide.
- Record a baseline in week two so the prototype can be judged on evidence rather than opinion.
- Keep the first use case small enough for real users to test before the month ends.
- Close with a clear decision to scale, change or stop, and whether to build or train.
Why a month is the right unit
Mid-size companies sit in an awkward spot with AI. They are too large for one enthusiastic person to change how everyone works, and usually too lean to fund a dedicated team that spends a year on research. What tends to happen instead is a scatter of individual experiments: someone in marketing uses a chatbot for drafts, someone in finance tries a spreadsheet add-in, and nobody can say whether any of it matters.
A 30-day plan puts a boundary around the first serious effort. A month is long enough to understand one area of the business properly and put a working prototype in front of the people who would use it. It is short enough that leadership stays engaged and the work cannot drift into a programme with no end date. The aim is not to change the whole company in four weeks. It is to make one well-informed decision, backed by evidence from your own operations. This is the shape Artifex uses at the start of many engagements, and you can run it with your own people, with a partner or with both. Before the clock starts, settle three things.
- Name one senior sponsor.Someone who can decide on budget, priorities and people, and who will attend the review at the end of the month. Without a sponsor, findings tend to become a slide deck that nobody acts on.
- Pick one area of the business.Choose a department or a single end-to-end process, such as customer onboarding or supplier invoicing. Surveying the whole company in a month produces a long list and very little depth.
- Form a small working group.A few people who do the work in that area, someone who understands your systems and data, and one person to run the plan day to day. Protect a few hours of their week for the whole month.
Week 1: agree what success means
The first week is about alignment rather than technology. Interview the sponsor and the people who lead the chosen area. Ask what slows them down, where errors creep in, which tasks people dread and what a better month would look like. Then speak to a handful of frontline staff, because their answers are often different and more precise.
By Friday, write a one-page brief. State the business goal in plain language, the constraints you must respect, such as data sensitivity, regulation or systems that cannot change, and how success will be measured. If the goal is to answer customer queries faster, say so, and note how that time is measured today. It is the same thinking behind our AI strategy and roadmap work, applied to a narrower slice.
Week 2: map the work as it really happens
In week two, the working group documents the process step by step. Sit with the people doing the work and follow a few real cases from start to finish. Note each step, who does it, which system it touches, how long it takes and where work goes back and forth. Process documents are a useful starting point, but they rarely match a busy day.
Pay particular attention to steps that involve reading, sorting, summarising, drafting or copying information between systems, because that is often where AI helps. Steps that depend on judgement, relationships or accountability usually stay with people, perhaps with AI preparing the groundwork. We cover this stage in more depth in our five-step workflow audit. As you map, capture four things for each step:
- Volume: how many cases pass through it in a typical week.
- Effort: roughly how long it takes and which role does it.
- Quality: where errors, rework or complaints tend to appear.
- Data: which documents, systems and fields it relies on.
Week 3: choose one use case and prototype it
Start week three by listing every opportunity the mapping revealed and scoring each against three questions. How much value would it create if it worked? How feasible is it with the data and systems you have? What could go wrong, and how serious would that be? A simple grid agreed with the sponsor keeps the choice fair and easy to explain. Agree the weighting before anyone scores, so the result reflects what matters most to the business rather than who argued hardest.
Pick one. Favour something contained, frequent and easy to check, such as drafting first replies to routine queries for a person to review, over something that touches many systems at once. Then build the simplest prototype that lets real users try it on approved examples. It does not need to be integrated or polished. It needs to show whether the idea holds up.
A rough prototype tried by the people who do the work tells you more than a polished plan that nobody has tested.
Week 4: test, measure and decide
In the final week, let the working group use the prototype alongside their normal work. Compare the results with the baseline from week two. Did it save time on the cases it handled? Was the output accurate enough to trust with a review step? Did people find it easier or harder than the current way of working? Capture their comments as well as the measurements.
Close the month with a review meeting. Present what you learned, what the prototype showed and what it would take to run it properly. Then make a clear decision: scale it, change it and test again, or stop and move to the next idea on the list. Stopping is a good outcome if the evidence points that way, because the mapping and scoring still feed the next round.
After day 30: build, train or both
If the use case earns a place, the next question is who takes it further. Some companies want a partner to build, integrate and maintain the solution. Others want their own people to learn how, so the capability stays in-house. Many do a bit of both, and we explain how to weigh the options in Build or Train?
Whichever route you take, keep the rhythm the month established: a named sponsor, a clear measure of success, real users involved early and a decision point at the end of each stage. That rhythm is what turns one promising prototype into a steady flow of useful improvements, and it mirrors the four stages of our process.