Automation Request Architecture

Requests to automate a notification, an alert, or a partner handoff arrive constantly and almost always as a sentence. The architecture existed to convert that sentence into a specification an engineer could act on, and to make prioritization an arithmetic exercise rather than a persuasion contest.

Everybody agreed the operation needed automation and nobody agreed on what first. Requests were phrased as outcomes, not as mechanics, so the same idea meant three things to three teams. The harder issue was underneath: a large share of the requests had no reliable trigger event or no single record that could be trusted to answer the question. Those requests were not hard to build. They were impossible to build correctly, and that only surfaced weeks into the work.

• Ask for the trigger event first. If nobody can name the moment the automation should fire, the request is a wish.
• Demand a source of truth. Two systems disagreeing about the state of an order is the actual project, and it should be named before anything is scheduled.
• Split execution into three lanes: what changes internally, what the partner must do, and what the customer receives. Most failed automations were strong on one lane and silent on the others.
• Require monitoring in the request. An automation nobody watches fails silently, which is worse than the manual process it replaced.
• Name an owner and a fallback. Systems that run unattended still belong to a person.
• Write acceptance criteria before estimating. If success cannot be described, it cannot be verified after launch.
• Score volume against effort and let the plot argue. Ranking by opinion produced a permanent tie.

1. 01

   A request specification

   A fixed set of fields covering trigger, source of truth, internal execution, partner execution, customer communication, internal task assignment, monitoring, timing rule, owner and fallback, dependencies, and acceptance criteria.

2. 02

   A scored request register

   Every request captured with estimated monthly volume and share of orders affected, so the operational weight of each idea was visible next to it.

3. 03

   A phase boundary

   An explicit nice-to-have column, so useful but non-essential scope could be recorded without inflating the first build.

4. 04

   A partner-facing view

   The subset of each request that depended on the logistics partner, separated out so external dependencies could be negotiated as a group rather than one ticket at a time.

1. 01

   Make the form mandatory before the conversation

   It felt bureaucratic and it was the highest-leverage decision in the project. Roughly half the backlog resolved itself once people had to write down what would trigger it.

2. 02

   Treat customer communication as part of the automation

   An internal state change that the customer learns about by calling in is not an improvement. Every request had to say what the customer sees and when.

3. 03

   Refuse requests without a source of truth

   Rather than building against ambiguous data, unresolved requests were held and the data ownership question was raised on its own. Slower, and it prevented automating a wrong answer at scale.

• Became the intake layer behind the customer journey operating system.
• Turned the partner relationship from ad hoc asks into a negotiated dependency list.
• Established the habit of writing acceptance criteria before estimating effort.

The register was valuable less as a plan than as a diagnostic. Reading the completed fields told you exactly where the operation lacked reliable data, and that turned out to be more useful than any single automation that came out of it. If I built it again I would add a column for what the manual workaround costs today, because that number ends prioritization arguments faster than volume does.

• Customer Operations
  Customer Journey Operating System →

  A complete communication architecture spanning purchase through long-term customer success, designed as an operating system rather than a set of messages.

• Customer Operations
  Order Operations Architecture →

  An operating model for orders: one rule that settles ownership, a split-intake work design, and a decision tree an associate can run in the moment.

• Customer Operations
  SOP Systems & Documentation Governance →

  A three-layer model separating the operating model from the directory from the executable steps, with one rule preventing version drift.