A clear brief. A better beginning.

Explain the task people need to complete and what makes it difficult today. Include who is affected, how often the problem occurs and what a successful change would look like. A measurable outcome can be as simple as reducing duplicate entry or making the status of a request visible to the right people.

Then list the capabilities you believe are needed. Keep essential requirements separate from ideas that could be explored later. If you are uncertain about the solution, say so. A brief is useful when it makes the business problem and constraints clear, even if the technical approach still needs discovery.

Name the systems the project needs to connect to and the people who control access to them. Note any provider limits, procurement requirements or dates that cannot move. Identify the records involved and any restrictions on where they can be stored or processed.

For AI work, describe the source material, the intended users and the consequence of an incorrect answer. Explain which decisions must remain with a person. This information helps distinguish a useful pilot from a demonstration that cannot safely become part of the real workflow. Avoid attaching raw customer records when a redacted example will explain the requirement.

Ask a business owner and someone responsible for the existing systems to review the draft. Look for conflicting assumptions about scope, timing and ongoing support. Mark unknowns explicitly and identify who can answer them. An honest gap is easier to resolve than an estimate based on an unstated assumption.

Review the brief and choose Send to email Cobnex. You can also download a PDF copy for your records. Keep a dated copy when the scope changes so later discussions use the same version. Commercial terms, acceptance and delivery commitments still need to be agreed separately for an actual engagement.