What We Tell Pacific Northwest Clients Before They Automate Anything

Three conversations in the last month started the same way. Client has heard about AI. Client wants to automate something. Client asks if we can help. We ask what they want to automate. They say "whatever makes sense." That's when we know the timeline just doubled.

The problem isn't enthusiasm. The problem is sequence. You can't automate a process you haven't documented. You can't document a process nobody owns. And you can't hand a model something ambiguous and expect it to guess correctly at scale.

Start with the thing you already do badly

A Seattle nonprofit called us because their grant application reviews were drowning a two-person team. Applications came in as PDFs, Word docs, sometimes scanned images. Reviewers copy-pasted sections into a spreadsheet, scored six criteria manually, then wrote a summary. It took 45 minutes per application. They wanted a model to "read the applications and score them automatically."

We didn't start with the model. We started with the spreadsheet. Turns out three of the six criteria were subjective enough that two reviewers scored the same application differently 40% of the time. The scoring rubric lived in someone's head. The summary template didn't exist—every reviewer wrote freeform notes.

We built the rubric first. Made it specific enough that a human could score consistently. Turned the summary into a structured template with five required fields. Then we ran the model against 50 old applications, compared its scores to the human scores, and tracked where it diverged. Accuracy hit 91% on four of the criteria. The two subjective ones? We left those to humans.

The system we shipped: model pre-scores the four objective criteria, flags applications where confidence is low, drops everything into a review interface where a human confirms the scores and fills the subjective fields. Time per application dropped to 18 minutes. The team didn't lose control. They lost the boring part.

The part nobody warns you about

Token costs are not flat. A model that costs you $40 in testing will cost $600 in production because production has edge cases. Someone uploads a 90-page document. Someone writes "see attached" with no attachment. Someone pastes the same section twice. The model runs, burns tokens, returns junk, and you don't notice until the bill comes.

We set hard caps. Input gets truncated at 4,000 tokens. If the model returns low confidence or an empty response, the request goes to a human queue. We log token spend per request and alert when hourly spend exceeds the daily average by 40%. These aren't features. They're the things that keep your pipeline from failing silently at 11pm on a Sunday when nobody's watching.

What works here, specifically

Pacific Northwest clients care about three things that don't always overlap with what the automation vendor pitched:

Data stays local. We've had two clients in healthcare-adjacent fields and one law firm explicitly ask where the data gets processed. OpenAI's API terms say they don't train on your data. That satisfies some clients. It doesn't satisfy all of them. For the ones it doesn't, we route through Azure OpenAI or run a local model. It's slower and costs more, but it's the correct answer for that client. It degrades gracefully. When the model fails, the system doesn't stop. It routes the request to a human. When the API is down, the system doesn't lose the request. It queues it. When token limits hit, the system doesn't retry the same oversized input fifteen times. It fails clearly and logs why. You can turn it off. Every automation we deploy has a kill switch that reverts to the manual process. Not because we expect it to fail. Because the client needs to know they're not locked in. Adoption goes faster when people trust they can walk it back.

What doesn't work

Automating something nobody wants to do differently. A Portland client wanted to automate their invoice approval process. We mapped it. Turned out the CFO liked reviewing every invoice personally. He didn't want a model pre-approving anything. He wanted a dashboard. We built him a dashboard. Sometimes the automation is just better reporting.

If you're considering this

Start with one process. Document it completely—inputs, steps, edge cases, who decides what when it's ambiguous. If you can't document it in two pages, you're not ready to automate it yet. Get the humans doing it consistently first. Then we'll talk about what a model can take over.

We run a free process-readiness review for Pacific Northwest clients. You describe the workflow, we tell you if it's a candidate for automation or if you need to fix something upstream first. Email hello@craftworkgrp.com or call us. We'd rather tell you "not yet" in week one than watch you spend money on a system that automates a broken process.