Workflow Assessment Before the Build

Assess the workflow before recommending the build.

That sounds obvious until a real AI conversation starts. Someone has a stuck process, a team is losing hours to repeated manual work, and a demo makes it feel possible that an agent could take the whole thing off their plate. The temptation is to jump straight from frustration to build.

Build questions are useful eventually. They are not the first questions.

The first question is whether the workflow is understood well enough to recommend anything responsibly. Most AI requests arrive as a proposed solution, but the real issue may be elsewhere: missing information, unclear ownership, an unnamed approval, a handoff that drops context, or a person who routes every exception. That is why most AI problems are operational problems before they are model problems.

A Workflow Assessment is the paid first milestone for that reason. It is a focused look at one real workflow before a build is recommended. It is not a vague discovery phase, and it is not a disguised sales meeting. The purpose is to inspect the work closely enough to make a clear recommendation: build an agent, build conventional software, buy something that already exists, change the workflow, improve documentation, hire differently, gather more evidence, or do nothing for now.

The output is a recommendation, not a pile of options.

Why The Assessment Is Paid

Good assessment work takes actual work. It requires preparation before the call, review of real materials, mapping how the process moves, identifying where the work waits or repeats, separating symptoms from bottlenecks, and writing down a recommendation the buyer can use.

That is different from a no-cost fit call. The first call is short, usually 20-30 minutes, and exists to decide whether there is a real workflow worth inspecting. It should help both sides understand whether the problem is ready for paid work. It should not pretend to solve the workflow in real time.

The Workflow Assessment begins when there is enough evidence to look closely. It usually falls between $2,500 and $7,500, depending on complexity. A narrow workflow with a few known systems, clear examples, and one decision owner is smaller. Multiple teams, messy handoffs, and unclear approval paths take more time to inspect responsibly.

If the assessment recommends a custom build and work begins within 30 days, the assessment fee is credited toward the build. That matters because the assessment is not meant to become a toll booth between the buyer and useful work. If the right answer is to build, the money carries forward. If not, the buyer still receives something useful.

Bring One Workflow

The most helpful customer homework is simple, but it needs to be real.

Pick one workflow. Not "operations" or "all the manual stuff around customer onboarding." Choose one path of work that starts somewhere, moves through people and systems, and ends with an output.

Then bring 3-5 real examples. The last few times the workflow happened are usually better than a polished requirements list. Bring the request that came in, the documents people checked, the messages that clarified missing context, the spreadsheet or system of record, the output that was produced, and the place where someone had to make a judgment call. If there was an edge case, bring that too. Edge cases often reveal the real shape of the work.

Name the people involved. Who starts the process? Who receives it? Who gets interrupted when the input is incomplete? Who approves the output? A workflow map without people is just a diagram of motion. The useful version shows responsibility.

Share supporting artifacts: forms, emails, tickets, reports, policies, spreadsheets, screenshots, templates, CRM records, meeting notes, or whatever the team actually uses. The awkward artifacts are often most valuable because they show where the organization has been compensating manually.

Finally, name the business outcome. Faster is not always specific enough. Faster response to whom? Fewer interruptions for which role? Better review of what risk? The assessment needs to know what improvement would make the work worth changing.

What Comes Back

The assessment should make the work visible enough to decide.

The first piece is a workflow map: the trigger, inputs, systems, people, handoffs, decisions, outputs, review points, and failure modes. It needs to be plain enough that the buyer can say, yes, that is how the work really moves.

The second piece is bottleneck analysis. The requested tool may be plausible and still not address the thing that limits the workflow. Maybe the slow part is not drafting the response, but finding the correct source material. Maybe the issue is not classification, but deciding who owns the exception. Maybe the team asks for an agent because the visible pain is manual work, while the deeper pain is that nobody trusts the input data.

The third piece is ranked interventions. Real workflows rarely have only one possible improvement. There may be a documentation fix, a SaaS option, an internal tool, an agent-assisted review process, and a larger custom build. But ranking options is not the same as handing the buyer a menu and walking away.

The fourth piece is one primary recommendation. That recommendation should say what to do next, why it is the highest-leverage move, what evidence supports it, what risks remain, and what should be excluded from the next step. If custom work is justified, the assessment can become the basis for a fixed-scope proposal with objective, deliverables, exclusions, acceptance criteria, timeline, and price.

If custom work is not justified, the recommendation should say that too.

Sometimes The Answer Is Not An Agent

This is the trust point.

A Workflow Assessment is useful only if it is allowed to recommend something other than the thing the buyer first imagined. Sometimes the right next step is an agent. Sometimes it is conventional software with no model in the middle. Sometimes it is an existing product the buyer should purchase instead of commissioning custom work. Sometimes it is a better intake form, clearer documentation, a changed handoff, a policy decision, cleaner data, a different hire, or no action until the workflow happens often enough to justify investment.

That is not anti-AI. It is how AI work becomes useful.

Agents work best when they have a defined lane: repeated cases, available inputs, reviewable outputs, known owners, and clear boundaries around human judgment. If those conditions are missing, the system will inherit the confusion. It may draft, route, or summarize faster while the real decision remains unresolved.

Good assessment protects the buyer from that. It slows the jump from "could we automate this?" to "what should exist?" long enough to inspect the actual work. A custom system built around an undefined workflow turns every hidden assumption into a future support problem.

The Assessment Is Portable

The buyer should be able to use the assessment even if they do not build with Aboriginal Armadillo.

That portability is part of the point. A workflow map, bottleneck analysis, and written recommendation should help the organization make a decision, align internally, talk to another vendor, compare a SaaS product, or fix the process themselves. If the assessment only has value when it converts into the next sale, it is not really serving the buyer.

The decision still belongs to the buyer. The assessment does not remove business judgment. It gives that judgment better material to work with. A good recommendation reduces uncertainty enough for a responsible next step. It does not pretend that every risk has disappeared.

That is also why the recommendation should be specific. "AI could help here" is not enough. "Build a review assistant that gathers these inputs, prepares this decision packet, flags these exception types, and leaves approval with this role" is something a buyer can evaluate. So is "do not build yet; standardize the intake form and collect 10 more examples first."

Before The Build

The Workflow Assessment is the first paid milestone because it creates what the buyer needs before it creates software.

Before a build, the buyer needs to know what workflow is being changed, where the bottleneck sits, what inputs are available, what output matters, where review belongs, and who owns the decision.

Skipping that work can make a project feel faster at the beginning. It usually makes it slower later. Examples are missing, exceptions appear after the first demo, approval paths shift, and the system produces an output that does not move the decision forward.

Assessment is not bureaucracy. It is how the build earns its shape.

If the answer is custom work, the assessment gives the build a clear lane. If the answer is something else, it prevents a custom project from becoming an expensive way to learn what should have been inspected first.

That is the buying clarity: the first paid engagement should help the buyer make a decision, not pressure them into a build. Assess the workflow. Name the bottleneck. Recommend the next move. Build only when the work justifies it.