Enterprise / Evaluation planner

Know what a useful pilot must prove.

Set the baseline, test cases and acceptance criteria. Then review accepted work, human effort and full cost before choosing how to expand.

Read the evaluation guide

Switch stages without losing the notes on this page.

Your evaluation / Draft on this page

Save or reopen your evaluation

Save an editable file to continue later, or download the complete team brief. Both include your plan, candidate assumptions and baseline and pilot observations.

Files are read on this page and are not sent to Forward. Keep the downloaded file to retain your work.

Save a file before leaving or refreshing to keep your work. A request is sent only after you review and send the contact form.

Prepare the acceptance plan.

Describe the process and what the test must prove. Fill what you know; unanswered items remain “To confirm” in the plan.

Workflow context

A scoping example. Changing context keeps your written notes.

Industry context

Choose the setting for discovery, or keep it general.

01Define the work

One task, one unit of work and a clear processing boundary.

Production task and unit of work (optional)

What should people complete? Name one unit, such as a reviewed record, accepted answer or approved change.

Workload volume (optional)

Units per period, users and peaks. An estimate or an explicit unknown is enough.

Integrations and data requirements (optional)

Systems, tools, data categories and access or processing constraints. Describe the boundary; do not paste records or credentials.

02Design the test

Compare the baseline and candidates on the same cases. Count rejected outputs, retries and human effort.

Current process and baseline (optional)

How is the work done today? Record quality, time, review effort and cost, or describe how you will establish them.

Evaluation sample and rules (optional)

Representative cases, sample size, expected results and reviewers. Include exceptions and a held-out set when training a model.

Acceptance criteria (optional)

What result is good enough? State thresholds for quality, time, review effort and total cost per accepted result, including what counts toward that cost.

03Agree the decision

Name the person who accepts the result and the evidence they need.

Decision owner and timing (optional)

Who accepts the result, by when, and what evidence would justify rollout, another test or stopping?

Review your contact details and requirements before sending. The proposal confirms delivery, access, price and acceptance.

Your team’s decision

A result you can accept.

0 of 7 planning items drafted. Each item records your requirements; it does not certify readiness.

Production task and unit of workTo confirm
Workload volumeTo confirm
Integrations and data requirementsTo confirm
Current process and baselineTo confirm
Evaluation sample and rulesTo confirm
Acceptance criteriaTo confirm
Decision owner and timingTo confirm

Review full plan

Your evaluation plan

# Enterprise evaluation plan

Planning draft · define the test before running it.

Planner: https://www.forwardintelligence.ai/evaluation

## Production task and unit of work

To confirm

## Workload volume

To confirm

## Integrations and data requirements

To confirm

## Current process and baseline

To confirm

## Evaluation sample and rules

To confirm

## Acceptance criteria

To confirm

## Decision owner and timing

To confirm

## Scope to confirm

Agree the evaluation environment, data access, deliverables, deployment, support and commercial terms in writing. Candidate selection does not activate access or book capacity. This plan records requirements; it does not report an evaluation result.

The copied plan includes all seven items. Unanswered items remain “To confirm.”

What counts as a useful result?

Define an accepted unit, measure failures and human review, then compare quality, time and total cost with today’s process. State the sample and cost boundary beside the result.

Prepare the deployment review Download a blank template

After the test / Your measurements

Compare the work people accept.

Review quality and the full cost of the same task. Include rejected work, retries and human effort in the cost boundary. These calculations use your entries.

Switching stages keeps your notes and measurements. Open “Save or reopen your evaluation” to keep them for another visit. Model pricing assumptions do not fill observations.

Task and unit of work

Name the task and one distinct unit. Your written task carries over from the plan.

Sample and test period

Name the evaluation set and dates. Counts alone do not establish representative coverage.

Cost boundary and exclusions

State which calls, tools, people and services are counted, how setup is allocated, and what is excluded. Use the same boundary and currency.

Acceptance rule and target

What counts as an accepted result, and what threshold justifies the next step? Your written criterion carries over from the plan.

Baseline

The current way of completing the work.

Units evaluated

Distinct cases in this sample. Retry costs belong in the cost boundary.

Accepted results

Units that meet your acceptance rule. Count each accepted unit once.

Usage and operating cost (USD)

Model calls, tools, retries and recurring services allocated to this sample. Exclude the human effort and one-time costs entered below.

Human effort (hours)

Manual work, review and rework inside the agreed boundary.

Cost per human hour (USD)

Use the same basis for both runs, including relevant overhead.

One-time cost (USD)

Delivery or setup cost allocated to this comparison. State exclusions in the boundary.

Acceptance rate: To confirm
Recurring cost, including human effort: To confirm
Total, including one-time cost: To confirm
Recurring cost per accepted result: To confirm
Total cost per accepted result: To confirm

Pilot

The candidate process on the same work.

Units evaluated

Distinct cases in this sample. Retry costs belong in the cost boundary.

Accepted results

Units that meet your acceptance rule. Count each accepted unit once.

Usage and operating cost (USD)

Model calls, tools, retries and recurring services allocated to this sample. Exclude the human effort and one-time costs entered below.

Human effort (hours)

Manual work, review and rework inside the agreed boundary.

Cost per human hour (USD)

Use the same basis for both runs, including relevant overhead.

One-time cost (USD)

Delivery or setup cost allocated to this comparison. State exclusions in the boundary.

Acceptance rate: To confirm
Recurring cost, including human effort: To confirm
Total, including one-time cost: To confirm
Recurring cost per accepted result: To confirm
Total cost per accepted result: To confirm

I used the same cases and acceptance rule for both runs.

Your comparison

Complete both sets of observations. Enter 0 explicitly where a cost or effort is absent.

Decision owner and timing: Confirm the owner and timing in the plan before the adoption decision.

Review full results

Your evaluation results

# Enterprise evaluation results

Task and unit of work: To confirm

Acceptance rule and target: To confirm

Decision owner and timing: To confirm

Sample and test period: To confirm

Cost boundary and exclusions: To confirm

Same cases and acceptance rule confirmed by the author: To confirm

## Baseline

Units evaluated: To confirm
Accepted results: To confirm
Usage and operating cost (USD): To confirm
Human effort (hours): To confirm
Cost per human hour (USD): To confirm
One-time cost (USD): To confirm

Complete valid observations before calculating results.

## Pilot

Units evaluated: To confirm
Accepted results: To confirm
Usage and operating cost (USD): To confirm
Human effort (hours): To confirm
Cost per human hour (USD): To confirm
One-time cost (USD): To confirm

Complete valid observations before calculating results.

## Comparison

Not ready: incomplete. Complete valid observations, name the boundary and compare the same evaluated cases and acceptance rule. A run with no accepted results has no cost per accepted result.

Calculated from the author's entries. Check the sample, exclusions and written acceptance target before deciding the next step. These entries are not independently verified performance results.

Review the actual task, production volume, integrations and success criterion before sending. A calculation does not make the rollout decision; delivery and commercial terms are confirmed in the proposal.

Know what a useful pilot must prove.

Prepare the acceptance plan.

Compare the work people accept.

Your comparison

Request access

Talk to us