Beyond The Hedge — Job Workflow Visibility System (Revised)

Purpose

Beyond The Hedge helps an artisan business identify the information people need as work moves through the shop, determine where that information currently lives or becomes difficult to find, and create a simple shared system that makes job status, exceptions, decisions, and next actions visible to the people who need them.

The objective is not to replace systems that already work. It is to make the information already being generated throughout the business easier to see, use, and keep current.

The Core Problem

Every shop already has a system.

A custom framing shop may use production sheets, handwritten shop tickets, emails, conversations, supplier information, and the knowledge of experienced employees.

The problem is often not that information doesn't exist.

The problem is that the complete story of a job rarely lives in one place. When someone needs an answer, they may have to find the person who knows it, search through paperwork, check another system, or reconstruct what happened.

The Beyond The Hedge objective is to identify these visibility gaps and strengthen the existing operation without unnecessarily replacing the tools and practices that already work.

The Six-Stage Method

1. Observe

Before designing a solution, observe how information actually moves through the shop.

For three to five working days, notice whenever someone has to stop what they are doing and ask another person for information about a job.

Capture:

• Job

• Question

• Who needed the information

• Who had the answer

• Where the answer actually lived

• Effect on the work

Example — Framing shop

Job 1847 Question: Has the customer approved the new moulding? Needed by: Production Answer held by: Designer Location of information: Designer's email Impact: Work stopped while the answer was found.

Example — Upholstery shop

Job 512 Question: Did the customer confirm the nailhead trim color? Needed by: Upholsterer Answer held by: Owner (phone call, no notes taken) Location of information: Owner's memory Impact: Job paused for a day waiting for the owner to be reachable.

This becomes a simple Job Visibility Observation Log. Treat the counts from this log (number of interruptions per day, total time lost) as your baseline — you'll compare against it later in the 30-Day Review.

The purpose is to gather evidence rather than assume where the problems are.

2. Diagnose: Map the Workflow and Find the Gaps

This stage has two connected parts: first describe how a job actually moves and what information it generates, then look across that description for the patterns that cause the most disruption. Keeping these together avoids a common trap — restating each individual handoff problem twice under two different headings.

2a. Map how a typical job moves through the business

For a framing shop, the workflow might look something like:

Design & Consultation → Order & Shop Ticket → Materials Ordered → Materials Received → Matting → Cutting → Fitting & Quality Review → Packaging & Store Delivery → Customer Pickup

Note that "Production" is rarely one undifferentiated stage on the shop floor — for a framing shop it typically breaks down into Matting, Cutting, and Fitting & Quality Review, each with its own handoffs and its own person responsible. Map the workflow at the level of detail the shop actually works at, not at the level of a simplified summary.

At each stage, ask:

• What information is created here?

• Who creates it?

• Where is it stored?

• Who needs it later?

• Can that person easily find it?

This creates an Information Handoff Map.

Example rows

Customer preference Created by: Designer Stored in: Conversation or notes Needed later by: Production Potential problem: Not recorded on shop ticket

Material substitution Created by: Manager or supplier interaction Stored in: Email Needed later by: Framer Potential problem: Framer does not see the change

Customer approval Created through: Telephone conversation Stored in: Employee memory Needed later by: Production Potential problem: No visible confirmation that approval occurred

2b. Identify the recurring visibility gaps

Once several individual handoff problems are on the map, look for the patterns that repeat across jobs — these are the actual targets for the system, not the individual incidents.

Common patterns:

• The same person repeatedly being asked for information

• Production frequently going back to sales or design

• Jobs waiting because nobody knows whether a decision was made

• Material status being difficult to determine

• Customer changes not becoming visible downstream

• Employees having to search multiple places for basic job information

• Customer questions requiring someone to "check and call back"

These are not necessarily failures in the existing process. They are signals that certain information deserves a more visible, shared home. The output of this step is a short, prioritized Visibility Gap Assessment — three to six recurring patterns, not a catalog of every incident on the map.

3. Define the Minimum Job Information Standard

Determine the small amount of information that should be easily visible for every active job.

Possible fields include:

• Job number

• Customer

• Current stage

• Promised date

• Responsible person

• Materials status

• Waiting on

• Next action

• Important customer/design notes

• Last update (date + who updated it)

The objective is not to document everything. The system should emphasize information that another person may need in order to understand or move the job forward.

In practice, this standard is a single information path — job status, the shop ticket or its equivalent, and customer requirements — that should travel with the job through every stage, visible to whoever touches it next. In shops with a coordinating role (a shop manager, lead, or similar), that person's job is largely to keep this path intact: prioritizing jobs, coordinating handoffs between stages, resolving exceptions, and approving completed work. The "Responsible person" field should reflect this — for a stage inside a production group (e.g., Matting, Cutting, Fitting), it may be both the person doing the work and the coordinator who owns exceptions across that group.

Standard Information vs. Exception Information

Most jobs do not require extensive notes. The most valuable information is often the exception.

Examples:

• Customer changed moulding

• Waiting for replacement glass

• Designer needs customer approval

• Moulding backordered until September 18

• Orientation confirmed with customer

• Material substitution approved

• Production question resolved

• Customer returned job for correction — sent back to production for rework

That last example matters because exceptions don't only move forward. A job can move from Customer Pickup back into production when a correction is needed. The system should make a returned job just as visible as a new one — including why it was returned and who is responsible for the fix — rather than letting it quietly re-enter the shop as an untracked repeat.

The system should make these exceptions highly visible without creating unnecessary administrative work.

4. Build the Visibility System

Only after understanding the information problem should Beyond The Hedge determine the appropriate technology.

Possible platforms could include:

• Notion

• Airtable

• Google Sheets

• Existing POS or framing software

• Other systems already used by the business

The objective is to create the smallest reliable shared visibility layer.

A shared job system might include views such as:

• All Active Jobs

• Due This Week

• Waiting on Materials

• Waiting on Customer

• Production

• Quality Review

• Ready for Pickup

The system does not necessarily replace the physical shop ticket or production sheet. Those tools may continue doing what they do well. The shared visibility system provides the information that multiple people need to see without having to locate another employee or another piece of paperwork.

5. Establish Ownership and Adoption

A visibility system only works if it stays current. This stage exists because the single most common failure mode for tools like this is not poor design — it's abandonment within a few weeks because no one owned keeping it updated.

Before launch, establish and document:

• Update ownership. Who updates the record, and at what point (e.g., at each stage transition, end of shift, immediately after a customer call)? A field with no named owner will go stale.

• A staleness signal. How is a record flagged when "Last update" is older than expected for its stage — a view, a color flag, a daily check?

• The minimum habit. What is the smallest behavior change being asked of each role? Framers, designers, and front-of-house staff will adopt a two-field update far more reliably than a full re-entry of job details.

• A trial period with a named owner. One person (often the owner or manager) is responsible for checking adoption daily for the first two weeks, not just building the system and hoping it sticks.

This produces the Implementation and Adoption Checklist — a short, practical document, not a policy manual.

6. Review and Measure

Thirty days after launch, compare the shop against the baseline captured in Stage 1.

Track:

• Interruptions per day (compare to the original Observation Log count)

• Average time to answer a "where does this job stand" question

• Missed handoffs or jobs that stalled because a decision wasn't visible

• Late jobs, and whether the cause was a visibility gap or something else

• Whether the "Last update" field is actually being kept current, and by whom

This produces the 30-Day Review — a short report on what changed, what didn't, and what the system should do next (expand, simplify, or adjust fields). Without this stage, "did it work" stays a guess.