Home›AI Agency Academy›Lesson 07
Module 02 · Lesson 07

Turn a use case into an offer

Package a believable before-and-after workflow with scope, responsibilities, and proof.

Last updated August 5, 2026•15–25 minutes•Free AI agent course
What you will learn

Make a clear, safer operating decision.

You will be able to describe an agent implementation as a clear operational change instead of a bundle of models, prompts, and vague automation.

Why this matters

Good agent work is useful before it is impressive.

Buyers do not purchase a prompt library. They purchase a better way of handling work. An honest offer names the current state, the bounded first release, the responsibilities on both sides, and how usefulness will be assessed.

Field note 07

Make the relationship visible.

AI AGENTS · FIELD NOTE 07Before → bounded build → measured afterTHE OFFER01Current friction02First release03Shared duties04Proof pointOriginal visual framework for Turn a use case into an offer.AI AGENTS · FIELD NOTE 07Before → bounded build → measured after01Current friction02First release03Shared duties04Proof point
Use this framework to make turn a use case into an offer visible before you build.
Core concepts

The language that keeps the work clear.

Before stateThe specific current workflow and constraint the buyer recognizes.
DeliverableThe tangible build: approved workflow, connected source of truth, test cases, launch plan, and review.
BoundaryWhat the first release does not do, including prohibited actions and systems outside scope.
Proof pointThe metric or observation used to decide whether the implementation is helping.
The practical method

Work through the decision in order.

Describe the current state

Use one grounded sentence about the delay, loss, rework, or inconsistent decision.

Specify the first release

Name the trigger, allowed context, chosen action, handoff, and result—not every future possibility.

Make duties reciprocal

List what you configure and what the client must supply or approve: policies, data access, owner, and review.

State the proof plan

Choose baseline, metric, quality guardrail, pilot period, and decision point.

Worked example

A realistic, bounded implementation.

A legal-services firm wants fewer missed consultation opportunities. A poor offer says ‘we install an AI receptionist.’

A useful offer says: ‘We design and launch an after-hours intake workflow that captures approved consultation details, categorizes the enquiry, writes a concise summary into the CRM, and alerts the assigned team. The firm approves questions, escalation rules, and all representations of legal advice.’

The proof plan measures completed intakes, response time, correction rate, and escalated cases during a pilot. The service has a clear finish line and boundary.

Build it in practice

Use this copyable working template.

Adapt it to the client’s evidence, policy, people, and tools. Do not treat placeholders as approved instructions.

For [buyer], when [trigger] happens, we will [bounded workflow] so [outcome]. Includes: [deliverables]. Client provides: [inputs and approvals]. Does not include: [boundaries]. Proof: [metric + review date].
Spacebrain implementation

Put the operating system around the agent.

Frame the implementation around real Spacebrain capabilities—capture, contact context, routing, tasks, messages, calls, automations, and reporting—only where the product supports the promised workflow.

Practice

Before you move on

  • Rewrite one vague service as a before-and-after workflow.
  • Add three exclusions that protect the client and delivery team.
  • Ask an operator whether the promised result matches their daily work.
  • The offer names an operational change, not a technology list.
  • Client responsibilities are visible.
  • Exclusions and escalation are stated.
  • A realistic measurement plan is included.

Build the operating layer around your agent.

Use the free Spacebrain workspace to keep contact context, handoffs, tasks, automation, and reporting together.

Start for free →