Every system I build is designed to detect|catch|catch something before it becomes a problem.

New hires faced 224 tasks — and didn't touch real work for a month.

Every project on our team was a peer review cycle, and running one took 224 tasks from kickoff to the final handoff to the client. Those tasks were split by role: some belonged to Team Leads, others to Project Support Specialists.

New hires learned all of it through lectures and the project task list in Asana. They wouldn't see their first real work task until about a month in — and when they did, it felt like starting from scratch. Reaching full competency took 60 to 90+ days, with heavy errors along the way. On a remote team, that stretch was also isolating.

The knowledge existed. The path through it didn't.

Onboarding was a lecture and a task list — no phases, no practice, no one checking in.

• No structure. 224 tasks were presented as one long list, not broken into the phases people actually work in.
• No practice. Hires listened to lectures but never used the systems until real work arrived weeks later.
• No personalized help. Nobody reviewed a new hire's work until it was live — which is where the errors surfaced.
• No connection. Remote hires learned alone and didn't get to know the wider team.

Five phases, each ending in the real system.

I architected a two-week onboarding program that split the 224 tasks into the five phases of a peer review project. Every phase followed the same loop: an interactive lecture deck, then the system used in that phase, then a hands-on assignment built on practice data, then personal feedback. Hires worked with real project work during the program, so by day 30 they could simply build a project.

Built for the role, paced for retention

Tasks were assigned by role level, so the program followed the same split: Team Leads and Project Support Specialists each practiced the tasks they would own. Practice data covered the work people found hardest — reviewer onboarding, stakeholder communication, reports, and data analysis.

How I built it

1. 01Map the work

   Broke the 224 tasks into the five phases of a peer review project, split by role.

2. 02Build the materials

   Interactive lecture decks, practice data, and a hands-on assignment for every phase.

3. 03Plan with Operations

   Co-developed the two-week schedule and which teammate would lead each session.

4. 04Run and adjust

   Delivered the first cohort, then rebuilt the dry lectures into two-way sessions.

5. 05Hand it off

   Trained managers to run it through mini train-the-trainer sessions.

I deliberately held the program at two weeks. Not an accelerated sprint, and not a drawn-out course: two focused weeks, then time to keep working through the materials, so people felt genuinely confident by the end of the first month. I co-developed the schedule and trainer assignments with the Operations team.

Every lecture was followed by practice — and every practice was reviewed.

This is the program's actual two-week structure, recreated with every name, system, and organization detail removed. Three tiers built on each other — basics, then tools, then the phase-by-phase modules — and sessions were led by more than a dozen different teammates, so new hires met the whole team.

Recreated from the program's real schedule; condensed, with all names, internal system names, and organization details removed.

Built to be interacted with, not read.

The original lectures were dry. These recreations show how I rebuilt them as enterprise-system training: animated walkthroughs of the live systems, then a slide that asks the new hire to do something — answer a question, spot what's missing, or stop and practice.

Recreated from the original training decks — logos, slide template, client, organization, and internal system names removed.

Onboarding a team onto a system is the same job as onboarding a client.

The audience was internal, but every design choice maps directly to how a client gets implemented onto a new platform:

The lectures were dry, so I made them two-way.

The first version of the lectures carried the same problem as the old onboarding: people were listening, not doing. I rebuilt them around interaction between trainees and trainers, so every lecture led straight into questions, the system, and an assignment.

The real test was each new hire's first unassisted task. It went through without a hitch or with only minimal feedback, and my manager confirmed that hires had reached full competency within 30 days. Fewer errors were caught in review, and fewer questions came up once people were live.

Still the standard today — and it runs without me.

I built the lectures and the program, then handed delivery to the operations managers through mini train-the-trainer sessions, and kept giving feedback using the same lectures and practice data. More than 20 hires have come through it, it is still how new team members are onboarded today, and the framework was adopted across the organization.

The effect reached our clients too: the team went on to earn very high customer satisfaction evaluation scores.

In capacity terms, each hire became productive roughly 30–60+ days sooner than before. Across 20+ hires, that's an estimated 600–1,200+ days of productive work the team got back — without adding headcount.

She also has played a lead role in our new staff training programs and overall led her team to perform at a high level resulting in very high customer satisfaction evaluation scores and very high level of quality based on our quality key performance indicators.Program Manager, PMP · managed Abitha directly

A team of 12 was losing 30 minutes per case to logic no document could hold

As the senior project manager overseeing a team of 12 project support specialists, I watched them navigate a three-system enrollment process every day across 10+ programs. A new security decision created 480 possible status combinations across those systems, and nobody had built anything to help staff interpret them.

Staff had to open three systems, read each status, mentally calculate how they interacted, decide what the user needed, and send the right email in the right order — every single case, every single day. I was fielding roughly 20 interruptions a day. Staff were frustrated, users were waiting, and the work wasn't getting done.

It was not a knowledge problem. It was a system design problem that nobody had built a solution for yet.

340 of 480 combinations were invalid — and staff couldn't tell which.

Staff were being asked to interpret logic instead of being guided through it, and the order of operations changed with every combination — for example, one status pairing meant work System 1 first, while a different pairing meant work System 2 first and leave System 1 alone. A static reference document couldn't hold that kind of hierarchy.

340 of the 480 combinations were invalid states where the systems didn't harmonize and the helpdesk had to intervene. Staff had no way to know which was which, which meant constant interruptions, inconsistent guidance, and avoidable escalations.

A form, not a table

I proposed the solution to my manager before building anything, got approval, and researched every status in every system row by row. Manually checking all 480 combinations by hand would have taken weeks on its own, so I used ChatGPT to help reason through the logic and narrow down which combinations were actually valid, and to draft the Excel formulas that powered the matrix — without exposing confidential data. I built and verified the full 480-combination master matrix myself over a few weeks.

Then I designed the interface like a form instead of a spreadsheet: staff select statuses from dropdowns, and the tool instantly shows what the combination means, what staff need to do, and what the user needs to do — color-coded by urgency. For invalid combinations, it returns a clear error: invalid, contact helpdesk. No more guessing.

One deliberate choice: the tool tells staff which email template to use but doesn't auto-fill or send it. I wanted staff to read and understand what they were sending — a staff member who understands the email is a better advocate than one who just clicks send.

Two moments proved the safeguard, not just the build

Both moments came back to the same principle: an automated "invalid" flag is only trustworthy if someone keeps the underlying logic current. The tool doesn't maintain itself — I do.

Still in use today, and it runs without its builder in the room.

The tool is still in active use today, updated as systems change, and remains the single source of truth for every status combination in the organization. A built-in instructions tab, the dropdown structure, and documented logic mean any team member can operate it without the original builder present — a deliberate architectural choice.

It's not possible to overstate what a game-changer this has been for us. Saves frustration, reduces wasted time, and reduces errors.Direct manager, on awarding a 2025 Spot Award for Innovation

Volunteers were losing their own time to a system nobody had measured

The users in this story weren't employees. They were volunteer peer reviewers, reading applications in whatever free time they could find around full-time jobs and families. When the review system launched, it wasn't intuitive — files were hard to find, navigation was clunky, and every minute spent fighting the system was a minute stolen from actually reading the application in front of them. That mattered beyond convenience: a tired reviewer with less time is a reviewer more likely to rush, and a rushed review is how the wrong application gets funded instead of the right one.

Their time was precious. The system was wasting it. And nobody had measured how much.

The organization was already collecting survey data after every review cycle, and users left detailed comments — but the report sent to leadership was a raw list of helpdesk ticket counts and an unprocessed dump of feedback. No categories, no patterns, no recommendations.

The #1 complaint sat uncounted for years — 179 people asked for the same thing.

The gap wasn't a data gap — the data existed. The gap was analytical. In one fiscal year alone, 900+ responses came in across program offices: roughly 300 navigation issues, 200 troubleshooting issues, 100 system accessibility issues, and 250+ with no criticism at all. The single most common complaint across all offices — a faster, simpler way to retrieve assigned files — was flagged by 179 respondents, but it had sat in a raw comment list, uncounted, for years.

Leadership was making system-improvement decisions without knowing what was actually broken or how many people were experiencing it.

Click a category to see what it meant.

A categorization framework held constant for four years

I proposed the initiative to my manager on my own initiative, then put every survey response into a single spreadsheet column and read each one manually, tagging it by hand into a small set of recurring findings. I tested multiple categorization structures before landing on three that held across all the data — navigation, troubleshooting, and system accessibility — and built individual pie charts per program office plus a combined totals analysis, with a recommendations list drawn directly from the highest-volume comments.

I kept the exact same framework from 2021 through 2024 so the data stayed comparable year over year, then documented and handed the template to my direct reports to maintain going forward. I also tracked something most analysts wouldn't think to measure: positive sentiment. In 2021, roughly 10% of comments held no criticism at all; by 2024 that had grown to 30%.

I had built a longitudinal proof of impact without anyone asking me to.

The top request shipped in 2024 as a one-click Download All button.

I presented the findings directly to leadership as evidence: this was end users' top request, and it was costing reviewers real time every cycle. In 2024, the client shipped a one-click Download All button — replacing the one-file-at-a-time downloads reviewers had been stuck with since launch.

The categorization template I built in 2021 is still in use today, maintained by my direct reports. It was designed to be replicable — documented clearly enough that anyone could run it, and consistent enough that four years of data remain comparable. That initiative made the organization look good in front of its stakeholders, and gave volunteer reviewers something they'd never had before: proof that someone was measuring what the system was costing them.

I don't wait to be handed a problem. I find the gap. I build the solution. And I make sure the people who have to live with the results are better off than they were before.

A miscategorized application could mean an organization went unfunded

My team ran application screening cycles across 30 or more programs. After each cycle, two reports had to match: one showing statuses before screening, one after. When they didn't match, an application had been miscategorized — and a miscategorized application could go unfunded entirely.

The human cost of bad data in grant management is not abstract. It is an organization that does not receive funding it deserved.

When a mismatch reached a stakeholder uncaught, the helpdesk had to manually fix the coding — days of correction work, during which the application sat in the wrong place and the applying organization had no idea.

Detection depended on a busy person being perfectly consistent.

Before the pipeline, every comparison was done manually: copy-paste, conditional formatting by hand, thousands of cells scanned visually — about an hour per program, per cycle, across 30 programs. The process was broken at the detection stage, because it depended on the person reviewing being thorough, unrushed, and consistent. Those are human qualities that vary.

A pipeline does not vary.

Automated detection, deliberately manual correction

Before any build began, I authored detailed multi-page validation procedures with screenshots, specifying exactly which columns to compare, which reports to match, and what a flagged mismatch should look like. I designed and directed a Power Query dashboard — I owned the architecture, and a direct report with stronger Power Query execution skills built it.

The structure has three parts: a pre-screening report, a post-screening report, and a comparative reference tab. When the query runs, it flags every mismatch as a red cell, and a separate tab shows exactly which application, which field, and which value changed — telling me precisely what to correct manually in the source system.

I kept the paste step deliberately manual, so the person running validation engages with the data before the tool processes it.

Comprehension was more important to me than full automation.

The first real catch was an application in the wrong funding category.

The first real mismatch the dashboard caught was an application that had moved from one funding category to another incorrectly. Without the flag, it may not have been funded at all. The pipeline caught it; the correction was made; the application went to the right place.

The tool is mission-critical enough that rebuilding it, if ever needed, is on my own task list — and because I wrote the procedure document before the build began, I can rebuild it from scratch without starting over, and any future team member could too.

Delegation is not the absence of skill. It is the presence of judgment.

I've been the client in this story.

When my organization replaced Microsoft Access with Asana, I worked directly with the Asana team to fit the tool into our project cycle. They didn't start by configuring anything. They started by asking how we ran projects — and through that discovery, we could see clearly how Asana would fit the company.

This lab rebuilds that experience from the other side of the table. I play the implementation consultant, rolling out Asana while running the rollout inside Asana.

Discovery comes first. The tool comes second.

Handoffs lose details, and plans get built on guesses.

• The handoff leaks. The move from sales to implementation is a common pain point where details get lost.
• Onboarding starts with unknowns. It happens after the sale, so many intake answers are still “not sure.” A plan built on those gaps looks finished but isn't.
• Speed can cost trust. AI can draft a plan and an email in seconds, but one wrong message to a brand-new client damages the relationship.

The goal: take a client from Closed Won to a kickoff-ready plan quickly, without losing the human judgment.

Two workflows, one hidden form field, two human reviews.

Both workflows run in n8n every 15 minutes. Step 1 starts when a deal reaches Closed Won and ends when the welcome email is sent. Step 2 starts when the client submits the intake form and ends when the kickoff or discovery email is sent. Status fields on the deal and the contact make sure each client is handled exactly once.

Human decision point — nothing reaches a client without it

The real workflows in n8n

Click any screenshot to enlarge it.

The stack

Every tool ran on a free plan or an existing account; each test run cost a few cents of Claude API usage. I started on Gemini and swapped to Claude without changing any business logic.

How I built it

1. 01Design the process

   Discovery form, PMBOK plan shape, train-the-trainer model, and a draft-only email rule.

2. 02Build the planning flow

   Wired HubSpot, Claude and Asana, then fixed each error until the first full plan came through.

3. 03Improve the outputs

   Capped emails at 3 questions, added a real kickoff date, and moved every question into Asana.

4. 04Build the sales handoff

   Closed Won trigger, intake form with a hidden field, and an automatic handoff to Step 2.

5. 05Test and document

   Four more clients across all three paths, clear workflow names, and notes inside each workflow.

I went step by step on purpose, learning each piece before moving on and testing one client at a time, with Claude as my build partner.

Three touchpoints, each one reviewed first.

From the client's side, onboarding is a warm welcome, a 10-minute form where “not sure” is a good answer, and a kickoff email built from their own words. Here's that journey for Brightpath Youth Alliance, the yellow client.

Test addresses in the form are redacted. Brightpath's draft still shows a robot-style date (2027-02-15) — the repeat catch that's next on the rules list.

Green gets a plan. Red gets a conversation.

Claude rates every intake before planning anything, and gives a reason. The rating decides what the client receives, so the system never builds a full plan on guesses.

What Lumen Creative Agency got in Asana.

Lumen rated green: a complete intake for moving 30 users from Trello and spreadsheets into Asana. Without anyone touching Asana, the workflow built the whole project — and the kickoff task carries every open question, so nothing lives only in email.

What Oakline Logistics got instead.

Oakline's intake came back almost entirely “not sure,” so the system didn't pretend to plan an implementation. It built only the Initiating phase, scheduled a discovery call, and drafted a warm invitation with three questions to think about first.

Five fictional clients, five fitting outcomes.

I wrote five realistic clients and ran each one end to end, playing sales, the client and the reviewer. Pick a client to see what the system produced and what my review caught.

All clients, contacts and companies are fictional. Test emails were routed to my own inbox.

Nothing reaches a client until a person presses Send.

The AI prepares and a human decides. These design choices are what make the speed safe to use with real clients:

The review packet

Every run emails me a review packet before anything goes to the client: a client snapshot, the readiness rating with its reason, flags to check, the questions sent and still open, the assumptions the AI made, and my review steps in order — HubSpot, then Asana, then the email.

How review made the AI better

Ten real build problems, each traced to a root cause.

1. 01HubSpot blocked new fields at “11 out of 10”The free plan allows 10 custom properties and HubSpot had auto-created 2. I archived those and consolidated 20 intake fields into 10.Working within platform limits
2. 02Claude node failed: “API key is invalid”The stored credential was out of date. I created a fresh key and updated it in n8n.Credential management
3. 03Asana rejected tasksThe task API needs the workspace even when a section is given. I added the workspace ID to every request.Reading API errors
4. 04Asana returned “too many requests”Ten tasks sent at once hit the rate limit. I sent one request every 0.7 seconds with 3 automatic retries.Rate limits and throttling
5. 05Phases appeared out of orderSections were created in parallel. I created them one at a time.Order of operations
6. 06Plans cut off mid-answerClaude hit its output limit. I raised it to 16,000 tokens and tightened the plan rules.Token limits and prompt design
7. 07HubSpot sign-in blocked in HTTP nodesn8n's managed HubSpot sign-in only works in native nodes. I swapped 3 raw API calls for native HubSpot nodes.Connector versus direct API
8. 08The form showed the last client's detailsA HubSpot tracking cookie remembered the last visitor. I tested each client in a fresh incognito window.QA and browser behavior
9. 09A discovery call landed 7 weeks outA 90-day fallback pushed every date late. Plans now anchor to today when go-live is missing.Logic review from test results
10. 10A pilot scheduled on Christmas DayThe AI's date planning ignored holidays. I added a rule to avoid weekends and major holidays.Human review improving the AI

Direct API calls where they fit, native connectors where they didn't.

I built the Asana project through its REST API with HTTP Request nodes, throttled with retries. For HubSpot, I first configured raw calls, then switched to native nodes when n8n's managed sign-in required it.

Every POST sent a JSON body — for example, {"data": {"name": "Planning"}} to create a section. Credentials live only in n8n's credential manager.

It works end to end, and it keeps getting better.

The system runs today from a Closed Won deal to a reviewed kickoff plan. Each of the five test clients received a different, fitting outcome: green clients got full plans, the yellow client got a plan with six labeled assumptions, and red clients got a discovery call within a week. HubSpot's timeline shows the whole journey for each client — contact created, deal won, form viewed, form submitted, plan drafted.

Every repeated review edit became a rule, so the next client's draft needs fewer of them.

Mapped to the PMI-CPMAI methodology

1. I–IIBusiness & data

   Defined the problem, success criteria and the human review requirement, and what client data HubSpot holds.

2. IIIData preparation

   Consolidated 20 fields into 10 properties and built clean client briefs.

3. IVModel development

   Wrote the prompts, rules and structured JSON outputs for Claude.

4. VEvaluation

   Tested 5 clients across green, yellow and red paths and reviewed every output.

5. VIOperationalization

   Scheduled workflows, handled-once markers, and a feedback loop from review to rules.