Prepare proposals and support from existing facts
In sales, a pilot combines a brief, approved services and pricing rules into a proposal draft. In support, it combines a ticket, product documentation and previous steps into a suggested response. Both processes need visible gaps: unknown prices, delivery promises and technical causes must not be invented. A domain owner decides on sending or binding commitments.
Tie reporting and knowledge search to sources
A reporting pilot starts with the same metrics and time range as the manual report. Calculations remain reproducible, and AI explains changes only as far as sources support them. Knowledge answers identify their underlying document and version. When there is no reliable source, an unanswered question is the correct result.
Prove software maintenance through small changes
A bounded bug fix with a reproducible test is easier to assess than a complete new application without a specification. Give the pilot a defined repository state and require a record of tests and changes. Claude Code can use project knowledge and additional tools; the team decides which are permitted before starting.
Review after two working cycles
Choose an owner and document the baseline, inputs, output format, approval and maximum effort. Initially run alongside the manual process. After two complete cycles, assess stable quality, remaining rework and whether exceptions are returned understandably. Expansion follows evidence rather than enthusiasm for the demo.
Keep it verifiable
Primary sources
- Extend Claude CodeSource checked:
