Build it yourselves, or have it built
There are two ways to work with Natural State Logic. The difference is who does the building, and both start with an Intro call at no cost.
- Your people build it: Team TrainingYour own people learn to build simple workflows with Claude, one bottleneck at a time, with coaching each month.
- Built for you: the done-for-you trackA Workflow Review picks the workflow, an Automation Pilot builds and tests it, and Ongoing Support keeps it running.
The done-for-you steps always run in that order. Scope and terms for either track are agreed in writing after the call, once it is clear which one fits.
New to this? Read what a business automation consultant actually does and whether it is worth it for a small office, or see jobs like after-hours voicemails turned into job tickets and a shared inbox sorted.
Build it, or have it built?
It comes down to who does the work. If your people want to learn to build their own workflows with Claude, that is Team Training. If you want a workflow built and kept running for you, that is the done-for-you track. You decide together on the Intro call.
Do it yourself
Team Training
A monthly engagement in which your own people learn to use Claude to build and run their own simple workflows, one bottleneck at a time, with Natural State Logic coaching. It isn’t custom-built software; for that, see the done-for-you track.
Each month includes
- Two 45-minute calls
- Working sessions: your people build on their own Claude accounts while Tanner coaches, and each call ends with something saved that you keep.
- Support between calls
- Questions between calls on Voxer, with no limit on messages and a reply within one business day.
- A monthly Progress Note
- A short note recording what was worked on, what your people built, and what comes next.
On these terms
- Claude only
- Your organization holds Claude Team or Enterprise seats in its own name. Personal or Pro accounts are never used with company data.
- Your people do the work
- One bottleneck at a time, chosen together. Tanner never signs in to your accounts and holds none of your credentials.
- You own what is built
- The skills, projects, and prompts your people build are yours, and stay yours.
Done for you
Review, Pilot, then Ongoing Support
Natural State Logic does the work, in three steps that each depend on the one before.
- Workflow ReviewDecides which workflow is worth building first, and whether it is worth building at all.
- Automation PilotBuilds that one workflow and evaluates it against real work and agreed criteria.
- Ongoing SupportKeeps the workflow running afterwards: monitoring, reviews of usage, cost, and access, and support.
On these terms
- Built and run for you
- Your team names the problem and approves what matters; the building, connecting, and testing are done for you.
- One workflow, measured
- The Pilot builds one workflow and judges it against success criteria agreed before work starts.
- Fitted to your systems
- Connected to the tools you already use, by whichever method fits, and not limited to Claude.
- A person stays in charge
- Anything with consequences waits for someone on your team to approve it.
The bridge: Move-up Triggers
Some jobs are better built for you. If a piece of work needs any of the following, it moves to the done-for-you track, and the rest of your Team Training carries on as before:
- Custom code or a custom integration
- A connector or MCP server that does not exist yet
- Write access to a system of record, such as accounting, CRM, or HR
- Regulated or sensitive categories of data
- Anything that runs unattended
That piece is proposed separately, in writing, and you can decline it. Team Training is not a first step toward the other track: most Team Training clients keep doing the work themselves, and done-for-you clients do not need to start with it.
The done-for-you track, step by step. Each step follows the one before it, because each step needs what the previous step produced.
Each title below leads to that step’s full description, and Team Training is described on its own page.
Intro call
At no cost
Is there a problem here worth examining, and are we the right people to examine it?
Workflow Review
Paid engagement
Which workflow is worth changing first, and is it worth changing at all?
Automation Pilot
Paid engagement
Does the recommended workflow work in real use, and does it meet the criteria set for it?
Ongoing Support
Paid engagement
Who keeps it reliable, and who notices when it stops being reliable?
The no-cost call and the paid Review are different conversations.
Intro call
At no cost
A short fit conversation. It is not a shortened assessment, and no analysis is produced.
- Purpose
- Decide whether Natural State Logic and the problem you have are a good fit for each other.
- Time
- 20–30 minutes, arranged at a time that suits you.
- Cost
- At no cost, with no obligation to continue.
- You leave with
- A direct answer about fit and an honest next step—including “not yet” when that is the correct answer.
- It is not
- A written assessment, a prioritized roadmap, or an analysis of your systems, data, and workflows.
Workflow Review
Paid engagement
Structured, documented work that ends in a decision you can act on and a plan you can follow.
- Purpose
- Examine the workflows, systems, value, feasibility, and risk, then recommend a workflow worth building first.
- Scope
- Agreed in writing before work starts, based on what the Intro call established.
- Cost
- A paid engagement. Scope, schedule, and commercial terms are agreed in writing before work starts.
- You leave with
- Prioritized opportunities, a recommended pilot, and a written roadmap—or a documented recommendation not to proceed.
- It requires
- Access to the people who do the work and accurate information about your systems and data.
The call is at no cost because it decides fit, not because the work behind an assessment is quick. Nothing about your systems is analyzed in depth until a Review scope is agreed.
Security, documentation, and human authorization apply to every step.
Both tracks carry the same conditions: what a workflow may reach, what gets recorded, and who authorizes an action that has consequences. These apply from the Review through Ongoing Support, including during a pilot, and to everything built in Team Training.
Security Constraint
A minimum condition for an engagement, not a tier that can be removed to reduce scope or cost.
- Identity and authorization design
- Every workflow begins with who the user is and what that person is already allowed to open. Nothing is retrieved, summarized, or sent on behalf of an identity that should not have it.
- Least-privilege access
- Each identity holds the narrowest access that does the job. Broader or standing administrative access is not requested for convenience.
- Data-flow review
- What enters a workflow, where it travels, which provider processes it, and what is retained is written down and agreed before work starts.
- Tenant and client isolation
- Work built for one organization stays inside that organization’s boundary, and data from one engagement never becomes context for another.
- Secret handling
- Credentials and keys live outside source control and outside anything a model can read, and they are rotated when access changes.
- Provider review
- Where data reaches a model or software provider, terms, retention behavior, and data-use positions are reviewed rather than assumed.
- Retention decisions
- How long a workflow’s inputs, outputs, and logs are kept is decided deliberately, and deletion stays possible.
- Untrusted content
- Email, documents, and web content are treated as untrusted input. Retrieved content cannot change what a workflow is permitted to do or which actions it may take.
Documentation and auditability
Work that cannot be explained after the fact cannot be relied on, so records are written as the work is done.
- Implementation documentation
- What a workflow does, which systems and data it touches, who owns it, what it deliberately excludes, and how to reverse it.
- Logging and auditability
- For actions with consequences, the record shows what happened, what the system proposed, who authorized it, and when it ran.
- Test and rollback approach
- Each implementation is tested before it runs on real work, and a failure leaves the underlying record untouched and reports the error.
Human authorization
Sensitive actions stay with a person, by design, in every engagement—including pilots.
- Accountable approval
- Record changes, payments, and externally facing messages are approved by someone accountable for the outcome before they execute.
- Assistance is not autonomy
- Drafting, summarizing, and classification support a decision; they do not make it, and they never replace the person responsible.
- Approval designed in advance
- Approval points are placed before the workflow runs, and the approver is identified in the record rather than assumed.
Not sure whether to build it or have it built?
Describe the work that is costing you time. The call is short, and its purpose is to establish fit, which track suits you, and the honest next step, which may be that nothing here is worth building yet.