A small-business owner may recognize a repetitive task without knowing every decision that makes it work. The person who handles the task each day often carries unwritten knowledge: which sources are trusted, which exceptions matter, when a request is incomplete, and who must approve the next step. A useful AI workflow starts by making that operating knowledge visible.

This guide gives readers of *Your Computer Is About to Wake Up* a practical interview for one bounded business workflow. It is designed for United States small businesses considering a local or connected AI system. It does not assume the task should be automated, and it does not turn an employee interview into permission to monitor performance or collect unrelated personal information.

Los Angeles County teams can pair this interview with the shared-handoff approach on the Los Angeles AI workflows page. Local AI Developer works nationally and does not claim a Los Angeles office.

Choose one handoff, not a whole job

Start with a narrow event that has a clear beginning and receiver. Examples include preparing a supplier-delay brief for purchasing review, routing an incomplete support inquiry, or collecting the evidence needed for a project-status decision.

Avoid broad prompts such as “Tell me everything you do” or “How could AI replace this role?” They create anxiety and produce vague answers. A better opening is: “We are documenting how one request moves from arrival to a reviewed output. The goal is to understand the work, exceptions, and boundaries before deciding whether any tool belongs in it.”

Write a provisional one-sentence scope:

> When a defined input arrives, the operator uses named sources to prepare a defined output for a named reviewer or destination.

The interview should test and revise that sentence. If several unrelated outputs or decision owners appear, split them into separate candidate workflows.

Prepare without pre-deciding the answer

Ask the operator to bring two or three representative cases: one ordinary, one incomplete or conflicting, and one that required escalation. Use sanitized or authorized examples. Do not copy customer, employee, supplier, financial, or credential information into a new interview file merely because it appears in the working system.

Also gather the current checklist, template, form, folder, mailbox, queue, or application view used for the task. Mark each item as an approved source, an informal aid, or an unknown source that needs an owner decision.

Before the meeting, define where notes will be stored, who may read them, and when raw notes will be summarized or disposed of. Tell the participant what is in scope. A workflow interview is not a hidden audit of unrelated behavior.

Ask for a walkthrough of a real case

Begin with the ordinary example. Ask the operator to narrate what they observe and decide, not just which buttons they press.

Useful questions include:

Record business meaning alongside tool steps. “Open the blue tab” is fragile. “Check the current approved purchase-order revision” explains the purpose and can survive an interface change.

Ask the operator to point out information they deliberately ignore. That may reveal a useful minimization rule. The system should not ingest an entire mailbox or shared drive if the workflow needs only a defined case, approved fields, and a source reference.

Distinguish observation from judgment

For each step, ask whether the operator is copying an observed fact, applying a written rule, using experience, or making a business decision. These categories have different automation and review implications.

An observed fact might be a received timestamp or stated quantity. A written rule might route a case when a required identifier is absent. Experience may help interpret an unusual supplier message. A business decision might approve a refund, change a delivery commitment, or accept a contractual exception.

Do not disguise decisions as data entry. If the operator chooses between conflicting sources, ask who authorized that priority and where it is documented. If no owner can answer, mark the point as unresolved rather than teaching a system to copy one person's habit.

Create a simple table with the step, information used, type of reasoning, authority owner, evidence required, and permitted outcome. The table helps identify where an AI system may prepare information while a person retains approval.

Find the real intake boundary

Ask what qualifies as a valid case. The arrival of an email may not be enough. A usable request might require an account identifier, product, location, due date, attachment, or source-system record.

List required, optional, and prohibited inputs. For every required field, define where it comes from and what happens when it is missing. The answer may be hold for clarification, route to a named person, or use the existing manual process. It should not be “let the AI guess.”

Also ask about duplicates and revisions. How does the operator recognize that two messages refer to the same case? Which revision is current? What makes a reopened case different from a retry? These identity rules are essential before tools can safely process repeated triggers.

Study the difficult example slowly

Use the incomplete or conflicting case to expose the hidden workflow. Ask the operator to pause at every point where the ordinary path breaks.

Capture:

Avoid a generic “send to a human” rule. Name the role, routing destination, evidence packet, and fallback when that person is unavailable. If the operator resolves an exception by asking a specific colleague, document the business authority behind that route rather than hard-coding a personal relationship.

Ask about work that should stay manual

Invite the operator to identify actions they would not trust to an automated path. The answer may include changing prices, promising a delivery date, sending an external message, deleting a record, approving a refund, or interpreting an unusual contractual request.

For each boundary, ask whether a system may prepare a draft, present source evidence, recommend a category, or only hold the case. Then define what explicit approval looks like and what receipt proves an approved action occurred.

Some work may remain manual because cases are rare, sources are inconsistent, authority is unclear, or consequences are difficult to reverse. That is a valid discovery result. The interview is successful if it prevents a poorly scoped build, not only if it produces an automation candidate.

Document tools and the actual data path

List every mailbox, folder, spreadsheet, application, device, and external service used by the case. Record the organization-controlled account, permitted resources, data read, data written, and owner who may change access.

Ask whether information is copied into personal notes, local downloads, chat tools, or exports during the current process. Do not shame the operator; the purpose is to map reality so the business can decide on an approved path.

A Mac mini-based system can keep readable workflow instructions and selected operating records in a business-owned location. Connected applications or cloud AI may still receive task information. The proposed design should state what stays on the computer, what leaves it, and who controls each destination.

Measure effort without turning it into surveillance

The business needs enough evidence to judge whether the workflow is worth improving. Ask for approximate case volume, ordinary handling time, review time, exception frequency, waiting time, and rework. Use a small representative sample when possible and label the limits.

Measure the process rather than ranking the employee. Waiting for a source owner and actively handling a case are different. A careful review that catches an expensive error is not waste simply because it takes longer.

Record ranges instead of false precision. Note peak periods and categories that were absent from the sample. The data should support scoping and capacity planning, not unsupported productivity claims.

Convert the interview into a workflow evidence packet

After the meeting, prepare a short structured packet rather than retaining a raw transcript as the operating specification. Include:

1. revised one-sentence workflow; 2. valid intake and case identity; 3. approved sources and owners; 4. ordinary steps and output; 5. named exceptions and holds; 6. human decision and action boundaries; 7. reviewer and fallback route; 8. tools, accounts, and data destinations; 9. completion evidence; 10. volume and effort ranges; 11. unresolved questions; and 12. representative acceptance cases.

Ask the operator to review the packet. Then ask the business owner or source owner to confirm authority, source priority, and prohibited actions. The person who performs the work can explain reality, but may not own every policy decision.

Keep disagreements visible. If the operator and manager define completion differently, do not average the answers. Resolve the conflict or mark it as a blocker before a build.

Test the packet with another authorized person

Give the packet and a sanitized case to a backup operator or reviewer who did not lead the interview. Ask them to identify the case, find the approved sources, recognize a hold, prepare the output, and state what they are not authorized to do.

Observe where they need private coaching. Missing terminology, undocumented source locations, personal shortcuts, and unclear approval evidence should return to the packet for revision.

Test at least one counterexample. A useful specification should tell the backup person when not to continue. If every case appears to pass, the boundaries are probably incomplete.

Decide whether to scope, observe, or stop

End discovery with a decision, not an assumption. The business may choose to scope a bounded workflow, collect more examples, clarify a source or policy, keep the task manual, or stop because the value does not justify the operating burden.

A scoping decision should name the accepted input, output, reviewer, excluded actions, test set, and unresolved dependencies. It should not authorize expansion into adjacent mailboxes, departments, decisions, or locations.

The book page introduces the broader idea of a personal or business-owned AI computer in plain language. This interview turns that idea into evidence about one real handoff without promising that a tool can or should replace the judgment around it.

Bring the evidence packet to a scoping conversation

Local AI Developer's build packages cover scoped Mac mini-based systems with readable business memory, approved connections, human approval boundaries, documentation, and package-defined support. Compatibility and operating design depend on the accepted workflow.

When you are ready, start an inquiry with the one-sentence workflow, representative cases, approved sources, named reviewer, three exceptions, prohibited actions, approximate volume, data destinations, and unresolved owner decisions. That packet creates a more useful conversation than a broad request to “automate the business.”