Case Studies

Case Study: Systematizing Onboarding

Universal Problem

Even high-performing companies falter when onboarding is a set of inherited habits rather than built on a coherent system.
The impact isn’t limited to new hires. Under these conditions, even experienced employees are forced to operate from diverging assumptions. In other words, when an organization can’t reliably teach “how things are done,” people can’t properly get aligned. Instead they have to improvise. And improvisation at scale produces chaos: inconsistent execution, preventable rework, and in client-facing roles, damaged relationships.

People rarely fail because they lack the skill. Instead, they fail because the organization never gave them a solid foundation in the first place.

Context: Cannabis SaaS

In a cannabis SaaS organization shaped by strict compliance requirements, the onboarding process consisted mostly of people being dropped into a maze of inherited habits and incomplete or inaccurate CRM records. More experienced team members offered incompatible explanations of key workflows, and role expectations could shift from conversation to conversation. Core processes existed in scattered files, legacy routines, or personal memory — rarely in the same form twice, and rarely aligned with regulatory reality.

Under conditions like these, even long-tenured staff developed their own interpretations of “how things are done,” and those interpretations diverged quickly. There was no stable way for a newcomer to understand what “good” looked like, because even veterans understood it differently.

People weren’t set up to succeed. They were asked to improvise in an industry where improvisation carries real regulatory and financial risk.

Intervention

My first step was to diagnose the places where the process was failing quietly. Not just the obvious gaps, but the hidden dependencies that made onboarding fragile.

I mapped how information actually flowed from sales to onboarding, identifying the gaps and the points where key details were consistently lost. I clarified who needed to own what, and where responsibilities blurred or contradicted each other. And I reorganized onboarding around the actual structure of the system, creating specific, itemized, and iterable project management tools to guide the process.

The result was a structured, repeatable onboarding sequence anchored in:

• consistent expectations
• clear definitions of “done”
• accurate process documentation
• predictable touchpoints and escalation routes

Onboarding became less about surviving a firehose and more about integrating clients into a coherent system.

Outcome

• Reduced preventable churn and confusion among both onboarding and client-service staff
• Faster time-to-effectiveness across roles, especially in sales-to-implementation handoffs
• Clear, shared expectations between sales, onboarding, engineering, and support around what “success” meant at each stage
• Lower operational stress and smoother delivery for teams responsible for onboarding and maintaining client relationships

Case Study: Mapping Data Flow to Expose Compliance Risk

Universal Problem

In regulated industries, data lineage is not a mere technical detail — it’s the backbone of compliance. This is especially true in consumer goods, where traceability underpins product safety, recall protection, and audit readiness. When key information must be re-entered between operational stages, the system loses continuity, and with it, the ability to prove where a product came from and what events shaped it. That loss creates regulatory, financial, and reputational risk long before any failure becomes visible.

Context: Vertical CPG Operations

The platform under analysis supported fully vertical operations, where raw materials were tracked, transformed, manufactured, and ultimately sold within a single integrated software ecosystem. In environments like these, regulatory compliance depends on preserving batch lineage across every stage of production. That continuity should have been automatic. Instead, several workflows required critical identifiers to be manually recreated as material moved downstream.

Each re-entry introduced the possibility of error and, more importantly, created a break in traceability. End-users attempted to adapt, but the software developer was unaware of the underlying flaw and, once informed, was not equipped to determine how best to implement a corrective solution.

Intervention

To surface this failure clearly, I built a comprehensive data-flow map for a fully vertical operation, tracing the trajectory of each critical data element as material moved from cultivation through harvest, processing, manufacturing, packaging, and retail. The model accounted for:

• unit conversions and transformation events
• lab results and quality attributes
• packaging workflows
• outbound flows such as sales, transfers, and disposal

By modeling how information should move, it became possible to identify where it was actually getting lost. The diagram revealed:

• the precise point where batch lineage broke
• how the break propagated into reporting and reconciliation
• and the downstream impact on compliance and audit readiness

With the map in hand, I presented leadership with:

• the lineage break itself
• its operational and financial consequences
• the compliance exposure it created
• and a set of practical recommendations for remediation

The document served both as a diagnostic tool and as a communication bridge, allowing non-technical stakeholders to understand the seriousness of the issue.

Outcomes

Regardless of when or whether the recommended fix was ultimately implemented, the work had several lasting impacts:

• It demonstrated how systems mapping can surface regulatory exposures long before they escalate into violations.
• It made a previously invisible compliance vulnerability unmistakably clear.
• It gave leadership a visual and conceptual model for understanding operational risk.
• It provided sales, onboarding, and product teams with a shared reference for how vertical data should move through the system.
• It enabled onboarding and training staff to teach operators how to avoid triggering the lineage break, reducing avoidable downstream errors.

Case Study: Rebuilding Knowledge Management at a Legacy Firm

Universal Problem

As organizations grow, their knowledge management capacities can struggle to grow with them. Instead, it fragments. Critical information ends up scattered across documents, isolated in inboxes, buried in ticket threads, improvised in slide decks, and stored in the private memories of whoever “remembers how this works.” Over time, teams lose their shared understanding of the system. They compensate with improvisation, duplication, and informal workarounds — each one increasing friction, slowing onboarding, and degrading the lived experience of work.

In other words, without a coherent knowledge architecture, every department ends up living in its own reality.

Context: Legacy Traceability SaaS

This organization was one of the earliest entrants in the cannabis regulatory traceability space. Theirs was a legacy platform built long before the industry professionalized. Unlike newer competitors, whose systems evolved alongside modern documentation standards, this company relied heavily on the knowledge held by long-tenured staff. For a long time, that worked. Many employees had been there since the beginning; they carried the system in their heads, and tribal memory functioned as the organization’s de facto knowledge base.

But as the company grew, the limits of that model became harder to ignore. The product expanded, new offerings were introduced, roles shifted, and historical staff were stretched thin trying to teach what only they remembered. Institutional memory — once a strength — had become a bottleneck. Without a central place for shared understanding, inconsistencies multiplied across support, engineering, onboarding, and sales. New hires struggled to assemble even a basic mental model of the system, and experienced staff spent increasing amounts of time re-explaining the same fundamentals.

Intervention

Initially brought in to evaluate escalation prioritization, I quickly realized that the organization was being undermined by deeper structural issues rooted in knowledge fragmentation. Through stakeholder interviews, workflow observation, and documentation audits, I mapped the friction points slowing onboarding, support, engineering, and customer communications. The pattern was unmistakable: this wasn’t a documentation deficit — it was the absence of a coherent knowledge architecture.

To make the stakes explicit, I created a Knowledge Management Benefits Map that linked specific interventions to operational improvements and strategic outcomes. This allowed leadership to see how a unified knowledge ecosystem could shorten onboarding, reduce support burden, lower error rates, and improve overall product understanding.

From there, I developed a high-level knowledge architecture for the company, including:

• a unified structure for organizing product, process, and compliance knowledge
• guidelines for content ownership and lifecycle management
• an initial schema for a centralized, cross-department KM portal
• alignment between internal documentation, onboarding curricula, and customer-facing knowledge bases
• recommendations for tooling and governance (Confluence, LMS integrations, documentation workflows)

The goal was simple: transform tribal memory into shared institutional understanding — and in doing so, reduce avoidable friction across the entire customer and employee lifecycle.

Outcomes

The work produced several meaningful outcomes:

• It improved escalation handling by introducing clearer prioritization pathways, reducing resolution time, and decreasing repeat escalations.
• It gave support, engineering, and onboarding teams a shared view of the systemic issues driving customer friction.
• It made the structural consequences of fragmented knowledge unmistakably visible, shifting leadership’s understanding of the problem from “we need better documentation” to “we need a proper knowledge architecture.”
• It provided a strategic framework that linked operational pain points to measurable business outcomes.
• It offered a scalable blueprint for how the organization could transform tribal memory into shared, durable institutional understanding.

In the end, the organization faced deep structural challenges that no single project could solve, but the work clarified the nature of those challenges and what would be required to address them.

Case Study: Transforming Tribal Knowledge into Operational Clarity

Universal Problem

In growing software companies, documentation often lags behind operational complexity. Without a canonical source of truth for the platform, every team ends up generating its own explanations of how the system works — each one slightly different. Support queues fill with training questions, onboarding becomes inconsistent, and engineers lose sight of user-facing standards. The organization begins to operate in parallel realities, and the cost shows up everywhere: rework, slow response times, frustrated customers, and a system that becomes increasingly difficult to maintain and develop.

In other words, when a product lacks an authoritative manual, the company ends up endlessly rebuilding its own knowledge.

Context: Early-Stage Compliance SaaS

I was brought in to contract with a young organization growing faster than its internal infrastructure. In its first year, the company launched a complex, compliance-heavy software platform without developing a formal documentation strategy. Training was improvised on the fly, and implementation and onboarding lacked any practical structure. Support inherited the downstream consequences: an escalation queue filled with basic workflow questions rather than technical issues.

Sales faced the opposite problem. With no authoritative reference for what the system actually did, reps relied on their own interpretations — and sometimes their imaginations — leading to inconsistent expectations and preventable churn. Engineers, meanwhile, seldom interacted with the product as users, so their understanding drifted away from lived operational reality.

The result was predictable: each department operated from its own assumptions about the product — none of them aligned, and none of them documented. The company had launched a platform, but not a shared understanding of that platform. And without a canonical reference point, the gap widened every day the product and the market evolved.

Intervention

My first priority was to stabilize how information showed up in the organization. With no canonical reference for the platform, support, onboarding, engineering, and sales were all relying on different assumptions. To address this, I designed the company’s first comprehensive user manual.

Using vector-design software, I created a set of visually consistent, workflow-driven modules that combined interface guidance, compliance considerations, and operational best practices. The aim was to give each team a single, reliable source of truth:

• Support gained standardized explanations.
• Onboarding gained a coherent training sequence.
• Engineering gained insight into user-facing expectations.
• Sales gained clarity on what the system actually delivered.

Because the company lacked a formal documentation platform, I worked with engineering leadership to introduce a lightweight “Help” entry point within the application, allowing the manual to be surfaced directly to users and internal teams. This created the organization’s first accessible, authoritative reference for how the product was meant to be used.

The result was a documentation foundation that reduced unnecessary support load, aligned expectations across departments, and brought the system’s intended behavior back into view, and could be easily ported into future, more flexible content management tools.

Outcomes

The work produced several meaningful outcomes:

• It reduced avoidable support volume by giving agents a reliable reference for common workflows and edge cases.
• It brought onboarding, support, engineering, and sales into closer alignment by grounding each team’s explanations in the same set of standards.
• It clarified the system’s intended behavior, allowing engineers to reconnect with user-facing logic and reducing ambiguity in product conversations.
• It improved the accuracy of sales commitments by giving reps a definitive source for what the platform actually supported.
• It provided the organization with its first canonical reference for the product — a foundation that stabilized day-to-day operations.

When the company eventually adopted Confluence, the manual migrated cleanly into the new environment. Because the content had been designed with structure and consistency in mind, it became the backbone of the company’s first true documentation platform, giving new employees ready access to the tools that had previously lived in improvised form.