Operational Intelligence: A Workflow Layer for Fragmented Pricing Deployments.
A bot + workflow layer that subscribes to events across the half-dozen systems a pricing deployment touches and reconciles them into one canonical state — so 'where is this?' and 'who owns the next step?' stop being questions that take four DMs to answer.
Context
A single pricing deployment touches half a dozen systems: config repos, experiment platforms, approval ticketing, deployment orchestrators, monitoring dashboards. Each has its own source of truth, its own notification model, and its own idea of 'done.' Teams coordinate the edges with Slack threads and institutional memory.
The mandate was to build a workflow layer that could see across those systems and answer the questions the org kept re-asking manually: where is this deployment, who owns the next step, what approvals are still outstanding, and when did the last handoff happen.
Business Problem
“The work wasn't hard — the coordination around the work was. Status updates were a full-time background process no one's title owned.”
Without a unified surface, tracking a deployment meant pinging four systems and three people to piece together a picture that went stale as soon as it was assembled. Handoffs slipped through cracks; approvals queued behind stale context; audit requests became archaeology. The process worked — barely — because senior operators held the full picture in their heads. That's not a system; that's a bottleneck waiting for its owner to go on vacation.
- Context-Switching Tax
- Dropped Handoffs
- Stale Approvals
- Audit Archaeology
The Senior Approach
The layer treats each deployment as a workflow with explicit states and explicit owners. The bot subscribes to events from every upstream system, normalizes them into workflow transitions, and exposes the current state in the place work already happens — chat. Crucially, it doesn't try to replace the upstream systems; it reconciles them.
Event Normalization
Built adapters that consume events from each upstream system and translate them into a shared workflow vocabulary — 'config merged,' 'approval granted,' 'deployment live,' etc.
Workflow State Machine
Modeled the deployment lifecycle as an explicit state machine with named transitions, owners per state, and timeouts that page when a state stalls.
Chat Surface
Exposed the current state and pending actions in Slack so status-checking moved out of 1:1 pings and into a place the whole team could see.
Realistic System Architecture
Representative Transition Shape
# Each transition names the event that triggers it, the owner
# responsible for the next step, and the audit record emitted —
# so status, accountability, and audit trail share one substrate.
@transition(
from_state=ConfigReview,
to_state=AwaitingApproval,
trigger="config.pr.merged",
)
def config_merged(deployment: Deployment, event: Event) -> Transition:
return Transition(
next_owner=deployment.approval_owner(),
sla=timedelta(hours=4),
audit=AuditRecord(
actor=event.actor,
artifact=event.pr_url,
note="Config merged; approval routing engaged.",
),
)Outcome & Senior Judgment
The Impact
Key Takeaways
- 1
Reconcile, don't replace.The leverage came from making the existing systems legible together, not from trying to become the new source of truth. Replacement projects fail; reconciliation projects compound.
- 2
State machines make accountability concrete.'Who owns this right now' is a question every operational process should be able to answer in under a second. A named state + named owner is the cheapest way to get there.
- 3
Audit is a byproduct of good structure.When every transition emits an audit record by construction, audit requests stop being a special project and start being a query.