Evaluation guide

Prove one valuable customer outcome against the current product

Start with one outcome worth proving

A Dubot evaluation should produce operational evidence, not only a polished demo. Choose one recurring request whose current answer still leaves meaningful work for the customer.

A good first journey

Choose a request that is:

• common enough to matter;
• completed through a product path the team understands;
• bounded enough to test safely;
• measurable through a visible product state or action result;
• feasible with current-build capabilities or an explicitly agreed controlled rollout.

Avoid a first journey dominated by destructive changes, unclear ownership, many exceptional states, or a connector that does not yet exist.

Evaluation sequence

1. Confirm feasibility

   Map each required behavior to a current product feature, controlled-rollout dependency, or customer-owned integration. Do not use a prototype as the availability decision.

2. Define the boundary

   Agree identity, origin, data, knowledge, action, confirmation, and stop conditions.

3. Build in Test

   Configure the narrow wizard, guide, Resource Center entry, and actions needed for the outcome.

4. Exercise failures

   Test invalid identity, missing callback, unpublished dependency, rejected confirmation, customer API error, unavailable UI target, navigation, and user stop.

5. Publish deliberately

   Publish only the reviewed entities and verify the Production experience on the target origin.

6. Measure and decide

   Review completion, safe stops, errors, customer effort, maintenance cost, and operational ownership before expanding scope.

Evidence to collect

Evidence	Why it matters
Baseline volume and effort	Establishes whether the outcome is worth improving
Successful completions	Shows the intended customer result occurred
Safe stops and declines	Shows controls work without forcing completion
Failure categories	Identifies product, integration, content, or model gaps
Maintenance work	Tests whether the experience stays economical as the product changes
Customer or agent feedback	Captures effort and trust not visible in technical logs

People to include

Role	Smallest useful contribution
CX	Recurring request, examples, current resolution path, desired outcome
Product	Expected product states, edge cases, and ownership
Engineering	Identity, origin, customer-owned execution, and test environment
Security	Data, action, authorization, retention, and review boundary
Dubot	Configuration, integration guidance, test plan, and evidence review

Confirm the status shown on each relevant product page. Keep current-build, controlled-rollout, planned, and design-only dependencies visible throughout the evaluation.