From Sandbox confusion
to Production readiness
Designing a Go-Live Checklist to help cross-border payment clients move from technical implementation to production with more clarity, confidence, and alignment.
ATTRUS clients go through a technical implementation process before they can process live payments. This journey — from API integration to Sandbox testing to Production activation — was taking 30 to 65+ days and often ended with clients going live before they were truly ready.
I structured a discovery process to understand the onboarding system end-to-end. Through journey mapping, stakeholder alignment, and a synthesis workshop, the team identified that the root problem wasn't just a missing document — it was the absence of a shared, visible definition of production-readiness.
The output was the Go-Live Checklist: a structured, phased artifact that makes readiness visible and actionable for both clients and internal teams. This case documents the discovery, synthesis, and design decisions behind it.
The challenge was bigger than a checklist.
The symptoms were visible in support queues and implementation timelines. The root cause was structural: the onboarding process had no shared clarity about what success looked like.
No shared definition of "ready"
Neither clients nor internal teams had a common, explicit standard for what it meant to be prepared for production. Everyone operated from their own mental model.
Timelines stretched to 30–65+ days
The implementation journey lacked clear milestones and checkpoints. Clients were often blocked by invisible dependencies they didn't know existed.
Clients moving to production unready
Some clients migrated from Sandbox to Production before completing necessary tests, leading to production failures, incident response load, and financial corrections.
High support load and correction work
Each unready go-live created downstream work: support tickets, internal triage, and financial corrections — absorbing capacity that should have been spent elsewhere.
Business and user impact.
The onboarding problem wasn't isolated to the client experience. It created real pressure on both sides of the relationship.
Client-side impact
- Slow time-to-revenue — weeks spent in implementation limbo
- Low visibility into what remained before going live
- Confusion about who owns which steps in the process
- Production failures after go-live due to incomplete testing
- Eroded trust in the platform during a critical adoption window
Business-side impact
- Support and implementation teams absorbing reactive, unplanned work
- Delayed revenue activation per customer
- Financial corrections required for premature go-lives
- No systematic way to verify readiness before production activation
- Critical knowledge living in individuals rather than process artifacts
Mapping the onboarding system before designing the solution.
Before proposing anything, the goal was to build a shared understanding of the full implementation process — its stakeholders, failure modes, and where the real friction lived.
Journey mapping
Mapped the full onboarding journey from acquisition to Go-Live — touchpoints, frontstage actions, backstage operations, stakeholder ownership, and known pain points.
Existing research synthesis
Compiled inputs from previous research, NPS feedback, support tickets, and internal documentation to establish a baseline understanding of recurring issues.
Stakeholder perspectives
Gathered perspectives from implementation, support, sales, and technical teams to understand each team's view of where the onboarding process broke down.
Customer feedback analysis
Reviewed direct customer feedback and NPS responses focused on the implementation experience to identify the most painful friction points from the client side.
AI-assisted opportunity mapping
Used AI to simulate perspectives of different internal teams and enrich the opportunity landscape. Outputs were treated as additional inputs — not as source of truth.
Discovery board creation
Consolidated all inputs into a shared discovery artifact in FigJam — connecting journey mapping, insights, stakeholder views, and process knowledge in one visible space.
HMW workshop
Facilitated a "How Might We" synthesis session with key stakeholders to cluster insights into themes and surface opportunity areas collaboratively.
Opportunity refinement
Refined opportunity areas through internal discussion on feasibility and potential impact, narrowing focus to the production-readiness gap as the key design opportunity.
A shared space to make the problem visible.
The discovery board was the central artifact of this process — a live space where customer feedback, internal knowledge, stakeholder perspectives, and journey maps converged into a shared view.
Multiple research streams in one place
NPS data, customer interviews, support logs, internal process documentation, and stakeholder perspectives — all mapped to journey stages.
Breaking silos between teams
The board made the full onboarding system legible across implementation, support, sales, and product — creating a common reference point.
From scattered data to structured themes
The board became the source material for the HMW workshop — enabling the team to cluster insights and prioritize opportunities collaboratively.
The key insight.
Clients weren't just missing documentation.The deeper problem was that there was no shared, visible definition of what “ready to go live” actually meant.
Each team had their own informal checklist — a mental model of what needed to happen before a client went live. These models diverged. Some criteria were never communicated to clients. Others were assumed rather than verified. The result was inconsistency that showed up as production failures.
Making readiness explicit and shared — for both clients and internal teams — meant aligning expectations before activation rather than correcting failures after. This reframe shifted the problem from “we need better docs” to “we need a shared production-readiness standard.”
Turning the insight into a direction.
How might we create a shared, visible definition of production-readiness that both clients and internal teams can rely on before a go-live?
This framing shifted the focus from “build a document” to “create a shared standard.” The opportunity wasn't just about giving clients a list to follow — it was about making the definition of readiness legible, consistent, and actionable for everyone involved in the process. The Go-Live Checklist became the product response to that opportunity.
The Go-Live Checklist.
A structured, phased checklist that makes production-readiness visible and actionable for both clients and internal teams — replacing informal mental models with a shared standard.
Depending on the final implementation scope, the specific checklist items and phases may vary. The structure below reflects the solution direction explored during discovery and prototyping.
From concept to artifact.
Two levels of prototype were built to validate the concept and communicate the interaction model — a high-fidelity Figma design and a functional coded implementation.
High-fidelity prototype
Figma file with screens, components, and interaction flows for the Go-Live Checklist product.
Functional coded prototype
A fully interactive implementation built with Next.js and TypeScript, demonstrating real interactions, state management, and the complete checklist experience.
Available as a local demo or screen recording. Contact to request a walkthrough.
Four principles that shaped every decision.
These weren't just design values — they were decision filters applied at every step of the solution design process.
Make the most important things obvious.
A checklist fails if it overwhelms. Each item was evaluated against whether it truly needed to block go-live. Items that didn't block readiness were moved to reference documentation — not the checklist.
Readiness is a joint responsibility.
The checklist was designed to surface who owns each step — not just what needs to happen. This reduced ambiguity and made handoffs between client and internal teams explicit.
Make progress legible at a glance.
Both clients and internal teams need to answer "how close are we?" without navigating through documentation. The design prioritized a clear, scannable view of completion state.
Consistency builds confidence.
A consistent checklist applied to every client means a predictable, fair process. No more 'it depends on who you're working with.' The checklist creates a baseline standard clients can rely on.
What success would look like.
These are the metrics and outcomes the team expected the Go-Live Checklist to influence. At the time of this case study, the product had not yet been fully launched and validated at scale.
Editorial note: The metrics below represent the intended impact framework — a hypothesis to validate, not reported outcomes. They are presented as designed success criteria, not achieved results.
Reduced implementation time
Shorter average time from contract signing to production activation, driven by clearer steps and fewer surprises at each handoff.
Fewer premature go-lives
Reduction in clients activating in production before completing all required tests, measurable via post-go-live incident volume.
Lower implementation support load
Decrease in implementation-related support tickets as clients have a clearer path to follow and know what to expect at each stage.
Improved client confidence
Higher NPS or CSAT scores during the implementation phase, reflecting a clearer and more transparent onboarding experience.
The work that remains.
A discovery and solution direction is the beginning, not the end. These are the validation steps I would prioritize to move from concept to a proven, scalable solution.
Validate with real cohorts
Run the checklist with a defined cohort of new clients and measure implementation time, support load, and go-live readiness against a pre-checklist baseline.
Test with implementation teams
Observe how internal teams use the checklist during client handoffs. Identify whether the ownership assignment per item is clear enough to reduce ambiguity in practice.
Explore progressive disclosure
Investigate whether a phased reveal — showing only the current phase's items — reduces cognitive load without hiding information clients need to plan ahead.
Integrate with existing tooling
Evaluate where the checklist should live: as a standalone product, embedded in the client portal, or connected to internal CRM and implementation workflows.
Revisit scope based on client feedback
Determine which checklist items are genuinely blocking — versus informational — through structured client feedback sessions and post-go-live retrospectives.
Design that makes
complex systems legible.
This case is about more than a checklist. It's about identifying where clarity is missing in a complex system, creating the conditions for shared understanding, and designing artifacts that teams and clients can actually trust.