The Best Onboarding Team in the Building Was Drowning in Busywork

Role: Lead Product Designer · Company: Sprout Solutions (HRIS) · Timeline: 3 months (prototype + validation) · Team: 1 PM, 1 Designer, 2 Engineers, and the entire implementation team as our research subjects

Here's an uncomfortable thing to discover about a team everyone loves: they're brilliant, clients rate them 9 out of 10, and they're being quietly buried alive by their own process.

Sprout's implementation team is the part of the company that takes a freshly-signed client and turns "we bought payroll software" into "payroll actually ran correctly this month." They're consultants, translators, and therapists rolled into one. And on a 150-day enterprise onboarding, they'll spend 300 to 350 hours per client doing it.

The gut-punch stat: only 15–20% of that time is the high-skill work they're actually exceptional at. The rest is parsing documents, validating spreadsheets, and reconciling attendance numbers cell by cell by cell.

Sprout's implementation team is its biggest onboarding strength. The process they operate within is its biggest constraint.

That sentence became the whole project. We weren't here to replace the team. We were here to give the busywork to something else.

Context: What "Implementation" Actually Means

When a company buys an HRIS, they don't get a product. They get a project.

Every client has its own payroll policies—overtime rules, 13th-month formulas, night-differential math, holiday stacking, government deductions—and almost none of it is standardized. A Payroll Systems Implementer (PSI) has to extract those policies out of half-finished documents, translate them into system configuration, run test payrolls, and explain—politely, repeatedly—why the client's beloved bi-weekly schedule has no tax table in Philippine law.

It's genuinely hard, judgment-heavy work. The problem was never the team. It was that the hard work was buried under hours of work that wasn't hard at all—just tedious, manual, and unforgiving of a single typo.

The Problem: Expertise Trapped Under Admin

When we shadowed the team, three problems kept surfacing—and they compounded each other.

The throughline: the team's expertise was real, but it was trapped—stuck in people's heads, and stuck under a pile of manual work that didn't need a human at all.

The Bet: Agents Do the 80%, Experts Keep the Judgment

The temptation with AI is to aim it at the hard, glamorous part—"let the agent decide the policy!" That's exactly backwards, and it's how you lose a team's trust in a week.

So we drew a hard line:

Agents do the work that's tedious but mechanical. Humans keep every decision that needs judgment.

Concretely, that meant agents would parse, extract, compare, and flag—then hand a human a clean, pre-digested starting point. The implementer still makes every call. They just don't start from a blank document and a cold spreadsheet anymore.

To prove the bet, we prototyped the two workflows with the worst time-to-value ratio: document intake and timekeeping variance. Both are live below—not screenshots. Real prototypes you can drive.

Tool One: Catching the Landmines Before the Meeting

Every payroll implementation starts with three documents:

• BIR 2303 — the government tax registration certificate (legal entity, TIN, RDO code)
• IRD — the Implementation Requirements Document, filled out by Sales, holding 40+ policy fields
• SOW — the signed Statement of Work (modules, headcount, entities, go-live date, payroll frequency)

Today, a senior PSI reads all three by hand—2 to 3 hours per client—looking for landmines. Things like a bi-weekly payroll frequency (no Philippine tax table exists for it—must go back to Sales) or a fiscal-year 13th month (not a blocker, but you'd better raise it at the meeting).

The skill of spotting those is exactly the expertise that lives in 3–4 heads. So we encoded it. The agent parses the documents, then runs every extracted policy through an escalation decision tree: return to Sales, flag for the kick-off, or proceed.

Try it. Drop the three documents in, run the extraction, and watch the agent work through them.

The point isn't the typewriter animation (though I'm fond of it). It's the line at the end: 40 fields captured · 3 items need clarification. The implementer didn't read three PDFs. They got a triaged list of the three things that actually need a human—before they ever walked into the room.

The Policy Prep Tool converts senior PSI judgment into a team asset. Today, that escalation-detection skill lives in 3–4 people. The tool encodes that logic—so every implementer, regardless of experience, catches what only seniors catch today.

That's the whole thesis in one feature: expertise, un-trapped.

Tool Two: Reconciling Two Spreadsheets Nobody Wants to Reconcile

Later in the project comes the parallel run—where the client runs payroll on Sprout alongside their old system to make sure the numbers match before going live.

The first thing to check is attendance. Sprout computes attendance from raw punches; the client has their own manual report. The two must agree, because every unresolved timekeeping variance becomes a payroll variance. Reconciling them means matching mismatched column names, comparing across 30+ attendance dimensions, and triaging every discrepancy to a root cause.

It takes about 4 hours per company, per run. An enterprise client with four sub-companies runs it six times. That's ~96 hours of spreadsheet diffing on attendance alone.

So the agent does the diff. Upload the Sprout file and the client's raw file, and it matches employees, compares every cell, and groups what's left by severity—material variances first, rounding noise last.

Try it. Drop in both reports and run the analysis.

Notice what it doesn't do: it doesn't edit anything or pretend to resolve the variances. It hands back a color-coded Excel with three sheets side by side and a blunt verdict—11 variances to review, 6 of them blocking. Excel stays the editor, because that's where implementers already live. The agent just makes sure they walk into the variance meeting already knowing where the bodies are buried.

Why This Wasn't an AI Project

It's tempting to file this under "we added AI." But the hard part was never the model. It was the domain.

Knowing that bi-weekly payroll is a hard blocker but fiscal-year 13th month is just a flag. Knowing that a missing employee in the client file is worse than a two-peso rounding difference. Knowing that implementers want a triaged list, not an autonomous decision. None of that comes from a prompt—it comes from sitting with the team and learning the work.

The design system scaled the UI. Product knowledge scaled the judgment we encoded into the agents.

The agents are only as good as the escalation rules behind them, and those rules are senior implementers' instincts written down for the first time.

What Success Looked Like

This is a prototype in validation, not a shipped product with a quarter of funnel data—so I'm not going to wave fake percentages around. Instead, before building anything, I defined what a win would actually mean, and pressure-tested the prototypes against it:

• Walk in prepared, every time. A junior PSI should catch the same pre-meeting landmines a senior catches—because the tool catches them, not their memory.
• Hours back, not minutes. The 2–3 hours of manual document review and the ~4 hours per variance run are the target. Those are real numbers from real shadowing, and they're where the time goes.
• Agents assist, never decide. Every prototype hands the human a clean starting point and stops. The moment it tried to resolve a variance instead of surface it, we'd have lost the team.
• Quality must not regress. The team's 9/10 client scores are sacred. Saving time is only a win if the work stays as good—or gets better because nobody's exhausted by busywork.

The real bar wasn't "automate the team." It was give them their expertise back—pull it out of the busywork and out of the four heads it's trapped in.

What I'd Do Differently

I'd put the ugliest possible documents in front of the intake tool on day one. Our prototypes shine on clean inputs—a tidy IRD, a well-formed Excel export. But the real world ships smudged PDF scans from biometric devices, columns named OT_FINAL_v3_USE_THIS, and sub-companies with policies that contradict the parent. The agents earn their keep on those days, not the clean ones. Next time I start with the worst file on the drive, not the demo file.

Key Takeaways

1. Point AI at the busywork, not the judgment. The fastest way to lose a team is to automate the part they're proud of.
2. Encoding expertise is a product, not a side effect. The escalation rules are the feature.
3. Domain knowledge is the moat. Anyone can call a model; almost no one knows that bi-weekly payroll has no tax table.
4. "Hand back a clean starting point and stop" is a surprisingly powerful interaction model for agentic tools.

The best thing this project could do was make itself invisible—so the team that everyone already rated 9 out of 10 could spend all their time on the work that earned the 9, and none of it on the work that didn't.