Specify the decision the assessment needs to support
An AI Opportunity Assessment is a scoped investigation for a commissioning team that needs to prioritise possible uses of AI or resolve feasibility before allocating delivery budget. It should establish which requirements are sufficiently understood to proceed, which depend on further evidence and which should be deferred. The recommendations need to account for the existing architecture and the team that will operate the result.
At MP Software, an assessment is paid work with agreed questions, boundaries and deliverables. It is separate from any subsequent development or implementation. A client with a defined requirement and completed feasibility work may be ready to commission delivery directly; an assessment is appropriate when there is a decision left to investigate, rather than a mandatory entry stage.
Agree scope, evidence and access
Define the workflows under review and the evidence the consultant will need: process documentation, representative records, current integrations and known failure cases. Agree who can authorise access, whether material needs redacting and which system owners must contribute. A review of one customer service workflow should not quietly expand into an assessment of the entire organisation.
Speak to operational staff as well as managers. Ask them to walk through a completed task, a delayed task and an exception. Review the forms, spreadsheets, inboxes and platforms involved. The discovery needs to capture the work that happens between systems, including informal checks and handoffs that are rarely written in a process document.
Map the current workflow and its baseline
Document the trigger, the information required, the main steps, decisions, owners and final output. Include where records are created or updated and what happens when something is missing. This makes it easier to distinguish a problem caused by repeated administration from one caused by unclear responsibility, poor information or an unnecessary approval.
Record a baseline using observed examples where possible. Useful measures include time per task, volume, delays, rework and the proportion of cases that need judgement. Keep the quality of the evidence alongside the numbers. Staff estimates can guide an initial review, but should not be presented as measured savings or used to promise an implementation outcome.
Compare AI, automation and existing software
Each opportunity should describe the proposed change and why the chosen approach fits. Moving a known status between systems may need a straightforward integration. Interpreting an unpredictable document or preparing a draft from several sources may justify evaluating AI. In other cases, a feature already available in the business's software could be the most practical option.
For an illustrative recruitment-office review, the shortlist might include synchronising application status through an API, extracting proposed fields from CVs for review and improving a candidate form. Those are three different kinds of work. The assessment should compare them against the same business objectives rather than relabelling all three as AI projects.
Examine feasibility before promising delivery
Information readiness
Identify the source records, document quality, ownership, access restrictions and any permission needed to use the information. Note gaps and preparation work instead of assuming the required data is ready.
System access
Check whether the existing platforms support the necessary integration, what account permissions are available and whether testing can happen safely away from live customer activity.
Failure and review
Describe the effect of a wrong answer, missing field or unavailable service. Establish which actions require human approval, what should be logged and how staff can continue manually.
Operation and adoption
Identify who will use the solution, maintain its information and review its quality. Include training, support and ongoing software or usage costs in the feasibility discussion.
Require deliverables that support commissioning
The outputs should include a workflow and system map, a ranked list of candidate changes, a record of feasibility findings and a recommended delivery sequence. For each recommendation, state the evidence, assumptions, dependencies and owner. Record rejected options and their reasons so that the same questions do not have to be reopened when the work reaches procurement or another supplier.
For work ready to proceed, include a proposed scope, integration points, data preparation, acceptance criteria and operating responsibilities. For an unresolved technical question, specify the evaluation needed and the condition for proceeding or stopping. Any estimates should state their basis and uncertainty. A roadmap that assigns every idea to a pilot without explaining what it needs to prove leaves the commissioning decision unfinished.
Review the recommendations with delivery and operational owners
Use the readout to challenge the recommendation with the people responsible for architecture, operations and budget. Confirm that the dependencies can be met and that the proposed acceptance criteria describe a result the business would adopt. Assign ownership of unanswered questions and distinguish a delivery estimate from a commitment that still depends on access or evaluation.
The resulting decision may be to configure an existing product, commission development, resolve a data dependency or stop the proposal. If an evaluation is required, define its scope and exit criteria. If the evidence is sufficient, proceed to implementation with the findings incorporated into the brief. The client should retain the assessment outputs independently of who delivers the subsequent work.
Useful resources and next steps
Discuss the requirements for your project
We can review a proposed AI use case, assess its integration requirements or take on a defined development brief.
AI consultancy and assessment