AI workflow blueprint: decide where automation belongs before you build
An AI Workflow Blueprint is a paid project, normally two to four weeks, that ends in a decision. It maps one workflow or one small group of workflows, tests where AI would actually help, and hands back a scope you can approve, change or stop. It is a step you buy, not a free proposal, and not a pilot you end up paying for twice.
Submit a project See the automation build serviceReviewed by David (CEO) · Updated 23 Sep 2026
What the blueprint produces
Most AI spending decisions fail on the same three questions: which work is worth automating, whether the data supports it, and what a correct result looks like. The blueprint answers those three questions with evidence, and records what it could not answer.
At the end you hold a prioritized roadmap, a target workflow design, a prototype where one is justified, a technical architecture, a risk list, a data plan, a baseline of the measures you care about, and an implementation scope. You also hold the option to stop. A blueprint that recommends doing nothing has done its job.
What is in scope
The service covers the assessment and design work that sits in front of an automation build, and nothing else. Typical engagements include:
-
AI opportunity review
Listing the candidate workflows across a team or function, sizing each one by volume, handling effort, error cost and data readiness, then ranking them.
-
Workflow redesign
Describing how a chosen process would run if AI handled part of it, including the exception routes and the point where a person decides.
-
Data-readiness assessment
Checking whether the records, documents or logs the workflow depends on exist, are accessible, are accurate enough and may lawfully be used for this purpose.
-
Agent feasibility
Testing whether a workflow can safely be handed to tool-using software at all, or whether it should stay as a narrow assisted step.
-
Build-versus-buy analysis
Comparing a configured product, a platform module and a custom build against the workflow you actually have.
-
Architecture and integration design
The systems, interfaces, permissions and boundaries an implementation would need.
-
Measurement design
The evaluation cases, thresholds and baseline metrics an implementation would be judged against.
The other engagements in the catalogue are listed on the services page. The blueprint is the front door to most of them.
Good fit and poor fit
Good fit
- You have a budget question to settle and want evidence before you commit to a build
- A named process owner can describe how the work runs today and who owns the result
- You can grant read access to the systems, samples and documents the workflow uses
- A decision is genuinely open, including the decision not to automate
Another route fits better
- You already know the workflow and the acceptance rule, and just want it built
- Nobody can be released to answer questions for a few hours a week
- No access to real examples is possible, so findings would rest on description alone
- The outcome is already fixed and the study is wanted as internal justification
What the blueprint is not
Three things are regularly bought under this name by mistake.
It is not a production build. The prototype, where one is built, exists to test a hypothesis and is not deployed to users. When the workflow is already understood and the argument is settled, go straight to AI Workflow Automation, or to Custom Product Engineering when the outcome is a product rather than a process.
It is not a health check of your existing systems. If the real question is whether a codebase, cloud setup or security posture is sound, that is a technical audit sprint, which produces an evidence pack instead of a design.
It is not a way to unblock a platform that cannot carry the workflow in the first place. Where the blocker is an ageing application, legacy application modernization comes first and the blueprint follows it.
What we will ask for at the start
A first review moves faster with a plain description of the workflow and roughly how often it runs, the systems and documents it touches, a handful of real examples with private details removed, who owns the result today, and any hard constraint such as a regulator or a data residency rule. Gaps are normal; they become questions in the first week.
Deliverables
The exact list is agreed before the project starts. A typical blueprint delivers:
- a current-state map of the workflow: steps, systems, volumes, exceptions, decision points and the person accountable for each result;
- a ranked opportunity list with the reasoning for each position, including the candidates that were rejected and why;
- a data-readiness finding per candidate: what exists, what is missing, what is usable and what the rights position is;
- a target workflow design showing what the software does, what a person does, and what happens when the software is unsure;
- a prototype where one is justified, with the question it was built to answer and the answer it gave;
- an architecture and integration outline with the permission and data boundaries it assumes;
- an evaluation plan: representative cases, the definition of a correct result, and the threshold a build would have to meet;
- an implementation scope and milestone outline ready to be turned into a proposal, with the assumptions it depends on stated.
How the work is done
-
Map and measure
Walk the workflow with the people who run it, record the steps and exceptions, and collect real examples. Establish the baseline you will later be measured against.
-
Assess the data and the rights
Check the records the workflow depends on for availability, quality and permitted use, and write down what would have to change.
-
Test the candidates
Shortlist the options, and where a question can only be settled by trying it, build a narrow prototype against real examples rather than arguing from a demonstration.
-
Design, scope and decide
Produce the target workflow, the architecture, the evaluation plan and the implementation scope, then hold a decision session where you choose to proceed, change direction or stop.
Netbase delivers remote-first from Hanoi in Agile increments with weekly reviews, using AI-assisted engineering under human review. A blueprint team is small and is drawn from the roles the work needs, usually business analysis, solution architecture, development and project management. The project delivery page describes how a Netbase project is planned, reported and accepted.
Milestones and acceptance
A blueprint runs as two or three milestones inside a fixed timebox. Each one names its deliverables, the access and decisions it needs from you, and how it will be accepted. Most Netbase projects are agreed as fixed-scope contracts after discovery; a blueprint is often the discovery that makes such a scope possible, and the engagement models page explains how the arrangements differ.
Acceptance is a review of documents and, where a prototype exists, a demonstration against the examples it was built for. The closing deliverable is the decision session itself: the record of what was recommended, what you chose, and what was left open.
Risks we plan for
The most common finding. It is reported as a finding with the work it would take, not hidden inside an optimistic scope.
Where accountability is unclear, the blueprint says so, because an automation without an owner cannot be accepted or corrected later.
Every prototype is labelled with its purpose, its limits and the reasons it must not be put in front of customers as it stands.
Whether the data may lawfully be used for this purpose is checked in the first milestone, not at the end.
Secure code review and version control, role-based access control and multi-factor authentication for admin dashboards are standard practice, contributors work under NDA, and NDAs and data processing agreements are available on request.
Models, data and human review
The blueprint is model-agnostic. Netbase works with commercial and open-source AI models chosen per project, based on the task, where the data may sit, operating cost and your own constraints. No vendor partnership is implied by a recommendation, and a shortlist that names a model also names the conditions under which it would be reconsidered.
Where your rules restrict AI tool use, for example on confidential source code or regulated records, that restriction is agreed before the project starts and applied to both the analysis and any prototype. Every recommendation in the pack is reviewed and owned by a named Netbase engineer or analyst; output from a model is never presented as a finding on its own.
Frequently asked questions
Two to four weeks is the normal timebox for one workflow or a small related group. A wider portfolio review is scoped as its own project.
No. The pack is written so that another supplier, or your own team, could implement from it. That is a deliberate test of whether the documentation is good enough.
That is a valid and fairly common result. The pack then records why, what would have to change for the answer to differ, and which cheaper non-AI change is worth making instead.
Sometimes. When the workflow is well understood, the data is known to be usable and the acceptance rule already exists, a build can be scoped directly. When it is not, a fixed scope quoted in the dark helps nobody.
The process owner, someone who can grant read access to systems, and whoever will make the decision at the end. A few hours a week each is usually enough.
It stays with you, with its limitations documented. It is a test artefact. Turning it into something people use is a separate build, and the blueprint says what that would involve.
Evidence and related work
Netbase has delivered anonymised client AI projects including retrieval-based knowledge assistants, document AI and MLOps pipelines. The anonymized delivery records on the Work page state what each one can and cannot prove, and the methodology page sets out the rules those records follow.
Ready to settle the question?
The natural next step from an approved blueprint is AI Workflow Automation, which builds and pilots the workflow the blueprint designed, and managed operations when you want the result monitored and improved after handover. Submit a project brief describing the workflow, who owns it and the decision you are trying to reach. OutsourcingVN is operated by Netbase JSC and is Netbase's own outsourcing-services platform.