How to brief a provider building your AI sales agents

Brief a provider building your AI sales agents around a defined sales task: the trigger, approved inputs, expected output, permitted actions and the person who handles exceptions. Include examples of correct and incorrect work. A useful brief describes what must happen when information is missing, not just the successful demonstration you want to see.

How do you brief a provider building your AI sales agents?

Start with the task you need completed and work through it in order. Your first brief should make these decisions explicit:

1. What starts the task?
2. Where does the required information come from?
3. What should the finished result contain?
4. Which actions can happen without a person's approval?
5. What should stop the workflow?
6. Who investigates a failure or approves a change?

Use approved examples from your own business. If your team cannot agree what a correct result looks like, resolve that before asking a provider to automate it. The guide to choosing a practical sales workshop also shows why practical seller review belongs in your evaluation, even when the provider builds the workflow.

The brief is a boundary for the work, not a wish list of everything an agent might do. Start narrow enough that sellers can inspect the result and explain why it is right.

Why a sales workflow brief matters

A follow-up draft and a CRM update create different risks. An inaccurate draft can be corrected before it reaches the buyer. An inaccurate CRM update can become shared information used in pipeline reviews before anyone notices the mistake.

Write the brief around the actual consequence of each action. Do not approve broad authority because the generated wording looks sensible. Decide separately what the agent can read, propose, write and send.

For B2B tech and SaaS teams, the source material can include account records, meeting notes and internal documents. Those sources can disagree. Your brief should identify which information takes precedence and when a seller needs to settle the difference.

Describe the current work before designing the new version

Ask the seller who does the task to walk through a recent example. Record the steps, decisions and hand-offs. Include the awkward parts: finding the correct opportunity, waiting for notes or checking whether a commitment was actually made.

A manager's summary is useful, but it is not a substitute for the person doing the work. Sellers often perform checks that never appear in the official process. If the provider cannot see those checks, the resulting workflow can remove a safeguard along with the admin.

Capture:

• What makes the task ready to start.
• Which records and documents the seller opens.
• What the seller copies, interprets or corrects.
• Who reviews the result.
• What happens when the input is incomplete.
• Where the finished work belongs.

Do not mistake a repeated workaround for a requirement. If reps copy the same note into several systems because the process is unclear, resolve the process question rather than automatically reproducing every copy.

Define the output in terms a seller can check

Give the provider an example of a correct result and explain why it is correct. A meeting brief should help the seller prepare a conversation, not merely produce a long account summary. A CRM update should place supported facts into agreed fields, not fill every empty box.

Use a small specification like this:

Workflow	Expected result	Review requirement	Stop condition
Meeting preparation	Relevant account facts, previous commitments and open questions	Seller checks sources and meeting purpose	Required source is missing or contradictory
Follow-up drafting	A draft reflecting agreed actions and the seller's voice	A person approves before sending	Notes do not establish the claimed commitment
CRM maintenance	Approved information in the correct record and fields	Review depends on the agreed field rules	Record matching is uncertain

These are starting points for scoping, not promises about any provider's standard package. Ask the provider to show how your exact output would be produced and checked.

Make the data boundaries explicit

Name the required source for each part of the output. For a follow-up, that might be the approved meeting notes plus the current offer. For CRM work, include the record identifier and the field definitions.

Avoid a request to connect everything. Access should follow the task. A seller preparing an account brief does not automatically need the workflow to edit the entire customer database.

Have your system owner confirm:

• Which accounts and records are available.
• Whether access is read-only or permits changes.
• Which information must remain outside the workflow.
• Who can approve an expanded connection.
• How access is withdrawn when the engagement ends.

Ask where information is processed and retained, and who can see it. Get answers that apply to the proposed setup. Do not treat an assurance about one product or account type as a statement about every connected system.

Separate drafting, internal updates and customer-facing actions

Write a decision for each action. A broad statement that a person stays in control is not enough if nobody knows where approval happens.

For customer-facing work, specify who sees the draft and how they approve sending. Decide what happens if that person is unavailable. The default should not quietly change from waiting for approval to sending automatically.

For internal updates, identify which fields can be changed directly and which require review. A confirmed meeting date is different from a judgement about deal quality. Treat forecast categories and commercial commitments as explicit business decisions.

Onwise's custom AI sales agents are described as drafting customer-facing work for a person to approve, while agreed internal updates can be written directly. Onwise tests agents on examples from the business before bringing them to the sales team. Confirm the action boundaries for your particular implementation rather than assuming every task uses the same rules.

Write acceptance tests that include a reason to stop

A successful example shows that a workflow can work. It does not establish what happens when the inputs are wrong. Include difficult cases in the brief before the provider builds around the tidy ones.

Useful tests include:

• Meeting notes with no agreed next step.
• Two plausible CRM records for the same contact.
• A follow-up deadline that appears in one source but not another.
• An outdated offer document beside the current version.
• A source account that is no longer accessible.
• A seller changing a record while the task is underway.

Define the expected response for each case. The workflow might stop, flag the gap or request a decision from the owner. The requirement is not that it always finishes. The requirement is that it behaves predictably within its authority.

Use these cases during acceptance, not only after launch. If a failure cannot be explained from the saved input and action history, ask what information the provider needs to make it diagnosable.

Agree ownership before the first agent goes live

Name the internal process owner and the provider's responsibilities. Keep this practical: who reviews a wrong record update, who adjusts instructions after an offer change and who decides whether the next task is ready to automate?

Ask what is included in ongoing support and what counts as a separate change. A new sales stage, a renamed CRM field or a different account structure can alter the task. The brief should make the route for those decisions clear.

Your handover should explain:

• How sellers start, review and stop the workflow.
• Where errors and exceptions are reported.
• Who has authority to change the instructions.
• Which connections and accounts the workflow uses.
• What to do if the workflow is unavailable.

Keep a manual fallback. Sellers still need to update deals and follow up with buyers if an automated step is unavailable. That fallback is part of the operating plan, not evidence that the agent has failed to justify itself.

What should a useful discovery brief contain?

Bring the current process, an approved input and an example output. Explain what takes time or causes rework. Do not invent a savings estimate to make the project appear worthwhile; ask the provider how the proposed change would be evaluated against the work your team does now.

Include the seller and the person who owns the CRM rules. Their answers often separate an implementation requirement from a training gap. If the team has not learned to review drafts, adding background automation does not solve that problem.

Onwise is a fit for B2B teams that want AI sales agents tailored to their existing process, rather than a standalone software purchase. Its published process starts with a blueprint session, builds the first agent and improves it with the team before adding the next. A tailored approach still needs your team's decisions and access approvals; it is not an excuse to skip process ownership.

FAQ

One last thing: ask what the agent will refuse to do

A clear refusal boundary is useful evidence that the brief has been understood. Ask the provider to demonstrate a task that stops because the record is uncertain or the source does not support a commitment.

If every example ends with a confident answer, you have not tested the difficult part. Bring your workflow and its exceptions to a discovery call before expanding the project.