Lesson 1 - Define the Workflow

In this lesson, we’ll look at a real business process - we’ll want to be able to define the workflow clearly enough that we can turn it into a Zebric blueprint.

For the purposes of this tutorial - this is where Taylor, HarborFlow’s Head of Operations, decides that the team’s “customer exception request” process has become too messy to keep running through Slack and spreadsheets.

Right now, everything is going through emails, text messages, and updates to spreadsheets that aren’t seen right away. Some of the requests are getting lost in the process, and customers are unhappy. It’s really hard to get an overhead view of where everything is in the process.

Goal for this Lesson

By the end of this lesson, you should have:

• one internal workflow worth fixing now in your own team or organization
• a named team or person who owns the process
• a concrete description of the items that move through the workflow
• a definition of what a successful first version should do
• a short prompt brief for the LLM

Choose The Right Workflow

Pick a process with all of these characteristics:

• it happens often enough to matter
• it does not require a full product team to validate
• it can be improved by better intake, visibility, routing, or approvals

Good examples:

• vendor intake
• access requests
• contract review intake
• customer escalation tracking
• hiring request approvals

Bad first examples:

• anything requiring deep customer-facing product design
• anything with many external integrations on day one
• anything where no one agrees on the process yet

For HarborFlow, the right first workflow is one narrow process:

• intake of customer exception requests
• review by ops
• approval or rejection
• visibility into what is still pending

Capture The Workflow In Plain Language

Write down:

• who submits the request
• who reviews it
• what gets stored
• what statuses it moves through
• what a submitter needs to provide
• what a reviewer needs to decide
• what happens when the request is approved or rejected

For Taylor, that plain-language description might sound like this:

• account managers submit exception requests
• ops reviews whether the request is feasible
• urgent requests need faster review
• approved requests move forward for execution
• rejected requests need a clear reason

Operator Brief Template

Use a brief like this:

We need an internal tool for [process name].

The people using it are:
- [submitter role]
- [reviewer role]
- [approver role, if any]

Each record should track:
- [field 1]
- [field 2]
- [field 3]

The workflow goes through these statuses:
- [status 1]
- [status 2]
- [status 3]

Users need:
- a list view
- a form to submit a new request
- a detail page to review a request

The first version is successful if:
- [success outcome 1]
- [success outcome 2]

Here is a filled-in version for HarborFlow:

We need an internal tool for customer exception requests.

The people using it are:
- account managers who submit requests
- operations managers who review requests
- directors who approve unusual or high-priority exceptions

Each record should track:
- customer name
- request title
- priority
- exception details
- status

The workflow goes through these statuses:
- submitted
- reviewing
- approved
- rejected
- completed

Users need:
- a list view
- a form to submit a new request
- a detail page to review a request

The first version is successful if:
- the ops team has one place to see every active request
- reviewers can tell what is waiting and what needs a decision

Lesson Output

Turn that brief into one final prompt input for the next lesson. Keep it short, concrete, and operational.

If you don’t have your own process, just use the HarborFlow template.

Lesson 2 happens entirely in the browser using the Zebric Playground — there is nothing to install yet.

Zebric Concepts In This Lesson

• Blueprints: you are defining what the blueprint needs to express before you write it
• Entities: you are identifying the main record the app will track
• Pages: you are deciding which core pages the first version needs
• Workflows: you are naming the business transitions the tool will eventually support

Next Lesson

Continue to Lesson 2 - Generate the First Blueprint With AI.