Diwang Malaya

From Manual Lead Tracking to a Revenue Operations System

Confidential Coaching Client · CRM Architecture · Revenue Operations · Customer Journey Design

The Challenge

This client ran an established coaching business with multiple offers, a webinar funnel, a mentorship program, and one-on-one sessions. Before any CRM was in place, lead tracking was almost entirely manual. There was no centralized way to see where a lead came from, where they were in the journey, which offer they were considering, what an opportunity was worth, or when a lead had gone quiet. The business had leads. What it lacked was visibility, and a repeatable system for moving those leads forward.

The Problem Beneath the Problem

This wasn’t really a “we need a CRM” problem. It was a “we need the sales process translated into a system” problem. Before building anything, I had to map the full journey, from lead acquisition through warm lead, sales opportunity, customer, and ongoing relationship, including the different paths someone could take depending on which offer they were interested in. That map became the foundation everything else was built on.

My Role

I designed the CRM architecture and revenue operations strategy, then worked alongside a teammate who supported execution. I mapped the customer journey, sales processes, funnels, pipelines, follow-up logic, appointment workflows, and lead-status transitions, then built many of the workflows and system components myself.

What I Built

Product & Service Sales Pipeline
A pipeline built specifically to track sales across the client’s different offers, giving the team visibility into which offer a lead was pursuing, where it stood in the sales process, and its potential value. Instead of looking at a list of contacts, the team could look at the actual revenue sitting inside the pipeline.

Lead Journey Pipeline
A second pipeline focused purely on the lead’s journey, acquired, engaged, opportunity, then won, lost, or abandoned. This separated two things that often get confused: who a person is, versus where they are in the journey, and that distinction gave the business much clearer visibility into what was actually happening with its leads.

Follow-Up System
Likely the most important piece. There was no structured follow-up before this, so I designed workflows that kept leads moving instead of quietly disappearing when they didn’t convert right away. The system also surfaced inactive leads that had been sitting untouched, some of which were re-engaged and converted. This wasn’t just administrative tidiness, it recovered opportunities the business would have otherwise lost.

Appointment & Show-Up Automation
Automated notifications when a lead signed up, when an appointment was booked, and as it approached, plus reminders sent to the lead directly. This made follow-up more consistent and was designed specifically to support better call attendance.

Before and After

Before, tracking was manual, visibility into the journey was limited, there was no structured follow-up, inactive leads could disappear, and appointments relied heavily on manual reminders.

After, the business had a centralized CRM architecture, defined lead and customer journeys, two dedicated pipelines, automated follow-up, and automated reminders, along with far greater visibility into where opportunities were sitting or leaking, and a way to recover leads that had already gone cold.

The Hardest Part

Building the workflows wasn’t the hard part. Understanding the business well enough to know what those workflows actually needed to do was. That meant learning the business logic first, and only then translating it into CRM logic.

What This Demonstrates

CRM Architecture – Designing structures around how a business actually sells and serves customers

Revenue Operations – Connecting acquisition, sales, follow-up, appointments, and conversion into one system

Customer Journey Mapping – Understanding the path before deciding what the technology should do

Automation Design – Identifying where automation can replace inconsistent manual processes

Systems Thinking – Seeing how individual pieces interact as one whole

I don’t start with the CRM. I start by understanding how the business works. Then I build the system around it.

Turning Expertise Into an Experience

Confidential Coaching & Education Client · Content Transformation · Customer Experience · Knowledge Structuring

The Challenge

The client had a large body of valuable material, podcast episodes, coaching conversations, spoken ideas built up over time. The challenge wasn’t a lack of content. It was that good ideas can stay completely passive. Someone listens to a 45-minute episode, thinks “wow, that’s interesting,” and then does nothing with it. The opportunity was turning that material into something that made the audience stop, reflect, and actually apply what they’d just heard.

My Role

I took long-form spoken content and transformed it into structured reflection material that extended the life of the original episodes. Rather than summarizing what the client said, I had to understand the idea underneath it and figure out how that idea could become something the audience actually engaged with, not just consumed.

What I Did

For each piece of content: listen to and understand the original material, identify the central idea or tension underneath it, separate the story or example from the actual lesson, anticipate the questions an audience would naturally have, then develop reflection prompts around those ideas. Those prompts had to be structured for genuine self-examination, not comprehension checks, and refined until the language actually sounded like the client’s own voice and philosophy, not mine.

The result was a bridge: content, to reflection, to self-awareness, to application.

The Interesting Part

Writing questions wasn’t the hard part. Understanding what the client was actually trying to get people to think about was. A good reflection question can’t just repeat the content back, it has to open a door. That meant constantly asking: what’s the deeper idea here, what assumption is being challenged, what might the listener recognize in themselves, what question actually moves someone past passive listening, and how do you preserve someone else’s voice without just copying their words.

Outcome

The client’s existing long-form content became additional customer-facing material without needing an entirely new body of source content. A single podcast episode, instead of being consumed once and forgotten, became an interactive reflection experience, extending its usefulness and giving the audience something more intentional to do with it.

What This Demonstrates

• Content Intelligence — Pulling the important idea out of a large amount of raw material
• Knowledge Translation — Turning spoken expertise into structured written experience
• Customer Experience Design — Thinking about what the audience should do with information, not just what they consume
• Editorial Judgment — Knowing what to preserve, cut, question, or build out further
• Voice & Context — Building material that supports someone else’s framework rather than imposing your own

I don’t just summarize what someone said. I find the idea underneath it and build something the audience can actually use.

From New Client to Clean Handover: Building a Repeatable Client Lifecycle

Confidential Professional Services Client · Client Onboarding · Operations · SOP Design · Project Management · Offboarding

The Challenge

As the company took on clients with different projects, processes, tools, and working preferences, the client experience needed to stay consistent without becoming rigid. The real challenge wasn’t just onboarding a new client, it was building a process that could move someone from signed contract to active project smoothly, capture what the delivery team actually needed, translate scattered conversations into documented workflows, coordinate multiple team members, and eventually hand the client a clear, complete record of what had been delivered.

The Problem Beneath the Problem

Every client comes in with their own way of working. Some already have documented processes. Some have processes that only exist in someone’s head. Some know exactly what they want handled for them, others need help figuring out what can even be taken off their plate. That meant onboarding couldn’t just be “contract, kickoff, project starts.” The team needed a way to actually understand a client’s business before deciding how to support it.

My Role

I designed and managed the onboarding and offboarding process, turning what could have been an ad hoc client experience into a repeatable system. I was the person responsible for initiating the relationship once a client signed on, gathering what delivery needed, coordinating the team, documenting the process, and making sure the client walked away with a complete handover at the end.

What I Built

Structured Client Onboarding
A documented SOP covering everything from signed contract through kickoff, sending and tracking contracts, organizing documents, scheduling the kickoff meeting, gathering brand assets, identifying which processes the client wanted taken over, and introducing them to how the team works. Onboarding wasn’t just intake, it was designed to understand how the client actually operated.

Process Discovery
Most clients don’t have their processes formally written down. So instead of asking for a perfect SOP upfront, I’d walk through their process with them directly, record the conversation, and use that as raw material. From there: what’s actually happening today, where are the gaps, what can the team take over, what’s missing, what could be automated. That turned onboarding into the first stage of process discovery, not just paperwork.

Automated Client Communication
Workflows that automatically sent call recaps, next steps, and relevant onboarding information, cutting down on repetitive manual follow-up while keeping clients in the loop.

Project & Client Management
I helped structure the client workflow across the team’s project management systems, coordinating with other team members so information gathered during onboarding actually made it into delivery, rather than living in a separate silo.

SOPs, Demos & Documentation
Documented workflows and short video demos, so processes didn’t depend on one person remembering how something worked.

Offboarding: Closing the Loop

The process didn’t end at delivery. I built the offboarding process around documentation and accountability, reviewing the original scope, what was actually delivered, and what the client was walking away with, then creating a handover pack with the completed work, screenshots, and links to every relevant asset.

That handover pack mattered more than it might sound. It created a point-in-time record of exactly what the client’s system looked like at handoff. If someone came back months later saying “this isn’t working anymore,” the team had a documented reference to compare against, clarity for the client, and protection for the business.

The Bigger Contribution

What started as onboarding and offboarding became a standardized client lifecycle: signed client, discovery, onboarding, process documentation, delivery, handover, offboarding, reusable across clients instead of reinvented every time. It also created a clean throughline: what the client told us, what the team needed to do, what was delivered, what was handed back.

What This Demonstrates

• Client Lifecycle Design — Mapping the operational journey from signed contract through completion
• Process Discovery — Pulling undocumented knowledge out of conversation and turning it into something usable
• Operations & Implementation — Connecting communication, project management, and delivery into one system
• SOP & Knowledge Management — Turning recurring work into something repeatable
• Automation — Spotting where repetitive steps can be systemized
• Cross-Functional Coordination — Making sure information doesn’t stall at onboarding
• Operational Judgment — Recognizing that sometimes the most valuable thing isn’t another tool, it’s clarity on how the business actually works

I walk into an imperfect process, understand what’s actually happening, and turn it into a system that doesn’t depend on me to keep running.

Turning Purchased Lead Data Into Actionable Sales Intelligence

Confidential B2B Client · Lead Quality Assurance · ICP Validation · Data Operations · AI-Assisted Analysis

The Challenge

The client had an established process for sourcing leads through a long-term freelancer relationship. For each project, she’d request a set number, often around 500, delivered through a spreadsheet, already enriched and matched against an agreed Ideal Customer Profile. But over time, something shifted. The quantity stayed consistent. The quality didn’t. Leads on repeat projects started drifting further from the campaign’s actual target. The real question became: how do we know we’re actually getting what we’re paying for?

The Problem Beneath the Problem

The original workflow assumed that 500 leads delivered meant 500 usable leads. Those aren’t the same thing. A spreadsheet of 500 contacts can quietly include duplicates, companies that don’t fit the campaign, contacts outside the ICP, or data that technically satisfies the brief without being commercially useful. Without a systematic check, all of that slides straight into the marketing system unnoticed. What the client actually needed was a quality-control layer that didn’t exist yet.

My Role

I designed a repeatable lead-audit process to evaluate each batch before it was treated as usable. The goal wasn’t just confirming a contact existed, it was answering a sharper question: does this lead actually make sense for what we’re trying to accomplish?

The Process I Designed

Every new batch went through three questions. Is the lead a duplicate, so the client isn’t paying twice for the same opportunity. Does it fit the ICP criteria the freelancer was given. And does it actually make sense for this specific campaign, since the same lead could be relevant to one campaign and irrelevant to another. That third question mattered most, it turned a basic data check into campaign-specific qualification, not just a box-ticking exercise.

Making the Audit Scalable with AI

Manually reviewing hundreds of leads by hand would have just created a new bottleneck. So I built a custom GPT trained on the campaign context, the client’s objective, the ICP definition, and the validation criteria, with clear instructions for spotting duplicates and ICP misalignment, and a structured output format. I could upload a full lead spreadsheet and get a complete audit back in under an hour, versus a person combing through every record manually. The output broke down which leads were valid, which matched the ICP, which didn’t, which were duplicates, and which needed replacing.

Turning the Audit Into an Action

The point was never an interesting report sitting unused, it was a feedback loop with the lead supplier. If duplicates or off-criteria leads showed up in a batch of 500, the client now had evidence for exactly what needed replacing. Instead of simply accepting “here are your 500 leads,” the conversation became “here’s how many actually meet the criteria, and here’s what needs to be swapped out.”

From Raw Data to Actionable Data

Cleaned data moved into the client’s marketing infrastructure, including Klaviyo, ready to be tracked and used downstream. The transformation, in short: purchased data, quality assurance, ICP validation, clean dataset, into the marketing and sales system. The spreadsheet stopped being just a list of contacts. It became something the team could actually act on.

Outcome

The client gained real visibility into lead quality, a consistent QA process for every new batch, clear identification of duplicates and non-ICP leads, a concrete mechanism for requesting replacements, and a scalable way to audit hundreds of leads without reviewing each one by hand. Most importantly, it introduced a quality-control layer that simply hadn’t existed before.

What This Demonstrates

• Revenue Operations — Understanding that lead generation isn’t finished the moment a spreadsheet arrives
• Data Quality & Governance — Building actual rules for what makes data usable
• ICP & Business Understanding — Judging leads against a real commercial objective, not a generic checklist
• AI Workflow Design — Using AI to speed up repetitive analysis while keeping judgment calls human-defined
• Process Design — Turning a vague concern into something repeatable
• Commercial Judgment — Recognizing the real issue was never the spreadsheet, it was whether value was actually being delivered

I built a quality-control layer between lead acquisition and marketing execution, so the client could verify the data she was paying for actually matched the customers she wanted to reach. I didn’t start with AI. I started with the business problem, and used AI as the mechanism to solve it at scale.

Diagnosing a “Broken” Analytics Setup Before It Became a Bad Business Decision

Confidential B2B SaaS Client · Marketing Analytics Audit · Root Cause Investigation · AI-Assisted Technical Diagnosis · Stakeholder Communication

The Challenge

The client had launched a B2B product and wanted a straightforward health check on its Google Analytics setup, mainly to understand whether the traffic and conversion numbers being reported were actually trustworthy. On the surface, this looked like a routine audit. It became something else entirely: a live investigation into whether an entire month of reported data was real at all.

The Problem Beneath the Problem

The initial review surfaced real, fixable issues: developer test traffic inflating the numbers, no tracking on sign-ups or demo requests, and a sharp, unexplained drop in visits at the start of the month. That alone was enough to justify a fix list. But partway through actioning it, one property suddenly showed zero data across every event type, for multiple consecutive days, including working days. The obvious read was “the tracking broke.” The obvious fix, floated internally, was to redirect the site’s code back to the property everyone had access to. Both of those would have been wrong.

My Role

I led the investigation end to end, from the original audit through to root-causing the data outage and deciding what could safely be fixed versus what needed a human decision first. That included directing an AI browser agent to interrogate the live site and the analytics account directly, rather than relying on assumption or the dashboard’s own explanations, and knowing when to stop trusting a convenient theory and go looking for harder evidence instead.

The Investigation

Rather than accept “no data received” at face value, I used an AI-assisted browser tool to independently interrogate both sides of the problem: what the live website was actually sending, and what the analytics property was actually receiving. Line by line, this ruled out the easy explanations. The cookie consent flow was tested directly and worked correctly. The daily trend data was read manually and cross-checked against the platform’s own totals until it reconciled exactly. Each theory was tested against evidence rather than accepted because it was plausible.

The root cause turned out to be almost invisible from inside the dashboard: the analytics property the team had access to was not the client’s product at all. It was a year-old, unrelated data stream, still holding its original unrelated name until someone reasonably renamed it, assuming it was simply an unlabeled setup that needed tidying up. Nothing in the interface flagged the mismatch. The live product had been reporting correctly the entire time, to a completely different property nobody currently had access to.

Judgment Over the Obvious Fix

This is where AI-assisted investigation mattered most, not for generating the answer, but for stopping a bad one. The instinctive fix, pointing the live site’s tracking code at the property everyone could already see, would have permanently merged the client’s real traffic into an old, unrelated dataset, and would not have recovered a single day of the data actually believed missing. Recognizing that this “fix” would create a second, worse problem, and holding off until the real property owner could be identified, was the difference between a quick patch and a quiet, permanent data loss.

Turning the Investigation Into Action

Once the root cause was confirmed with direct technical evidence rather than inference, the response was sequenced deliberately rather than fired off all at once. The technical lead received a precise, evidence-based request, exactly which property was misconfigured, exactly which identifier the live site was actually using, and exactly what access was needed, with no speculation dressed up as fact. The manager was briefed separately and in more depth, including how the investigation was actually carried out, so she had the full picture before anyone else did. The team member who had unknowingly built the earlier fixes on the wrong property was given a clear, blame-free explanation, since nothing in the platform itself would have warned her, and holding that context accurately mattered as much as solving the technical problem.

Outcome

The investigation prevented an unnecessary “your traffic collapsed” narrative from reaching leadership, and prevented a well-intentioned fix that would have permanently merged the client’s real data into an unrelated dataset. It very likely preserved a full month of otherwise-assumed-lost conversion data, sitting intact once the correct property is accessed. It also surfaced a structural recommendation worth acting on regardless of this incident: as the client’s product portfolio grows, each product needs its own analytics property from the outset, not a shared one that invites exactly this kind of confusion later.

What This Demonstrates

• Root-cause thinking under pressure, treating a scary surface symptom as a question to investigate rather than a fact to react to.
• AI-augmented technical investigation, directing an AI tool to gather direct, verifiable evidence from a live system, rather than accepting either the platform’s alert or the AI’s first answer without cross-checking it.
• Judgment over automation, catching and rejecting an AI-suggested action that looked like a fix but would have caused irreversible harm.
• Stakeholder communication, calibrating what different people needed to know, a developer needing precision, a manager needing full context, a team member needing reassurance, rather than sending one generic update to everyone.
• Composure under ambiguity, resisting the urge to escalate or panic before the actual cause was confirmed with evidence.

UAT Testing for an AI Project Management Platform

Client type: AI-native SaaS platform (confidential)

The brief
I ran a full UAT pass on a new AI agent suite added to a project management platform. The client built a fictional M&A deal scenario, complete with invented companies, financials, and documents, so testers could stress-test every feature without touching real client data.

What I did
I worked through 34 test cases across document handling, chat and citations, task management, and five AI agents (contradiction detection, risk tracking, deadline extraction, decision logging, and briefing summaries). For each, I scored against six dimensions: functionality, output quality, UI/UX, tone, usefulness, and accessibility.

I didn’t just run the happy path. I tested empty inputs, double-clicks, mobile, keyboard-only navigation, offline states, and 10,000-character pastes, and pushed on ambiguous cases (like whether the AI would invent an answer when the source material didn’t cover something).

What I found
11 bugs, ranging from a blocker to cosmetic. A few standouts:

• An AI assistant correctly caught contradictions between source documents that a human reviewer might miss
• One agent silently substituted unrelated real-world data when asked about something outside its scope, a subtle but important trust issue in high-stakes work
• A signup form had no validation, letting a user accidentally expose a password as their display name, with no way to fix it afterward

I also flagged several open questions rather than assuming intent, like whether certain permission restrictions were deliberate design or genuine gaps, and brought those back to the product team for a decision rather than guessing.

Deliverables

• Full scored responses across all 34 test cases
• 11 logged bugs with severity, repro steps, and supporting documentation
• Two chronology reports (Word docs with screenshots) for bugs that needed a clear paper trail
• A summary email distinguishing confirmed bugs from open design questions

Leading a smoke test for an unreleased voice AI app

Client: UK-based AI software company · Product: voice-first AI learning app, pre-launch · Role: UAT lead

The brief

The product team handed us a 192-case UAT pack and asked for a 12-case smoke test before wider testing. The pack was thorough but dense: test catalogue, results workbook, fixture files, severity rules, evidence standards, and strict safety rules around synthetic data.

My role

I led the run end to end. I broke the pack down into what actually mattered for the 12 cases, set up a clean disposable test account, and directed a tester through each case live. Every result went through me before it was recorded. I judged pass or fail against the written criteria, wrote the issue reports, and kept the evidence trail clean.

How I ran it

I read the whole pack before touching the product, which surfaced blockers early: missing accounts, a fixture file we needed, and conflicts between the docs.

I sequenced the tests so nothing would contaminate anything else. The first-run onboarding test went first, while the account was still fresh.

I held a strict line on evidence. Every screenshot was named to the pack’s format, timestamps were converted to UTC, and anything showing personal data was cropped before saving.

When results were messy, I dug instead of guessing. A retake count that didn’t match History, an ambiguous timestamp, a Settings page I’d wrongly flagged: each one was checked against the screen and corrected before it went into the record.

What we found

11 of 12 cases completed. 9 passed, 1 failed, 1 was blocked, and 1 was held pending a seeded account.

Six issues logged: 2 High, 3 Medium, 1 Low.

The most valuable find came from a blocked test. A new account was cut off for exceeding its daily usage allowance, reporting more minutes used than the account had existed. Rather than just logging “limit reached,” I traced the timeline and found abandoned sessions still marked active in the background. That gave the developer a concrete lead instead of a vague bug.

We also found the app was hiding that limit behind a generic “hit a snag, try again” message, which would leave real users retrying for nothing.

What I’d bring to your project

Structured test execution against written criteria. Clear, reproducible bug reports with expected vs actual, severity, and evidence. Careful handling of test data and privacy. And the habit of asking why a number looks wrong, not just recording it.