# The bernan.ai Operator Starter Pack

The first mistake is adding more tools before naming the work.

Use this pack to choose one repeated workflow that is worth fixing. Do not start with a company-wide AI rollout. Start with one result you can verify.

## 1. Find the work that repeats

Write down the work that meets all four conditions:

1. It happens at least once a week.
2. It follows a recognizable sequence.
3. It consumes at least three hours a week across the team.
4. A person can tell whether the result is correct.

Good starting points include preparing a recurring report, turning field notes into a proposal, extracting action items from meetings, following up on open invoices, or sorting an inbox into decisions and drafts.

Do not start with strategy, hiring decisions, employee discipline, final pricing authority, or anything irreversible.

## 2. Define the finish line

Complete this sentence:

> When this workflow is done correctly, I have __________, checked against __________, before __________.

Example:

> When this workflow is done correctly, I have a draft proposal, checked against our approved scope and pricing table, before the estimator reviews it.

If the finish line cannot be stated plainly, the workflow is not ready to automate.

## 3. Name the inputs

List only the sources a careful employee would need:

- The starting document, message, photo, or record
- The company rules that control the result
- The approved source of truth for names, prices, dates, and status
- One example of a correct past result
- One example of a result that should be rejected

Missing inputs should stop the workflow. They should never invite a plausible guess.

## 4. Separate judgment from procedure

Make two columns.

### Procedure

- Copying known fields
- Applying an approved formula
- Looking up a value in a named source
- Formatting a standard deliverable
- Checking required fields
- Routing a draft for review

### Judgment

- Choosing a price without an approved table
- Making a promise to a customer
- Approving a payment
- Sending an external message
- Changing a live record
- Deciding what the company should do

Automate the procedure first. Stage the judgment for a person.

## 5. Install three gates

Every useful first build needs three gates.

### Input gate

Are all required inputs present, current, and from the approved source?

### Output gate

Does the result contain every required field, follow the approved format, and pass the known calculations?

### Action gate

Can the system save a draft safely, or does the next step require a person to approve it?

If any gate fails, stop and say what is missing. Do not quietly continue.

## 6. Measure the baseline

Before changing the workflow, record:

- Minutes per run
- Runs per week
- People involved
- Rework or error rate
- Time between the first input and the usable result

Measure the same five numbers after the build. Faster is not enough if error rates rise or the result becomes harder to audit.

## 7. Run the first test

Use one real, low-risk example.

1. Run the old process and save the result.
2. Run the new process from the same inputs.
3. Compare every consequential field.
4. Record what differed and why.
5. Fix the rule, source, or gate.
6. Run the same input again.

The workflow is ready only when the same input produces the same approved result inside a declared tolerance.

## Your one-page build brief

Copy this block into a new document:

```text
Workflow:
Owner:
Runs per week:
Current time per run:
Finish line:
Required inputs:
Approved sources:
Procedure to automate:
Judgment to keep human:
Input gate:
Output gate:
Action gate:
Test example:
Rollback:
Metric after launch:
```

That is enough to have a useful build conversation. If the brief still feels vague, the right next step is not more software. It is one hour spent observing the work.