Define a first release your team can put to work.

“Improve outbound” leaves the builder and buyer with different pictures. “Give the sales owner every relevant campaign reply with the account history, original message and next question” names work a person can inspect. The owner still assesses the need and decides what follows.

Describe today’s task before proposing the replacement. Where does a reply arrive? Who reads it? How do they find the account, and what happens when they are absent? A first release should resolve an identified problem, such as replies waiting in a shared inbox or technical questions reaching someone without the product context.

Choose a boundary that contains the whole handover. A list needs a recipient who can use its account evidence; a notification needs a way to record the response. The seven-part system helps identify the relevant connections without making every part compulsory. Agree the focused research, campaign or workflow assignment the situation calls for.

Name what remains outside this release. For the reply example, that might include changing the campaign proposition, replacing the CRM and sending customer replies automatically. The first release can be useful while those decisions stay with the existing team.

Decision: what should someone be able to decide or do? Name the recipient and the question the result must help answer. “Sales can assess the request and choose a next step” is more useful than “increase CRM adoption”.

Scope: which campaign, account group, region or handover belongs in the release? Keep exclusions beside inclusions. State whether existing customers and open opportunities need different treatment and who approves any expansion of the boundary.

Sources: where will each fact come from, who can authorise access and how current must it be? Show a real permitted sample where possible. Mark missing access as a dependency; do not describe a proposed integration as if it has already been tested.

Rules: how are records matched, owners selected and uncertain cases handled? Distinguish fit, routing and qualification. An ideal customer profile can supply fit rules, while the routing guide covers assignment and exceptions.

Output: specify the task, record or draft, its destination and the original context it carries. List the fields the release may change and those it must leave alone. Include how the operator sees a failure or an outcome whose receipt cannot yet be confirmed.

Acceptance: write ordinary, awkward and failure cases with expected results before the demonstration. Name who reviews them and what evidence they retain. The workflow-testing checklist develops the test record, including uncertainty and repeated actions.

Operation: identify the rule owner, recipient, technical operator, continuing costs and review date. Add a safe pause or rollback procedure: what stops, where new work waits and how completed actions are reconciled. The operating record belongs with the configuration and handover instructions.

A distributor runs a campaign exploring the need for a second supplier for a supported component range. Replies reach a shared inbox, and account owners reconstruct the context from separate records. The first release prepares a review task for each reply. The recipient assesses the buyer’s need and decides how to respond.

The task contains the original reply, campaign reference, checked company or site, known relationship, proposed owner and unresolved question. Current customers keep their relationship owner. Technical questions include the relevant product range. Unknown matches enter a named review queue rather than a guessed opportunity.

The campaign owner confirms the reply states and exclusions. Sales confirms ownership and cover. The CRM owner approves the append/update boundary and supplies permitted sample records. The builder demonstrates the handover with those people before enabling it for campaign traffic. Their access and review time are delivery dependencies.

Write six expected cases: a relevant request reaches its owner; a current customer reaches its existing contact; an unclear company match remains unresolved; an absent owner triggers cover; the same reply delivered twice creates one work item; and an uncertain CRM response remains visible for reconciliation. Add a stop-contact response if the release also controls an active sequence. Its stop must be confirmed independently of whether a sales task was created.

The release may use existing inbox and CRM capabilities. HubSpot’s record-matching guidance shows why matching identifiers need their own design decision. A copied email address, company domain and branch identifier do not necessarily describe the same buying unit.

For rollback, stop new automated writes while preserving incoming replies in the agreed holding queue. Keep confirmed destination references. Reconcile unresolved writes before replaying them, then let the owner release the held work. “Turn it off” is incomplete if nobody can find the replies that arrived during the pause.

Walk the brief from the original source to the person using the result. Ask who approves the interpretation, who receives the task, who notices missing work and who can stop the process. A shared inbox can be a destination; “someone in sales” is not an ownership rule.

Agree what acceptance requires from the client. A product specialist may need to check technical categories. The account owner may need to review disputed company matches. An administrator may need to approve access. Put those inputs and the consequences of a delay in the written scope.

The recipient should try a sample output using their ordinary tools. Can they find the original message, correct a match and choose an action without asking the builder to explain the screen? The commercial workflow specification helps describe the record passed between teams.

If an AI step interprets a reply, test that interpretation separately from routing and writing. NIST’s AI Risk Management Framework is voluntary guidance for considering risks through AI design, use and evaluation. It does not replace the acceptance cases for this release or certify the outcome.

Record how the same task works today over a defined period: replies received, messages checked, time spent finding context, wrong assignments and unresolved requests. Define what counts as a reply and a work item so a long email thread does not become several supposedly independent opportunities.

Keep gaps visible. If staff only record difficult enquiries, their history cannot establish an average for every request. If one week’s volume is unusually high, record that context. Record those limits alongside the baseline rather than combining incompatible records into an apparently precise average.

After release, compare the same task and definitions. A shorter preparation time may be useful even while commercial outcomes remain open. More tasks can reflect better coverage rather than increased demand. The measurement guide explains why operational change and additional revenue need different evidence.

Choose the date and person for the first review. Keep, repair, extend and stop are all possible decisions. Write the reason beside the evidence, including unresolved issues; do not treat a completed technical connection as automatic approval for a wider campaign.

Fill in the seven headings for one live task, using permitted examples. Begin with the recipient and desired decision. Add the current source and sample output, then the exclusions and failure cases. Mark every assumption the future owner needs to confirm.

Ask the recipient to use the sample and the operator to explain how to pause and recover the workflow. If either gets stuck, identify the missing decision or instruction. Keep the brief concise, adding record and permission maps where the handover needs them.

You can also use the brief for a weekly account review. A company announcing a new site needs its original source, observation date, assigned owner and commercial question. An old announcement stays dated; an unreadable source is a coverage gap; a repeated announcement should not become a second finding. The release still needs a clear receiving decision.

If a missing market or account answer needs research first, agree that Plan assignment separately. If a complete campaign can already be scoped, Build includes planning, setup, operation and improvement during the agreed period. Your team may receive research and target accounts, share the work or ask ClarityRev to operate outreach. A standalone connection or custom tool has its own scope; a bounded AI preparation task may fit AI Workflows. This brief helps agree deliverables and responsibilities. It does not make a paid Plan compulsory or put every research question inside the €999 entry scope.