Business Process Automation Brief: A Copyable Operator Template

A business process automation brief is a short operating specification for one bounded process. Before a team picks software or starts a build, it records the process boundary, owners, inputs, allowed actions, manual decisions, expected output, acceptance evidence, exceptions, and stop conditions.

IBM defines business process automation as a strategy that uses software to automate complex and repetitive business processes (IBM). Salesforce describes it as using technology to automate repetitive, time-consuming tasks and streamline workflows and processes (Salesforce). The brief precedes product selection and defines the work that software or an operator must perform.

For a boutique consulting firm, the useful unit is one named process with a visible beginning and end, not “automate operations.” The brief must answer:

• What event starts this process?
• What information is required at the start?
• What result marks completion?
• Who owns the result and each manual decision?
• What evidence will show that the automation passed?
• What condition sends the work to a person or stops it?

Operator note: Jungle Roots proposes these questions as an operating template, not as an IBM or Salesforce standard.

If process ownership or inputs remain uncertain, use the AI readiness assessment before scoping a build involving AI.

What should it contain?

The brief should contain enough detail to run, inspect, and accept one automation without relying on an unwritten assumption. The table below is Jungle Roots' proposed copyable format. Replace the guidance in the right column with your own operating facts.

The “allowed actions” and “manual decisions” rows should agree with each other. If the automation may draft a response but not send it, state both facts. If the business owner and operating owner are the same person, name that person in both rows rather than leaving ownership implicit.

Boundary check: If a proposed action is not listed under allowed actions, it is not authorized by this brief. If a condition appears under stop conditions, the workflow pauses or ends exactly as written.

The Jungle Roots method provides the wider context for this proof-first approach. In this brief, the evidence and acceptance-test fields define what the reviewer will observe.

What are Jungle Roots' seven questions for choosing the first process?

Choose a process that your team can describe as a bounded operating unit before discussing products. The sequence below is Jungle Roots' seven-question process-selection sequence. It is not a universal seven-step standard or a claim that one category produces a particular return.

Create a shortlist from work already performed by the firm. For each candidate, ask:

1. Can we name the start event without using a vague phrase such as “when needed”?
2. Can we list the required inputs?
3. Can we state the final output in observable terms?
4. Is one person accountable for the result?
5. Can we separate allowed automated actions from manual decisions?
6. Can we write a pass or fail test using a sample input?
7. Can we name the conditions that stop the automation?

Select a candidate only when the team can answer those questions. A candidate that cannot be bounded can remain manual while its current process is documented. This keeps tool research attached to an actual operating requirement.

This approach also prevents a software catalog from becoming the brief. Connectors, interfaces, and product labels belong in the evaluation that follows. The brief should remain readable if the implementation option changes. Use the separate automation tools guide once the process definition is approved.

Filled fictional example: inquiry triage for Northstar Advisory

The example below was built for this article to show the template filled in. Northstar Advisory is an example boutique firm.

• Brief name: Website inquiry triage
• Business owner: Managing partner
• Operating owner: Operations lead
• Start event: A new inquiry appears in the website form inbox
• Required inputs: Name, work email, organization, inquiry text, and consent field
• Process boundary: From receipt of a complete form submission to creation of a review record
• Allowed actions: Copy submitted fields into the review record, label the inquiry by the approved service categories, and notify the operations lead
• Manual decisions: Decide whether to reply, what to promise, and who should own the conversation
• Output: One review record with the original submission, a service-category label, and a pending-review status
• Evidence: The original form record, the created review record, and the notification record
• Acceptance test: Given a complete sample submission, when the process runs, then one review record contains the unchanged submitted fields, an allowed category label, and a pending-review status; the evidence must show the source and created records
• Exception owner: Operations lead
• Stop conditions: A required field is missing, the category is not in the approved list, or the review record cannot be created
• Exclusions: Sending a reply, assigning commercial priority, or making a client commitment

Notice that the example does not claim the automation will improve conversion, save a stated amount of time, or remove human review. It defines permitted work and testable output.

What does an acceptance test look like?

An acceptance test states the starting condition, the input, the expected observable result, and the evidence that determines pass or fail. Jungle Roots proposes the following format:

Given: [the approved starting state] When: [the approved sample input is processed] Then: [the exact observable output exists] Evidence: [the records a reviewer will inspect] Pass: [all stated output and evidence conditions are present] Fail: [any stated output or evidence condition is absent or altered]

Write tests against the brief, not against a product demonstration. “The workflow ran” is not an acceptance result. “One pending-review record contains the unchanged submitted fields and can be traced to the source record” is observable.

A useful test set can include:

• A valid sample that should reach the stated output
• An input with a stated stop condition that should not proceed
• An input requiring a manual decision that should reach the named owner without that decision being made automatically

The bullets above are proposed test cases within the Jungle Roots template. They are not performance benchmarks. Keep each result binary enough for the business owner to approve or reject without interpreting the builder's intent.

Acceptance rule: A polished demonstration is not acceptance evidence unless it runs the approved test input and produces the output and records named in the brief.

What should stay manual?

Keep a step manual when the brief reserves it for human judgment, approval, or handling of an exception. IBM notes that some workflows can be fully automated while others need automated tasks and manual intervention, especially for activities requiring human judgment (IBM).

For the Jungle Roots template, mark these items explicitly rather than relying on a builder to infer them:

• Decisions that depend on human judgment
• Approval of a client-facing promise
• Handling an input that matches a stop condition
• Resolution of an exception that the brief does not classify
• Changes to the process boundary, allowed actions, or exclusions

Manual does not mean undefined. Name the owner, state what information reaches that person, and state what automated action must not occur before the decision. In the fictional inquiry example, the workflow can prepare a review record. It cannot decide whether Northstar Advisory should reply or make a commitment.

The same discipline applies to AI-related operations. For a related evidence-review workflow, see the AI visibility audit. A separate operating brief should define what, if anything, happens after evidence is collected.

How do you hand the brief to a tool, builder, or managed operator?

Hand over an approved operating package, then require the recipient to map the implementation back to each field and acceptance test. The recipient may be a software vendor, an independent builder, or a managed operator. The brief remains the reference in each case.

Include:

1. The approved brief
2. Approved sample inputs
3. The expected output for each sample
4. The actions the implementation may perform
5. The decisions that remain manual
6. The evidence required for review
7. The acceptance tests and stop conditions
8. The business owner and exception owner

Ask the recipient to identify any field they cannot implement as written. Resolve that gap by revising and reapproving the brief or changing the implementation option. Do not let an undocumented product behavior silently redefine the process.

For a tool, compare its capabilities with the allowed actions, evidence, and stop conditions. For a builder, request a field-by-field implementation map and the test result. For a managed operator, confirm which steps are performed by software and which are performed by a person. Salesforce describes BPA as software streamlining workflows and processes; the operating brief adds the firm-specific boundaries and ownership that Salesforce's general definition does not prescribe (Salesforce).

If the process cannot yet be expressed in this template, begin with an operations audit. If you want Jungle Roots to define the operating boundary, evidence, and acceptance test with you, Get the operations audit. For a buyer comparing firms that define or deliver AI workflows, see the AI consulting firms buyer scorecard.

Related reading

• Business Process Automation Tools Boutique Firms Can Run
• What Is an AI Readiness Assessment?
• AI visibility audit: capture evidence, assign fixes
• AI Governance Framework: Operating Record