Understand the workflow before choosing the technology.
I help businesses examine one expensive or frustrating workflow. I observe how the work happens, find where it gets stuck, and recommend what to change, whether that involves responsibilities, existing software, automation, or AI.
We'll discuss the workflow, see whether the work is a fit, and decide on a useful next step. You suggest a few times and I confirm one.
What it looks like
Your people keep the work moving by filling the gaps.
Where two systems do not connect, a person connects them. Some people call that role human middleware: capable staff doing by hand what the tools were supposed to do. The work gets done, but it depends on their effort and memory, and it does not scale. It usually looks like this:
Copying or re-entering information between systems.
Chasing updates, approvals, or missing handoffs.
Reconciling emails, PDFs, spreadsheets, and application records that disagree.
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
Businesses with a workflow that keeps demanding attention.
The work fits when three things are true:
A recurring workflow is consuming time or creating delays, errors, or repeated intervention.
The people involved in the work can explain and demonstrate how it happens.
An owner or responsible leader can take part in decisions about changes.
Most of the businesses I talk with are professional and technical service companies, roughly 20 to 150 people, without an internal systems architect for the workflow in question. Architecture, engineering, construction, specialty contracting, managed services, consulting, and multi-location service companies are where I am starting. The industry matters less than the pattern.
Start with context. What changed, why now, what you have tried, who does the work, who can decide.
Observe a real case. Someone demonstrates a recent example and I follow the information through every handoff.
Establish the current reality. Steps, systems, handoffs, waiting, exceptions, rework, and a baseline where we can get one.
Identify the constraint. Process, missing information, unclear ownership, the current software, an integration gap, or a real automation opportunity.
Design the future workflow. What people keep owning, what technology handles, and where existing software is already enough.
Test the uncertain part. When it helps, the smallest private prototype that can prove or disprove the idea against real examples.
Decide what happens next. Keep the learning and stop, run the prototype by hand for a while, build it internally, bring in a delivery partner, or have me build it.
↳ Managers describe the intended workflow. The people doing the work reveal the real one.
Engagements
Start with one workflow.
Which workflow, and what problem?
One recurring workflow that costs time or creates delays, errors, or repeated intervention. We choose it in the first conversation and name the problem we are trying to understand before anything else.
What I need from you
A recent, real example. An hour or two with the people who do the work, so they can show me how it happens. Access to the documents and systems the workflow touches. An owner or responsible leader who can take part in decisions about changes.
What I do
Observe the work, document the current reality, identify the constraint, and design the future workflow. When the answer is uncertain, I build the smallest private prototype that can test it against real examples.
What you receive
It depends on the engagement, described below. A workflow review ends with 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.
Who puts it into practice
Your team, a partner, or me. If I build it, the scope is fixed and it's handed to your team when it's done. The next section explains how.
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 your team, a delivery partner, or I can build it.
Scope and fee are set per engagement after a first conversation.
How the fix gets built
Who builds it, and what happens after?
When a fix is worth building, I can build it with your team. Each build has a fixed scope, and its price is based on what the fix is worth to you. We agree on both before any work starts. When it's done, I hand it to your team with what they need to run it.
If your team would rather build it, or you already have a partner, I'll give you the plan and check that the finished system solves the problem we put a number on.
After a build, we can stay in touch once a month to look at what's working and what's next. Whether that includes support for what I built, and what kind, is something we agree on together before we start.
Part of every engagement
Finding what's really slowing the work down.
Putting a number on what it costs.
Deciding what to fix first.
Designing the fix.
When you want it
Building the fix, with a fixed scope and a defined handoff.
A monthly check-in after the handoff, with support agreed per client.
Your team owns
Running it day to day once it's handed off.
If I build a quick prototype to test an idea, I'll tell you plainly whether it's ready to rely on or needs a proper build first.
From owners I've worked with
As a small business owner, I often wear all the hats. It's exhausting at times and I find myself spending time on tasks that should be delegated so I can focus on the key activities that drive my business revenue. That's where Amos stepped in. We walked through operational processes, identified inefficiencies, and Amos educated me on AI and operational ways to create more margin in my work day. Amos helped me automate several clerical tasks in a way that I didn't realize was even possible. I definitely recommend Amos and really appreciate his insights.
Nathan Rueckert, Artist & Founder, Baseball Seams Co.
Want to hear it from him? Ask, and I'll introduce you.
Uplift Local Media sells ads on screens inside local businesses. We spent part of a working session on the report that shows each advertiser how often their ads played.
I've used the ad play report multiple times and it helps a lot.
I find what's really slowing the work down, put a number on what it costs, and help you decide what to fix first. I'm a computer engineer turned process consultant, so when a fix is worth building, I can build it too. Sometimes the answer is a change in who does what, or better use of software you already own.
What happens in the first conversation?
We talk about one workflow that keeps demanding attention: what comes in, who touches it, and where it gets stuck. By the end you'll know whether I think it's worth a closer look and what the next step would be. If it isn't worth fixing, I'll say so.
What do I receive after a workflow review?
A map of how the work happens today, the main thing slowing it down and the evidence for it, an estimate of what that costs you in a year, and a recommendation on what to fix first. From there you can fix it yourselves, bring in a partner, or have me build it.
What if the answer isn't AI?
Then I'll tell you. Some problems come down to who owns a step, or a tool you already pay for that nobody has set up. I'd rather recommend the simplest fix that works.
Do you build the fix, or does my team?
Either. If I build it, we agree on a fixed scope first, and when it's done I hand it to your team with what they need to run it. If your team or a partner builds it, I'll give you the plan and check that the finished system solves the problem we put a number on.
Do we need to be using AI already?
No. Many of the owners I talk with use it in a browser tab or not at all. What matters is a workflow that keeps costing time, and people who can show me how it happens.
Who needs to be involved?
The people who do the work, for an hour or two, so they can walk me through a real example. And an owner or leader who can decide on changes.
How much does it cost?
It depends on the size of the problem. We put a number on what the problem costs before I quote anything, so you can judge the price against it. Scope and fee are set after a first conversation.
Where do you work?
I'm based in Sioux Falls, South Dakota, and work with teams remotely across the US. I also meet businesses in person when I travel.
Nathan Rueckert, Artist & Founder, Baseball Seams Co.
Amos Buelow, Uplift Local Media