How to write a useful AI and automation consultancy brief

A useful AI and automation consultancy brief explains the work you want to improve, the evidence available and the decision you need help making. It does not require a technical solution or a preferred model. A clear brief gives a consultant enough context to propose an appropriate scope and gives you a basis for comparing the response.

Established businesses often approach a consultancy with a mixture of symptoms: too much retyping, slow reporting, staff shortages or systems that do not talk to each other. Those are legitimate starting points. The brief turns them into a manageable investigation without pretending the cause has already been proved.

This guide provides a reusable structure and practical commissioning questions. The examples are hypothetical. It distinguishes an initial assessment from implementation so you can understand what a quoted engagement will actually deliver.

Describe one operating problem clearly

Begin with a task and the people affected. “We want to use AI” does not identify a business outcome. “Our operations team re-enters emailed orders into two systems and resolves product-code questions manually” describes work that can be observed and assessed.

Explain what makes the problem important now. Growth, changing customer expectations or a new reporting obligation may affect priority. Keep the explanation factual. You do not need to claim the process is disastrous to justify examining whether it could work better.

State the boundary of the initial question. A company-wide transformation may be a later ambition, while the first engagement examines one order route or reporting pack. A bounded brief is easier to price and evaluate than a request to optimise every process at once.

Include the outcome you want to support, such as fewer avoidable transfers, more dependable records or a report available at an agreed time. Avoid promising a saving before the baseline is known. The consultant can help establish whether the desired outcome is feasible and how it should be measured.

Describe the organisation without oversharing

Give enough context to understand size, operating locations, customer types and the teams involved. An established distributor with several branches differs from a charity coordinating services and fundraising. Those differences affect observation, information access and implementation effort.

Explain the relevant systems and their roles, not every technical detail. A short list saying which tool holds orders, invoices and customer contacts is more useful initially than a large infrastructure diagram with no connection to the task. Identify any known contract or access limitations.

Keep passwords, keys, full customer exports and sensitive staff records out of the initial enquiry. A consultant can scope a discussion from a process description and appropriately minimised examples. If detailed access becomes necessary, agree the controlled route, permissions and purpose later.

State any constraints the consultant must respect: approved suppliers, data arrangements, accessibility needs, operating hours or a change freeze. Distinguish firm requirements from preferences. This prevents a proposal from assuming options the organisation cannot actually use.

Prepare a small evidence pack

Gather a process outline, representative volumes and examples of ordinary and difficult cases. Label estimates as estimates and record the period they cover. A rough but honest baseline is more useful than a precise number assembled without a consistent definition.

Separate processing time from waiting time. A report may take an hour to prepare and three days to obtain approvals. These are different constraints. The consultant needs to understand where the work waits before recommending faster drafting, another integration or a revised decision route.

Include known exceptions. Missing references, duplicate records and unclear ownership often determine whether a proposed automation is viable. Do not remove awkward cases to make the process look tidy; the assessment should reveal how the real operation works.

The workflow mapping guide can help organise this material. You do not need a polished diagram before asking for help. A simple sequence with roles, systems and unresolved questions gives a useful starting point for discussion.

Use a reusable brief structure

The following headings can form a first draft. Adapt them to your organisation and keep the initial version concise enough for the relevant managers to review. The brief should support a conversation, not become a large document that delays understanding the problem.

• Context: what the organisation does and which operation is in scope.
• Problem: the task, current friction and consequences for staff or customers.
• Evidence: volumes, timing, sample cases and known limitations.
• Desired outcome: what would be observably better and who benefits.
• Constraints: systems, information rules, timing, access and budget boundaries.
• Decision needed: assessment, options comparison, pilot design or implementation proposal.
• Acceptance: the deliverables and evidence needed to consider the engagement complete.

Add named roles for the sponsor, operational owner and relevant technical or finance contacts. The consultant should know who can clarify facts and who can make decisions. Avoid relying on one enthusiastic employee to speak for every department affected by the work.

Record open questions separately from confirmed requirements. If the organisation has not decided whether a process should change, say so. The consultant can then propose an assessment rather than price an implementation against an assumption that may later be rejected.

Distinguish discovery from implementation

A discovery or diagnostic engagement examines the process, evidence and options. Its deliverables may include findings, a prioritised roadmap, a business-case method and a recommended pilot. It should not be described as delivering a complete production system unless that work is actually included.

Implementation adds design, development or configuration, testing, deployment and handover. Its scope depends on what the assessment establishes. A fixed implementation price offered before important dependencies are known may contain assumptions or exclusions that deserve close attention.

Agree how the first phase leads to a later decision. You should be able to stop after an assessment and retain useful findings. Ask whether the recommendation can be used with another supplier and whether any commercial relationship influences the proposed technology.

Our business process audit service provides a route for a scoped initial review. A starting fee relates to the defined engagement, not a promise to assess every department or implement a whole business system within one day.

Set realistic access and observation expectations

Some problems can be explored remotely through interviews and controlled screen sharing. Others need on-site observation across shifts, roles or locations. Understanding how staff handle exceptions may require more than one working day, particularly where the relevant activity happens infrequently.

Describe the operating cycle and available participants. If a monthly close or delivery peak is central to the problem, the consultant needs to plan around it. A convenient meeting date may not provide evidence of the work you actually want investigated.

Explain how staff will be involved. They should understand the purpose of observation and the information being collected. A process review should not become undisclosed staff surveillance or a judgement about individual performance based on a brief visit.

The on-site discovery guide sets out a practical preparation and observation plan. Use it to discuss coverage and limits so a proposed day rate is connected to realistic work rather than an assumption that one visit reveals the whole organisation.

Ask for measurable deliverables

Describe what you need to receive and how you will judge it. A workflow map should identify roles, systems, decisions and exceptions. An options assessment should explain evidence, assumptions and trade-offs. A pilot plan should state scope, test cases, ownership and stopping conditions.

Avoid accepting vague deliverables such as “strategic insights” without an explanation of their practical use. Ask what decision the document will support and who should be able to use it after the engagement. The output should help the organisation act, not merely restate the original problem in technical language.

Where a business case is included, require a distinction between released capacity, cash savings and uncertain future benefits. Include operating, review and maintenance costs. The automation ROI guide provides a method for examining those assumptions.

Set a review meeting and a route for factual corrections. Staff should be able to point out where the findings misunderstand the process before recommendations are finalised. Agreeing an acceptance process makes the engagement easier to complete fairly for both the organisation and the consultant.

Compare proposals against the same questions

Give shortlisted consultants the same core brief and record clarifications that change the scope. Otherwise one proposal may include several site visits while another assumes a single remote workshop. A lower total may reflect less work rather than better value.

Compare the approach to evidence, staff involvement, information handling and handover. Ask who performs the work and what relevant capability they bring. A premium presentation is useful only if the proposed method can address the task and the people named can deliver it.

Separate confirmed price, assumptions and optional work. Identify travel, additional days, third-party fees and ongoing support where relevant. For international visits, discuss the actual itinerary and written expense policy rather than relying on a generic claim that overseas costs are included.

Ask what happens if the assessment recommends no major build. A vendor-neutral engagement should be able to conclude that an existing feature, a simpler rule or a process change is sufficient. That possibility helps keep the recommendation connected to the organisation's needs.

Define information handling and ownership

Agree what data the consultant can access, why it is needed and how long it will be retained. Use the minimum practical access and remove it when the work ends. Credentials should be shared through an approved secure route, not pasted into an enquiry form or meeting notes.

Clarify ownership and use of deliverables, configurations and source files. The organisation should know what it can maintain or transfer to another supplier. Identify any licensed components or proprietary dependencies that affect future operation before committing to implementation.

Review the proposed AI use within the engagement. If a consultant intends to process your documents through an external model, that should fit the agreed information arrangements. A general confidentiality statement does not answer which services receive the material or under what configuration.

The NIST generative AI profile offers a voluntary reference for considering AI-system risks. Your brief can keep this practical by asking for documented use, representative evaluation and clear human responsibility for material decisions.

Work through a hypothetical commissioning decision

Imagine an established service company struggling to prepare project reports. The initial request asks for an AI reporting system. A short evidence pack reveals that source updates arrive late and managers use inconsistent project definitions. These are fictional details used to illustrate how a brief can improve the decision.

The company commissions a bounded assessment of the reporting handoff and definitions. The deliverables include a current-state map, a reconciled sample report and options for reducing repeated preparation. A production build remains a later decision, with its own scope and acceptance criteria.

During the review, an existing system feature appears capable of handling part of the problem. The consultant tests that option against the actual task rather than assuming a custom build is necessary. The recommendation distinguishes the confirmed improvement from features that still need evaluation.

The company can then choose a pilot with better information about effort and risk. The first engagement has value because it supports a decision, whether or not a larger project follows. That is a useful standard to apply when reviewing any proposed consultancy package.

Keep a decision log during commissioning

Record material clarifications alongside the brief. If the scope changes from one location to several, note the reason, who agreed it and the effect on evidence and duration. This prevents different people comparing proposals against different versions of the requirement.

Keep unresolved assumptions visible until they are answered. A consultant may assume access to a system export that the organisation cannot provide. Another may depend on staff being available during a peak period. Those dependencies affect feasibility and should be reviewed before a commitment is made.

Use the log to distinguish an accepted requirement from an option discussed during a call. An interesting future integration should not become part of the expected deliverable merely because it appeared in meeting notes. Confirm the agreed scope in the final written proposal and retain the decision record for later review.

Add the current brief version to the proposal review sheet. Check that each supplier has acknowledged the material clarifications before comparing scope or price. A short written confirmation can prevent a later disagreement about which assumptions were included.

Prepare for a productive first conversation

Bring the short brief, one ordinary example and one difficult example, with sensitive details appropriately controlled. Include someone who performs the task and someone who can authorise the next step. A conversation based only on senior assumptions may miss the actual operational constraint.

Ask the consultant to reflect back the problem and identify missing information. Their questions can reveal whether they understand the business outcome or are moving immediately to a preferred technology. Keep a record of assumptions that affect duration, price or the proposed deliverables.

Use the conversation to agree a concrete next step: a scoped diagnostic, further evidence gathering or a decision that the current proposal is unsuitable. You do not need to commit to a full transformation programme simply to explore a specific problem.

A well-prepared brief makes consultancy easier to buy and easier to judge. It gives both parties a shared task, an evidence boundary and a clear definition of useful work. That foundation improves the chance that any later AI or automation investment addresses the process the organisation actually needs to improve.

Checked sources

• NIST: generative AI risk-management profile