How your team makes the way they work.
Build is the function that decides how the work gets done. It's the difference between a team that follows scripts and a team that owns its operation. Macros, workflows, decision trees, the architecture of the day.
v 02 · live
What Build means.
Build is the work of making the way the work gets done. Not the work of buying tools. Not the work of writing scripts. The work of designing the workflows, macros, decision trees, and routing logic that turn a customer's request into a resolution, and maintaining that scaffolding as the work changes.
Most CX teams inherit a macro library nobody owns. Workflows that were correct 18 months ago. Routing rules written by an admin who's no longer there. Decision trees that don't match the product anymore. The team navigates around the parts that don't work and the operation calcifies.
That's the gap Build names. The tools have configuration; nobody owns it. Workflows have logic; nobody maintains it. The operation runs on accumulated history rather than considered design. New product changes don't flow through. Drift becomes the default.
"We had 247 macros. I asked the team how many they actually used. The honest answer was about 30. The rest were leftovers from people who'd left, products we'd discontinued, or rules someone wrote one Tuesday and forgot. The whole library was lying to us."
Haven's Build module starts with the workflow audit. What's used. What's stale. What's missing. The macro library, the routing rules, the decision trees: all named, all tracked, all owned. A maintenance cadence replaces accumulation.
The operation gets simpler over time, not more complex. Each product change has a flow-through to the operation. Each new capability has a place to live.
The progression. Four levels.
The macro library accumulates. Workflows are written when problems appear and never retired. Nobody owns the configuration. Drift is the default.
- Accumulated macros
- Stale workflows
- No configuration owner
- Operation calcifies
Some maintenance happens, when there's time. Quarterly cleanups catch the worst. Most of the library is still leftover. New product changes flow through inconsistently.
- Quarterly cleanup at best
- Most library is legacy
- Inconsistent change flow
- Maintenance is firefighting
The library is owned and audited. Macros have owners, dates, and usage counts. Stale workflows are retired routinely. Product changes have a defined path into the operation.
- Owned library
- Routine audits
- Clear retirement criteria
- Product change pipeline
The library shrinks as quality grows. Macros are consolidated. Workflows get simpler. The operation responds to product changes within a sprint.
- Library is shrinking
- Workflows simplifying
- Sprint-paced product flow-through
- Quality metrics improve as count drops
What Build builds.
The macro audit
Every macro tagged with owner, last-used date, usage count. Stale ones retired. The library shrinks first, then grows with intention.
- Owner attribution per macro
- Last-used · usage count telemetry
- Stale-flag rules & retirement queue
- Drift detection on every release
The workflow map
Top 20 customer journeys mapped end-to-end. Decision points named, owners assigned, drift detected. The operation made legible.
- End-to-end journey diagrams
- Decision points named & owned
- Exception paths captured
- Versioned per product release
The change pipeline
A defined path for product changes to flow into operations. Each release has named operational impacts. No more surprises.
- Operational impact named per release
- Macro · process · KB updates queued
- Pre-flight checklist per change
- Post-release drift review