A vague brief gets a padded quote
Automate our customer operations sounds like freedom. To the team pricing the work, it means unknown systems, unknown permissions, unknown volumes and an unknown definition of finished. Those unknowns do not disappear. They become contingency in the quote.
A useful brief does not need to prescribe a model, framework or architecture. Those are implementation choices. It needs to make the business process visible enough that a studio can identify the product around the model: the inputs, decisions, actions, exceptions and people who will operate it.
The best starting point is not a feature list. It is a real piece of work described from beginning to end.
Describe what happens today
Name the event that starts the process. A message arrives, a sales record changes, a document is uploaded or a scheduled review becomes due. Then describe what a capable employee does next, including the systems they open, the information they compare and the judgment they apply.
Include examples of the input and finished output. Sanitised material is fine if the structure remains realistic. A sample email, invoice, support case or CRM record reveals more than a page of abstract requirements.
Also state why the current process is a problem. Slow is not precise enough. Is the delay blocking revenue, creating compliance risk, exhausting a specialist team or producing inconsistent decisions? The desired business change determines what is worth automating and what should remain manual.
Define the action and its authority
An assistant that drafts a response is a different system from an agent that sends it. Reading a CRM is different from editing customer records. Recommending a refund is different from issuing one. The brief must say what the automation may do on its own, what needs approval and what it must never do.
Name the person who handles an exception. Human in the loop is too vague unless the human has a role, a queue and enough context to decide. Describe what they need to see when work is handed over and how the process continues afterward.
Permissions often determine the architecture and the price. If production credentials, personal data or financial actions are involved, say so early. A studio should not discover the risk after building the happy path.
Inventory the systems and the mess
List every source and destination: CRM, inbox, document store, database, commerce platform, internal API and spreadsheet. For each one, state who owns it, whether API access exists and whether a test environment is available. Do not write integration available unless someone has confirmed the credentials and required fields.
Describe the data honestly. Clean knowledge base and folder of mixed PDFs are not the same input. Neither are standard product records and free-text notes written differently by every salesperson. If documents conflict, identify which source wins and who maintains it.
Volume and variation matter as much as integrations. Share normal traffic, peak periods, languages, markets and the common exceptions. A workflow handling predictable internal requests has a different operating surface from a customer-facing system that must remain available during a campaign.
Define a correct output, serious errors and today's baseline. Include ordinary work, awkward cases and inputs the automation should refuse.
Success can combine quality, time, cost and business outcome. The important part is that the measures describe the real workflow rather than generic model performance. A fluent answer is not successful if an operator must rebuild it before use.
Include who will review the initial results and who owns the system after launch. Ongoing evaluation, incident response and source maintenance are operating work, not launch polish.
Write the brief this week
Document the trigger, current steps, sample inputs, required output, allowed actions, approval points, connected systems, data condition, exceptions, expected volume and owner. Mark facts that are confirmed and assumptions that still need discovery.
Ask the studio to price discovery, implementation, external usage and ongoing operation separately. Then ask which unresolved assumption creates the largest contingency. That answer shows where a short investigation can reduce the quote.
A good brief does not remove every unknown. It makes the important unknowns visible before they are priced as worst cases.