Assessment

What the Assessment is

This is not a generic AI strategy deck or a discovery call. It is a fixed-scope paid decision product designed to identify the smallest credible path to a useful result—including when the right answer is cleanup, redesign, a focused review, pause or no build yet.

The review starts with the business problem, not a tool list. It looks at what the organisation needs to see, report, connect, automate or improve; where the relevant information lives; what can be trusted; what requires human review; and who will own the result.

When should a business start with an Assessment?

Start with an Assessment when several systems are involved, readiness is unclear, reporting is manual or disputed, several routes look possible, or the workflow and owner are not yet resolved. A narrow, credible requirement may go directly to focused work. The evidence can recommend a build, redesign, pause, no build or another approved route.

Typical assessment scope

Assessment is a single product. It typically covers the relevant business area or areas, the systems and uncertainty affecting the decision, stakeholder input, source mapping, a clear roadmap and architecture sketch where useful, and an implementation-ready or SOW-ready recommendation when the evidence supports one.

Final inclusions follow the written scope and the current Pricing Model.

When it fits — and when it does not

What the Assessment reviews

Process

1. Scope the decision — define the business area, intended use, people, systems and decision the fixed 1–2 week review must support.
2. Diagnose the current state — map the workflow, material exceptions, handoffs, baseline, evidence limits and the minimum conditions required before a build.
3. Review systems, data and readiness — examine the relevant sources, access, ownership, definitions and proposed capabilities at the depth needed for the decision.
4. Compare the opportunities — show which use cases are worth prioritising, which limiting dimensions remain and which recommended AI-enabled solutions pass or fail the required production gate.
5. Agree success measures and sequence — define client-specific output, operating, guardrail, adoption and value measures, then separate required-now work from later improvements.
6. Issue the decision package — present the evidence, blockers, recommendation, route, next owner and action.

What does an Assessment deliver?

The deliverable is a decision package: evidence confidence, the current workflow and baseline, relevant system and data inventories, readiness and production-gate results where applicable, risks, engagement-specific measures and a phased recommendation. It is not a live sample or a promise that implementation should proceed.

1. Scope and evidence-confidence summary — what was reviewed, what is supported and where evidence or stakeholder agreement is limited.
2. Current-state workflow and target-state view — the normal path, important exceptions, handoffs, fallback and the minimum state required to start.
3. Baseline and value range — current measures, assumptions and a decision range tied to the actual workflow rather than a universal automation percentage.
4. System, data and relevant AI inventory summary — the sources, access, ownership, definitions and proposed or existing AI-enabled items that affect the decision.
5. AI-readiness view where relevant — dimension-level capability scores with limiting dimensions kept visible; no overall average that can conceal a blocker.
6. Prioritised use-case map — opportunities compared by value, evidence, feasibility, boundedness, risk and owner readiness.
7. Production Readiness Gate result — a clear result for each specifically recommended AI-enabled solution, including failed gates or named conditions.
8. Risk and blocker list — the conditions that must be fixed, evidenced or owned before implementation.
9. Engagement-specific success measures — the output, operating, guardrail, adoption and value measures to carry into the written scope or SOW.
10. Phased roadmap and leadership decision brief — required-now work, later improvements, explicit route, next owner and action.

The exact depth depends on the agreed Assessment scope. Detailed technical design for a larger build is separately scoped.

What we need from the client

• A clear business problem or set of questions to investigate.
• The people who understand the workflow and can explain recent real examples.
• A list of relevant systems, reports, files and existing automations.
• The current technical state: warehouse or database, cloud environment, SaaS stack, dashboards, exports, integrations and access methods such as APIs, webhooks or files.
• Access to representative information where agreed and appropriate.
• A named decision owner and the likely owner after any future build.
• Known security, privacy, procurement, timing or regulatory constraints.

Can Memory(One) work with systems a business already uses?

Yes, where the selected systems expose a workable approved access path such as an API, database connection, webhook, file transfer or export. Memory(One) can assess or build a custom connection when standard options are insufficient, but access, feasibility, source limitations, controls and the written scope determine what can actually be connected.

Illustrative example

A team prepares a weekly performance report by exporting information from three systems, reconciling definitions and asking several people to explain mismatches. Assessment could map the sources and owners, identify why the numbers disagree, score the reporting and automation options, and recommend a sequence: agree definitions first, connect selected sources next and defer automated actions until the review path is clear.