Start with the job to be done
Specify the users, the task, and the output they should receive. An illustrative requirement is an operations team needing a weekly report draft from approved spreadsheets. Distinguish this from a system that reads several applications and automatically distributes reports. These require different designs, permissions, and tests. Record what is deliberately outside the first phase so that competing estimates describe the same work.
Separate delivery from operating costs
Request a breakdown for discovery, data preparation, development, integration, testing, documentation, and training. Separate recurring model usage, hosting, storage, monitoring, and support. Establish who owns each account and who pays for each component. Ask whether third-party charges are included in the proposal and how later changes to those charges are handled. This makes the ongoing commitment easier to understand.
Check data readiness and system access
Scattered files, inconsistent spreadsheet columns, or procedures without version information can add preparation work. Integration also depends on available APIs, permissions, and a test environment. Before requesting an estimate, prepare a source inventory and sanitized examples. Do not send passwords or confidential documents in an introductory conversation. Ask the proposal to identify unresolved assumptions and explain what happens if those assumptions change.
Compare pilot and production requirements
A pilot tests whether an approach is useful within a limited scope. Production adds decisions about users, access, recovery, monitoring, and support. Request acceptance criteria and a named approver for each phase. Google’s introduction to production ML systems explains that a model is part of a wider system. This supports budgeting for the surrounding work rather than treating a working demonstration as the whole delivery.
Use usage scenarios instead of one fixed prediction
Estimate active users, task frequency, document size, and response requirements. Request low, expected, and high usage scenarios with explicit assumptions. Agree suitable budget alerts and usage boundaries. For the business case, measure the existing work and the time required to review AI outputs. Faster drafting does not automatically translate into a matching reduction in company expenditure, especially if review and exception handling remain substantial.
Prepare a brief that supports a useful estimate
Bring a workflow summary, example output, system list, expected user count, timing constraint, and decision owner. Ask about code ownership, data export, scope changes, and which support ends at handover. KODE can discuss whether assessment, a pilot, or integration is the appropriate first step. The aim is a reviewable scope with clear assumptions before a budget is agreed.