Workflow consulting

Understand the workflow before choosing the technology.

I help established, owner-led businesses understand one expensive or frustrating workflow before they buy software, automate it, or hire another employee. I observe how the work actually happens, identify the constraint, and help decide what people should own and where existing software, automation, or AI can help.

What it looks like

Capable people working as human middleware.

  • Copying or re-entering information between systems.
  • Chasing updates or missing handoffs.
  • Reconciling emails, PDFs, spreadsheets, and application records.
  • Searching for information that should be easy to find.
  • Reformatting the same material for different people or systems.
  • Depending on one employee's memory or private workaround.
  • Considering another administrative hire because volume is growing.
  • Owning software that does not match the actual workflow.
  • Believing AI may help but lacking a clear starting point.

These are signals, not proof. Before recommending anything I want to know how often it happens, how long it takes, where it waits, what gets redone, and what it costs the business when it goes wrong.

Who it fits

Established businesses growing faster than their processes.

Owner-led professional and technical service companies, roughly 20 to 150 people, with a workflow that crosses people and software and a process owner who can take part and eventually own the outcome. Architecture, engineering, construction, specialty contracting, managed services, consulting, and multi-location service companies are where I am starting.

I stay away from highly regulated or mission-critical workflows until a delivery partner can carry their security and operational requirements.

How I work with a business

One workflow, beginning to end.

  1. Start with context. What changed, why now, what you have tried, who does the work, who can decide.
  2. Observe a real case. Someone demonstrates a recent example and I follow the information through every handoff.
  3. Establish the current reality. Steps, systems, handoffs, waiting, exceptions, rework, and a baseline where we can get one.
  4. Identify the constraint. Process, missing information, unclear ownership, the current software, an integration gap, or a real automation opportunity.
  5. Design the future workflow. What people keep owning, what technology handles, and where existing software is already enough.
  6. Test the uncertain part. When it helps, the smallest private prototype that can prove or disprove the idea against real examples.
  7. Decide what happens next. Keep the learning and stop, run the prototype by hand for a while, build it internally, or bring in a delivery partner.

Managers describe the intended workflow. The people doing the work reveal the real one.

Engagements

Bounded work with a clear beginning, end, and owner.

Start here

Workflow review

A map of the current workflow, the main constraint with the evidence behind it, a baseline or a plan to get one, and a decision on whether a technology experiment is worth running.

When the answer is uncertain

Prototype sprint

A narrow question with defined test cases, a private human-supervised prototype, measured results, the gaps between prototype and production, and a decision about implementation.

For a larger system

Architecture and acceptance

The future workflow, requirements, risks, ownership, and acceptance tests, so an internal team or delivery partner can build and support it.

Scope and fee are set per engagement after a first conversation.

What I don't take on

I diagnose, design, and test. You or a partner own production.

I own
  • Investigating the workflow and asking what is really happening.
  • Finding the consequential constraint.
  • Designing the future workflow.
  • A bounded prototype when it reduces uncertainty.
  • Standards, requirements, and acceptance tests.
  • Judging whether a proposed system solves the problem that justified it.
Your team or a delivery partner owns
  • Production engineering and security hardening.
  • Data migration and cleanup.
  • Rollout planning and change management.
  • Training at scale.
  • Monitoring, incident response, maintenance, and support.

A prototype reduces uncertainty. It is not a finished operational system. If the business starts depending on it, it needs a separately owned production phase.

Contact

Tell me how the work happens today.

Send a note about the workflow. I reply within one business day.

Prefer a call? Book a 20-minute call and pick a few times.
Prefer LinkedIn? Message me there.