Look for repeated operational friction
Start with work that repeatedly waits for information, produces inconsistent answers, or depends on a small number of experienced people. Frequency creates learning opportunities and makes improvement visible.
The question should matter enough that a faster reliable answer changes cost, response time, risk, or client experience. Novelty by itself is not a selection criterion.
Prefer a bounded evidence set
A first workflow should rely on a small number of identifiable sources with owners who can explain their quality and access rules. Avoid a use case that requires every shared drive and every message history before it becomes useful.
The workflow also needs a clear decision owner and a next action that can be described precisely. A proposed CRM update or approval request is easier to govern than a broad instruction to manage the client relationship.
- Repeated question
- Measurable operational consequence
- Named authoritative sources
- Clear role and approval boundary
- Specific next action
- Testable edge cases
Write the failure cases before the happy path
List what should happen when evidence is missing, old, contradictory, or restricted. Define the behavior when the approver is unavailable or the target integration fails.
This turns the first implementation into an operational test rather than a presentation. A delivery partner can then scope connectors and automation against observable acceptance criteria instead of an open-ended AI ambition.