How it works

Assess the question. Build only what is needed. Run it as a managed service.

Each stage has a clear output and a decision before the next commitment. An assessment can recommend an existing tool, BI, a managed connection, prerequisite work, or stopping.

Assess, Build, Run

Three stages. Each ends with a review before the next begins.

Production work begins only when the assessment supports it. Launch follows agreed answer, access, and operating checks.

01 Assess

question, data, options, recommendation

02 Build

definitions, access, tools, tests

03 Run

monitoring, support, change, exit

The customer approves the business purpose, users, data, provider settings, and acceptance decision at the relevant stage.

Assess

Choose the simplest suitable option before building.

The assessment starts from the business question and compares the tools and access paths already available.

Inputs

One recurring question, its owner, likely source data, the intended AI assistant, and a trusted comparison result.

Review

Business definitions, source and access options, assistant compatibility, trusted comparisons, operating ownership, and exit.

Output

A written recommendation, source and access review, evaluation plan, and scope-based fee model.

Decision

Use an existing tool, use BI, build a managed connection, fix a prerequisite, or stop.

Build responsibilities

Systems Place builds the agreed service. The customer keeps business authority.

The responsibility split is written for the actual systems, users, assistant, and hosting option.

Systems Place

Design, implementation, and answer checks

  • Document agreed business definitions and result limits
  • Implement the approved source, identity, and tool path
  • Prepare representative answer and access checks
  • Document monitoring, support, change, and exit procedures

Customer

Purpose, access, and acceptance

  • Name the business owner and approve definitions
  • Authorise users, source access, and provider settings
  • Provide trusted reports or known results
  • Review test results and make the launch decision

Acceptance before launch

Check answers, access, failures, and operating readiness.

The exact acceptance set follows the approved use case and is refined during the build.

  • Representative answers are consistent with agreed reports or known results.
  • Unauthorised users, operations, fields, and sources are rejected as designed.
  • Unavailable data and unsupported questions fail visibly.
  • Monitoring, support, incident contacts, responsibilities, and known limits are documented.

READY-01

Launch review

Answers

Reviewed against known results

Access

Approved and rejected paths tested

Operations

Monitoring and failure paths tested

Decision

Accept, revise, or stop

Acceptance applies to the agreed question, systems, users, assistant, and environment.

First step

Start with the question, the owner, the data, and a known result.

That is enough to assess the available options.