Given the ambitious timeline, we made a deliberate decision to focus the research scope on the highest-priority applications: those most commonly sold as part of multi-product deals or those representing the greatest share of company revenue. I then applied a mixed-methods approach drawing on service design principles, combining qualitative depth with quantitative breadth to triangulate findings and make the evidence as robust as possible.

The full research programme consisted of:

• 3 executive stakeholder interviews with VP of Product, CTO, and Head of Implementation, to frame the project brief and understand strategic priorities
• 16 implementation consultant interviews across all product lines, covering ICs, Analysts, Onboarding Specialists, Team Leaders, and Technical Managers
• 6 live shadowing sessions, attending real client onboarding calls to observe the process as it actually happened, not as it was described
• 1 internal survey with 25 respondents for quantitative validation of qualitative findings
• Desk research into the PS product register, partner documentation, and existing service maps

Note: This project was scoped to include external customer interviews to complete the journey map from both sides. Before that phase could begin, leadership placed the project on hold following the strategic review of the business cases (showcased below).

Qualitative interviews gave us the nuance and the context, the "why" behind the problems. The quantitative survey let us validate those patterns at scale across a company too large to interview in full. Shadowing sessions gave us something neither method alone could provide: direct observation of real onboarding calls happening in real time, with real clients.

Each interview session was documented in a structured Miro board, capturing observations, insights, pain points, and design opportunities. All boards followed the same template, which also incorporated a service map covering time, processes, tools, technology, our notes, and supporting evidence, making cross-product comparison systematic and consistent.

The interviews covered more ground than initially anticipated. By the end of the discovery phase, we had mapped the implementation flow across 12 EcoOnline applications. The service blueprints below represent each product's onboarding process, reconstructed from the internal teams who run it every day.

The gap between "deal closed" and "customer up and running" was costing the company more than anyone had measured.

The research surfaced five systemic problems, consistent across products, teams, and geographies.

1. No standardisation across products
Every product ran its own implementation process with different expectations, different documentation, and different tooling. When a customer bought two products, they effectively experienced two separate companies.

2. The Sales-to-Implementation handoff was broken
Internal satisfaction scores for collaborative processes sat at 3.09 out of 5, and the data extraction and management step scored 2.95, the lowest of all.

3. Over-reliance on manual work
Many onboarding tasks were done manually by consultants as the business didn’t have enough scripts, APIs, or automation systems in place.

4. Inconsistent self-service options
Some products were suitable for self-service but others required full consultant support.

5. Products that undermined client confidence
Consultants described clients as fearful of the products themselves, afraid to make changes, unsure what actions were reversible. One observation from a shadowing session stayed with me, a customer reviewing an onboarding spreadsheet said, "That looks like a scary document and I am glad I am not the one who has to fill it out." EcoOnline's products weren't just difficult to onboard, they were difficult to trust.

The findings fell into two categories that required fundamentally different responses:

Quick wins: handed over immediately
Not all findings required strategic investment. A significant portion of what we uncovered were process problems that implementation and delivery teams could act on without waiting for product development.

I compiled these into a prioritised quick wins tracker, organised by effort size and categorised as either process-related or product-related. Understanding what was in our remit and what wasn't (and routing findings to the right owners) was as important as identifying the problems in the first place.

Foundational issues: escalated for investment
The deeper problems were structural. They couldn't be fixed with a template or a process tweak. They required product development, platform investment, and cross-team coordination at a level that needed leadership backing and proper resourcing.

With the full picture mapped, I built a prioritisation matrix in Miro to organise all identified initiatives across two axes: effort and impact. The matrix was divided into four quadrants: quick wins to act on now, long-term improvements to plan for, initiatives to deprioritise, and items to reassess once foundational work was complete.

I used this matrix to ask diverse stakeholders to vote on the items they found more critical. The voting exercise largely confirmed what the research had already surfaced. However, one result surprised us: 'partner enablement' received a high number of votes despite barely appearing in any of our consultant interviews. This told us something the research alone couldn't see: it was a strategic priority that lived in leadership thinking, not in the day-to-day operational experience of the people we'd spoken to.

The prioritisation exercise brought the project's central tension into focus: leadership wanted quick fixes but the research pointed to structural problems. The matrix gave them a clear view of both, and following an update call, they asked us to translate the most significant findings into formal business cases.

We produced six business cases:

• Update onboarding spreadsheets (low investment, quick win): redesign and rebrand all customer-facing implementation spreadsheets
• Centralised data (multi-quarter, foundational): implement consistent user management and hierarchy services across core products
• UX improvements for self-service (1–2 quarters per product): redesign onboarding flows to reduce reliance on consultants and improve customer autonomy
• Digital onboarding (1 quarter per product): leverage in-app guidance, tooltips, and checklists to standardise onboarding at scale
• Enable partner implementation (strategic expansion): develop an iterative partner experience to support indirect sales
• Global Customer ID (cross-system data integrity): introduce a single unique customer identifier across all products, tools, and integrations

Each case included an executive summary, problem definition, proposed solution, cost breakdown, benefit and impact analysis, risk assessment with mitigations, responsible parties, and estimated timeline. Recommending a band-aid when you've found a broken bone would have been the wrong call, and producing business cases was how I made that argument in a language leadership could evaluate.

The project was placed on hold; the scale of foundational investment required meant it couldn't be prioritised in the current planning cycle. This was the most complex and politically challenging project I've worked on, and it taught me more about research governance and stakeholder management than any project that shipped cleanly. These are my reflections:

Scope before you start. Without a list of agreed deliverables and a defined product scope negotiated upfront, a brief from three executives becomes three separate briefs. I would now negotiate a tighter written scope, covering specific products, specific deliverables, and specific success criteria, before a single interview is scheduled.

Stakeholder visibility is a design problem. Keeping leadership informed makes the difference between research that lands and research that gets shelved. I'd build formal stakeholder touchpoints into the research plan itself: not just updates at the end of each phase, but structured moments of involvement during the research, so findings feel like shared discoveries rather than a designer's report.

Survey first, interviews second. Running the quantitative survey at the midpoint of the project meant we were still trying to define our questions when we should have been deepening our understanding of the answers. Starting with the survey would have given us a high-level map of the landscape before going into 1:1 sessions.

Team presence in research builds buy-in. When the designer is the only person attending the interviews, findings arrive in the room as "the designer's opinion." I attended every session; the rest of the team attended far fewer. If I were doing this again, I'd push much harder for broader participation in the sessions themselves, not just the presentations.

Research is also a political act. The evidence was rigorous. The findings were clear. The business cases were well-structured. What was harder to control was whether the right people felt enough ownership of the conclusions to act on them. That's not a research failure, but it is something I'd factor into the plan from day one.

If this project were revived, the most critical gap to address would be the external customer perspective. The shift toward business case development deprioritized a key research component: the user journey. While consultants were interviewed and onboarding sessions shadowed, no formal research was conducted with multi-app customers who had lived through onboarding across two or more EcoOnline products.

I would also want to do a proper usability test on the onboarding spreadsheets: they are the lowest-effort business case and nevertheless the first touchpoint clients encounter, so the potential for measurable improvement with minimal resources is high.

Beyond that, I'd focus on piloting the two most common app combination journeys to test targeted improvements at small scale before recommending platform-wide investment.

The foundation was built. The research documented. The business cases ready. What remained was direct customer research, a bit of team effort, and a complete design phase to bring some improvements to life.