How an AI Implementation Diagnosis Works
Tomohiro Iida · Published July 11, 2026
An AI implementation diagnosis is a short, structured assessment that identifies which of a company's internal operations are worth applying AI to, before any tool selection or proof-of-concept work begins. Many organizations get stuck at exactly this first step: they know they want to use AI but cannot decide which task to start with. This article uses Netsujo's own AI Applicability Diagnosis package (JPY 300,000, excluding tax, 10 business days) as a concrete example of what such a diagnosis reveals, how the process runs, what the cost covers, and what options exist afterward. All figures and deliverables described here are drawn from data Netsujo publishes on its own pricing page.
Key takeaways
- An AI implementation diagnosis inventories business processes, identifies candidate areas for AI application, estimates ROI, and produces an implementation roadmap. Netsujo provides this as a fixed-price package: 10 business days for JPY 300,000, excluding tax.
- What a 10-business-day diagnosis delivers is a decision-making package: which processes to target, in what priority order, and with what expected effect. It does not include building the AI system or running a proof of concept (PoC).
- After the diagnosis, there are three options: proceed in-house, select an external vendor, or commission the diagnosing company for development. The diagnosis widens the comparison material available but does not guarantee a successful outcome.
What the diagnosis is
An AI implementation diagnosis is the process of identifying, before any tool is selected or built, where in a company's operations AI should be applied, estimating the likely effect, and deciding the order of implementation. Netsujo provides this as a fixed-price, 10-business-day package for JPY 300,000 (excluding tax). The diagnosis discussed here is specifically about whether and where to apply AI to internal operations; it is a separate service from a diagnosis of how a company's website appears in AI search (AIO, meaning AI search visibility and optimization). Before moving to a PoC or a tool rollout, three questions need answers: where AI should be applied, whether applying it there is worth the cost, and in what order multiple candidate areas should be pursued. Proceeding to a PoC or tool adoption while these three are still unclear tends to produce a PoC that is tried but never adopted, or one whose budget cannot be justified because its effect cannot be explained.
What you learn
| Deliverable | What it tells you |
|---|---|
| Process interviews (two 90-minute sessions) | An overview of which of the company's operations are candidates for AI application |
| Report identifying 3–5 candidate areas for AI | Which operations generative AI or LLMs are likely to fit, and the reasoning behind it |
| Per-area ROI estimate | Estimated cost savings or revenue gain for each candidate area, stated together with its assumptions |
| Implementation priority order and roadmap (3–6 months) | The order and steps for moving into implementation |
| Vendor-selection reference material | What to require from vendors, and what to compare, when commissioning the work |
These five deliverables turn a vague intention to "do something with AI" into a specific proposal that can go before a budget decision: apply AI to this process, with this expected effect, in this order. What is explicitly out of scope is just as clear: building the AI system or PoC itself, negotiating vendor contracts, large-scale user research, and ongoing operational support are not included. The diagnosis produces the decision-making material; building the system is a separate, later phase.
The five-step process
- Step 1. Process interviews — two 90-minute interviews with management and frontline staff to understand workflows, time-consuming steps, and pain points. The client is asked to make available someone who can explain the target operations and to share existing documentation such as manuals and forms.
- Step 2. Breaking operations into process steps — interview content is decomposed to the level of individual steps, such as "drafting a quotation" rather than "the sales department," fine enough to judge AI applicability.
- Step 3. Identifying candidate areas — each step is scored against five axes (business impact, technical feasibility, data readiness, risk, and operational fit) and narrowed to 3–5 candidate areas rather than declaring that AI can do everything.
- Step 4. ROI estimation — for each candidate area, potential time and cost savings and revenue contribution are estimated as a hypothesis, based on stated assumptions such as current workload, usage rate, accuracy, human review time, and implementation or running costs, shown as conservative, standard, and upside scenarios rather than one single number.
- Step 5. Roadmap and decision material — candidate areas are prioritized into a 3–6 month implementation roadmap, together with vendor-selection reference material if the work is to be outsourced. This is the end of the diagnosis's scope.
Prerequisites for the 10-business-day timeline
- The department and scope of operations to be diagnosed have already been decided.
- A manager who can explain the operations, and frontline staff, are available to take part.
- Manuals, forms, workload data, and similar materials can be shared.
- A deadline for responding to fact-checking requests can be agreed.
- A method for sharing personal or confidential information, if needed, has been decided.
If these conditions are not met, the start date or delivery date is rescheduled. The 10 business days is a standard turnaround designed around a fixed price, not a completion guarantee if these prerequisites collapse.
Cost
| Item | Detail |
|---|---|
| Price | JPY 300,000 (excluding tax, fixed) |
| Duration | 10 business days |
| Payment terms | 50% on commencement, 50% on acceptance; payment due within 30 days of invoice |
| Travel | Included for meetings within Kyoto and Osaka prefectures; billed at actual cost elsewhere |
| NDA | Can be signed before the first consultation |
| Additional costs | None within the stated scope; work outside scope is quoted in advance before starting |
| Obligations after the diagnosis | No obligation to commission further development; handover documentation is provided if another vendor is engaged |
The price and timeline are fixed because the diagnosis itself exists to produce the material for deciding a later budget and schedule; if the diagnosis's own cost and duration varied, the plan built on top of it could not be set either. A free 30-minute consultation is available beforehand for sorting out what to discuss and an initial judgment on whether AI applies at all; the paid package is for the fuller diagnosis.
The outcome: Go, conditional Go, or No-Go, and what happens next
The diagnosis does not simply conclude "adopt AI." Each candidate area is marked Go (proceed to a small PoC with defined success metrics, timeline, owner, and budget cap), Conditional Go (re-assess after data preparation, process standardization, or a security review), or No-Go (the cost-benefit or risk does not currently justify it, with non-AI alternatives suggested). Being able to issue a No-Go is what gives the diagnosis its value; an approach that marks every case a Go on the assumption that development work will follow afterward is not a neutral input to the decision. After receiving the results, there are three ways to proceed: pursue the roadmap in-house where existing tools or process changes suffice; select an external vendor, using the diagnosis's requirements and comparison criteria to evaluate multiple proposals on the same basis, which also helps keep the diagnosis and the development vendor independent of each other; or commission the diagnosing company itself to carry the work into a PoC and implementation, quoted separately. Whichever path is chosen, the ROI estimate produced during the diagnosis becomes the baseline against which post-implementation results are measured. A common reason companies later find they cannot tell whether an AI rollout worked is that no such baseline was set before implementation.