Case study
Cost Configurator Approval Flow
Designed a scalable approval workflow for Equinix's multi-billion-dollar construction operations, reducing turnaround time by 20% and achieving 100% adoption.
Project overview / TL;DR
Defining how approvals work at scale.
Cost Configurator (CoCo) was an internal tool used to manage billions of dollars in construction cost estimates across Equinix's global data center projects. As project complexity grew, approval decisions increasingly relied on email, meeting, spreadsheet, and manual follow-up, making ownership and decision history difficult to track.
Starting from an ambiguous request for an "approval function," I designed a centralized approval workflow that clarified review ownership, surfaced decision context, and made approval progress visible across stakeholders. The solution reduced approval turnaround time by 20% and achieved 100% adoption among commercial teams.
01
BUSINESS CONTEXT
Cost approvals depended on distributed teams and informal coordination.
CoCo supported large construction cost estimates that moved through commercial team members, reviewers, and business stakeholders before projects could move forward. Approval decisions had meaningful operational weight, but the workflow surrounding those decisions was not formally represented inside the product.
The brief arrived as a simple feature request: “We need an approval function in CoCo.” The larger issue was that approvals already existed informally across the organization. Teams were using emails, spreadsheets, meetings, and side conversations to keep work moving, but no shared system made ownership, status, or rationale consistently visible.
I interviewed stakeholders to learn about their process and frustrations, and mapped the current workflow to understand how coordination actually happened: who initiated review, who participated, where feedback lived, and how people reconstructed past decisions when something changed.
Existing workflow
The workflow moved forward through coordination effort rather than shared system visibility, which left commercial team members and stakeholders reconstructing progress by hand.
The more I mapped the workflow, the clearer it became that the deeper issue was more than simply adding functionality - it was the absence of a shared operational structure.
Team signal
I spend dozens of hours sending hundreds of emails just to make sure a project is ready to move forward.”
— Commercial Team Member, Stakeholder Interview
Communication Chaos
Approval context was distributed across scattered threads. Reviewers struggled to track feedback, and critical information was buried in inboxes.
Manual Coordination Burden
With 2-6 review levels per project, creators manually tracked who had reviewed, who was next, and repeatedly followed up to keep projects moving forward.
Zero Visibility
No centralized view of review status or approval history. Team members couldn't see past feedback or understand where projects were stuck in the pipeline.
02
KEY CHALLENGES
The hard part was defining how approval work should behave across roles, decisions, and constraints.
01
No shared ownership model.
Estimators, reviewers, commenters, and business stakeholders all participated, but the system did not clarify who owned the next decision.
02
Visibility needed structure without extra overhead.
Teams needed to see review state and rationale without adding another layer of manual project management.
03
Authority and participation were different problems.
Not everyone who provided context should be able to approve, reject, or change the workflow sequence.
04
Discussion had to become part of the system record.
A centralized place needed to preserve decision rationale instead of disappearing into scattered communication threads.
05
MVP feasibility shaped the operating model.
The workflow had to deliver accountability and visibility without major backend restructure.
03
SYSTEM ARCHITECTURE
The approval system needed an operating architecture before it needed screens.
Architecture frame
Movement
How an estimate moved through creation, review, revision, and approval.
Ownership
Who could create, approve, comment, or change the approval sequence.
Visibility
What status, feedback, and review activity needed to remain visible across roles.
Record
Which comments, notes, and approval actions needed to persist as decision context.
Operational loop
The loop turned approval into a repeatable path: estimates moved from creation to review, feedback, revision, re-review, and final approval, with comments, notifications, and history supporting the workflow instead of sitting outside it.
Once the movement model became clearer, the next problem was authority. Not every participant needed the same level of control, responsibility, or visibility throughout the approval lifecycle.
Ownership model
The role matrix separated participation from authority: estimators could create and revise, reviewers owned approval decisions, and commenters could provide context without changing any details.
04
DESIGN EXPLORATION
Turning the approval architecture into product capabilities.
System need
Product capability
Ownership model
Reviewer management and structured approval roles.
Discussion record
Centralized comments and contextual discussion.
Workflow visibility
Review visibility and approval timeline structure.
Decision rationale
Persistent review history and traceable decisions.
Coordination signals
Notification infrastructure and workflow signals.
Early interaction concepts
With the capability structure in place, I moved into lo-fi concepts to quickly explore how the system could operate inside CoCo. The goal was to make the workflow tangible enough for stakeholders and engineers to react to early.
These concepts made the workflow concrete enough to discuss with stakeholders and engineering. The next challenge was deciding which parts of the system could survive MVP constraints.
05
CRITICAL DESIGN DECISIONS
The final MVP came from a series of product decisions under real constraints.
As implementation planning began, the ideal workflow had to be adjusted around engineering feasibility, delivery pressure, and evolving business priority. The goal was to protect user & business goals without overbuilding the first release.
System evolution
The approval model was adjusted as engineering feasibility, business needs, and delivery pressure became clearer during implementation planning.
Implementation shifts
Reviewer sequencing was removed so reviewers could review simultaneously.
Estimators gained manual approval control to keep moving when real review paths were less linear.
Notes became a dedicated workflow capability instead of staying as secondary documentation.
The sign-off tracker and in-app notification center were deferred to protect the MVP timeline.
MVP feature scope
The final MVP focused on preserving accountability, approval visibility, and contextual discussion while reducing implementation complexity where possible.
MVP scope
The scope protected the core operational value of the system: clear responsibility, visible state, and a central place to recover decision context.
Product decisions
Decision 01
Row-level comments preserved context without requiring a backend restructure.
Cell-level comments matched the earliest stakeholder expectation, but engineering confirmed that supporting them would require major data-model changes. Row-level comments kept feedback connected to the estimate context while staying feasible for MVP delivery.
Decision 02
Notes reused the comments pattern instead of becoming a separate system.
Stakeholders later emphasized Notes as operationally critical. Rather than introducing another communication layer, Notes reused the same interaction and architectural patterns as Comments so the team could preserve value while limiting new engineering effort.
Decision 03
Notification infrastructure was reduced to protect delivery confidence.
The original direction included an in-app notification center. For MVP, the team relied on email notifications instead, reducing infrastructure complexity while still giving reviewers and estimators basic workflow signals.
06
FINAL EXPERIENCE
The final experience made approval work coordinated, visible, and traceable.
The MVP brought reviewer coordination, contextual discussion, and approval visibility into Cost Configurator so teams could manage approval work without reconstructing progress across scattered channels.
Capability 01
Coordinate reviewers
The workflow established clear reviewer ownership, approval participation, and decision authority directly inside the product.
Capability 02
Capture discussion
Approval rationale and operational discussion became persistent, centralized, and directly connected to workflow activity.
Capability 03
Track approval state
Teams could now understand workflow progress, review state, and approval history without reconstructing decisions manually.
07
OUTCOMES
Approval work shifted from scattered coordination into a traceable system.
The MVP launched with reviewer coordination, contextual discussion, workflow visibility, and approval tracking integrated into one operational workflow.
What changed
Email threads
Centralized approval workflow
Manual follow-up
Defined reviewer coordination
Hidden status
Visible approval state
Lost rationale
Persistent comments and notes
Operational impact
~20%
Approval turnaround reduction
~500 hrs
Manual coordination reduced annually
100%
Commercial team adoption
Teams reported increased confidence in approval decisions because workflow ownership, approval history, and contextual discussion became visible inside a centralized system.
“This is exactly what we needed. I can finally see where every project stands and who's responsible for what.”
Commercial Team Manager, UAT Feedback
Reflection
The hardest problems were organizational before they were visual.
This project reinforced that enterprise workflow problems are rarely solved by interfaces alone.
The harder challenge was creating shared operational structure across stakeholders, engineering constraints, and evolving business requirements.
It changed how I think about product design: not as screen production, but as a process of clarifying systems, ownership, and decision-making under real organizational constraints.
Future workflow infrastructure, including sign-off tracking and a notification center, could extend the same operating model as approval volume and coordination complexity scale.