You should write the rule before you automate a workflow only when people still disagree on what the rule is. If the team already knows how a record should move and they spend the week copying it anyway, waiting for a perfect SOP is how that handoff (work leaving one person so another can continue) stays expensive for another quarter.
"Never automate a broken process" is right when nobody can state the decision in a sentence two people would accept, and wrong when the decision is already known and the cost is volume. Before you pick a side, put a number on the copy-paste tax for one pathway so the argument is about a handoff rather than a slogan.
When writing the rule first is the right call
If two coordinators would route the same intake to different pods, software will ship that disagreement at the speed of the queue. The workflow is non-deterministic because the rule lives in someone's head, or in a few heads that do not match, and connecting the steps will not resolve the fight. It will only raise the volume of exception tickets your senior people already handle by hand.
In a 20 to 200 person service firm this usually shows up as a handoff with no entry criteria. Team A passes a half-built record and expects chat to fill the gaps, or an approval added after one old mistake still sits in the path. The same CRM field means contract start to one person and work start to another.
You do not fix that by buying a connector. You fix it by naming the fields, writing the entry criteria, and assigning an owner for the exceptions that remain, then deleting the fake approvals, because automation has nothing useful to follow until those pieces exist.
Write the rule first when:
- People who do the job would not draw the same box around
"done" - Today's failures come from interpretation rather than typing speed
- The definition would not survive a Tuesday when the person who
"just knows"is out
You need that definition, not a forty-page binder.
Labeled synthetic, judgment-heavy: a professional services shop routes new work by "complexity." Managers who sit in the same meeting would still sort the same packet differently because complexity was never a field. Automating that assignment would only put the disagreement on the calendar. Define the criteria first (entity type, jurisdiction, whether prior-year files exist) and then the routing can be a map.
When waiting for a perfect process is the stall
The same sentence gets pointed at work that is already rules-based. A person copies client details from intake into a tracker, fixes the date format, and pings delivery that the file is ready. Nobody is making a strategy decision in that minute; they are paying a weekly tax so the firm can postpone writing a mapping everyone would already agree on at the whiteboard.
Waiting for perfect documentation on that kind of handoff is how operations teams stay in analysis paralysis. You will not list every exception in a conference room, because volume is what reveals the weird records and those records force the standard.
Build a narrow pipe when the work is deterministic data routing: the source fields are known, the destination fields are known, and the transformation is a map you can write as trim, reformat, lookup, or reject. Put validation at the front and an exception inbox at the side so a failed record stops and names the field. Automation does not replace the standard here; it is the forcing function that shows which rules you actually need, because the queue tells you which cases the current map cannot handle.
Labeled synthetic, deterministic: the same shop copies engagement dates from a signed checklist into the project tracker and reformats them. The rule is already known, so holding the integration until someone writes a full process binder keeps the same people in the same weekly loop. Stand up the map, reject bad dates into an inbox, and let the rejects write the remaining rules.
Cost stays invisible while the work is all manual, because every delay hides inside someone's day until a date slips. If you have not priced the pathway, measure that handoff before you argue about tools. Use your own tallies, not a borrowed percentage:
Weekly Routing Tax
How to tell which case you are in
Ask the same pathway four questions. If the answers split, you are mixing two problems and should split the scope before you schedule a workshop or a build.
| Question | Write the rule first | Automate to force the rule |
|---|---|---|
| Do two people agree on "done"? | No | Yes |
| Does a typical record need judgment? | Yes, and it is not written down | No. It follows a map |
| What fails today? | Interpretation of the same instruction | Volume, format, and missed copies |
| What you do next | Name fields, entry criteria, and an exception owner | Narrow pipe, validation, exception inbox |
If the data is freeform and required fields are routinely missing, you are in the first column even if the team is also busy, because busy does not make a judgment call into a map. If the inputs are already structured and people agree on the destination, you are in the second column even if someone wants a binder first.
Teams often mix the two and then stall on both. They document a date-reformat handoff that has no judgment in it, while the routing rule that causes fights stays oral, or they connect the judgment step because it is noisy and watch the exception queue fill with cases nobody agreed how to close. Split the pathway so you write the contested rule and automate the map that is already agreed.
When not to use a live workflow to learn the rule
Skip a live workflow as a discovery tool when:
- A bad record can leak client data, send a wrong invoice, or trip a filing. Write those edge cases down before anything moves without a person.
- The service model still changes every few months. Code will rot as fast as you write it, so stabilize the offer and then bind the handoff.
- You cannot name the single pathway.
"Fix operations"is not a scope. Pick the handoff that already produces fights about the fields, or the one that already has a measurable copy tax. - The next step is still a sales conversation dressed as a form. If a partner has to decide scope before the record is real, no workflow will make that deterministic.
Next step
Map the bottleneck first, then say whether the next hour goes to writing the rule, building a pipe, or buying something. Flaux runs that as an operational AI assessment: one pathway, a split between judgment and routing, and a stop if neither build nor buy is the right next move.