Operational Complexity Turned Into a Decision-Ready Transformation Blueprint
The Center for Puppetry Arts was preparing to replace and modernize several of the systems supporting ticketing, fundraising, marketing, internal workflow management, and its public website.
Before those systems could be implemented successfully, leadership needed clarity around a more foundational question:
How should the Center’s people, workflows, customer journeys, data, and technology work together as one connected operating system?
Framework conducted cross-functional discovery, designed the organization’s future-state operating model, and translated that model into RevOps, data-governance, system-architecture, and vendor requirements.
The result was not simply a list of recommended tools. It was a blueprint for what the organization needed its future technology transformation to support.
At a Glance
Client: Center for Puppetry Arts
Industry: Arts, Culture and Nonprofit
Location: Atlanta, Georgia
Primary Need:
Define the operating model, customer lifecycle, system responsibilities, data standards, and cross-functional workflows required before implementing a new technology ecosystem.
Engagement focus:
- Operating model and workflow discovery
- RevOps and customer lifecycle design
- Data governance and system architecture
- Technology evaluation and vendor requirements
Work completed:
Current-state discovery, future-state design, system requirements, implementation guidance, operating documentation, and adoption planning.
The Real Question We Needed to Answer
The engagement was not designed to determine which software had the longest feature list.
It was designed to answer:
- How should work enter the organization?
- What must be complete before another team begins?
- Who owns each decision, approval, handoff, and data point?
- How should customers and constituents move through a shared lifecycle?
- Which system should own identity, transactions, engagement, workflow execution, and public experience?
- What information should move between systems automatically?
- What should vendors be required to configure?
- What must be true internally before implementation can succeed?
Answering those questions first prevented the Center from recreating the same operational gaps inside a new set of platforms.
Our Integrated Approach
The work combined two perspectives that are often addressed separately.
The Inside-Out Operating Model Perspective
We examined how work actually moved across the Center, including intake, readiness, approvals, ownership, cross-functional handoffs, exception management, and operational execution.
The Outside-In RevOps and Customer-Journey Perspective
We mapped how families, schools and groups, adult audiences, donors, partners, and puppetry professionals discovered, engaged with, purchased from, experienced, and returned to the Center.
Together, these perspectives connected internal operations to customer experience, revenue, reporting, data governance, and technology requirements.
-
7
core audience groups connected
through one shared customer lifecycle created from staff expertise -
22
tools, systems, and operational artifacts consolidated
into 5 main platforms to unblock (at scale) revenue and funding possibilities -
173
pages of future-state documentation
thoroughly detailing who owns what, when operational readiness happens, who patrons are, each persona's journey, and what would be required to make adoption stick
-
A comprehensive operating reference covering:
- Core audiences
- Lifecycle stages
- Revenue architecture
- Workflow categories
- Intake and validation
- Default and exception lanes
- Cross-functional workflows
- Handoff contracts
- Reporting
- Data governance
- Operating rhythms
- Adoption and training guidance
-
A documented framework defining:
- Required system capabilities
- Data ownership
- Platform responsibilities
- Integration expectations
- Technology-evaluation criteria
- Recommended future-state architecture
-
A shared blueprint aligning implementation vendors around:
- System roles
- Data standards
- Workflow requirements
- Integration boundaries
- Implementation principles
- Success conditions
-
Supporting documentation included:
- SOPs
- Requirements packets
- Team starter guides
- Workflow guidance
- Readiness standards
- Adoption and training materials
The debrief identified these materials—including the Default Lane and Exception Lane framework, Definition of Ready, validation checkpoints, workflow-to-system requirements, system architecture, and starter-guide structure—as the strongest reusable components of the methodology.
What Changed for The Center and It's Perspective of the Future
The most significant outcome was not that the Center received 173 pages of documentation.
It was that leadership and teams gained a clearer explanation for why their work kept becoming difficult.
The organization could now see that:
- The problem was not insufficient effort.
- A new platform would not resolve unclear operating rules.
- Workflow breakdowns and data problems were connected.
- The customer experience was shaped by internal handoffs.
- Systems had to reinforce the operating model rather than define it.
- Implementation required clearer ownership, sponsorship, capacity, and readiness.
- Technology decisions needed to be made as part of an ecosystem.
Organizations ready to find out and leverage what works vs what doesn't to close their revenue or funding gap.
Let's frame your future impact.
Schedule time with us to understand root causes of system issues and the possibilities of what can be unlocked.