Designing the Morning: Fixing Distribution Intake from the Inside
Self-initiated concept · Figma, Claude Code, Cursor · All data fabricated
Ten of us on a retirement plan administration team process ~100 401(k) distribution requests a day, one carrier each, against a two-day timeline. I run this workflow every morning — so I mapped where it breaks and designed a better version.
100+
Requests
2 days
Processing Time
The Current Workflow
Each person runs a script that clicks through their carrier’s portal and exports requests to Excel. Everyone emails their file into a chain; one person consolidates all ten and keys each request into PensionPro, our system of record.
Where it Breaks
Script failures are invisible. They stall mid-clickthrough and fail silently — someone just notices a file never arrived.
Aggregation runs through one person. Ten streams, one email chain, one consolidator — a bottleneck and a single point of failure.
Errors surface too late. Duplicates aren’t caught until PensionPro rejects an entry.
The pattern: people are doing the work the system should do — aggregating, catching errors, noticing failures.
The Constraint I Can’t Design Away
The deepest fix is upstream — data feeds instead of scripts clicking through portals — but that’s a vendor-and-engineering problem, not a design one. So I scoped to the layer I can design: the surface between the scripts and PensionPro.
The Intake Dashboard
The deepest fix is upstream — data feeds instead of scripts clicking through portals — but that’s a vendor-and-engineering problem, not a design one. So I scoped to the layer I can design: the surface between the scripts and PensionPro.
AN ALL IN ONE DASHBOARD
What This Doesn’t Solve
It removes the email relay and surfaces failures — but it doesn’t eliminate manual PensionPro entry, and live aggregation assumes the scripts feed a shared store rather than emailing files. The open question: where’s the line between a useful intake layer and rebuilding a tool the team already pays for? Knowing that line is the job.
What It Reflects
The failures that hurt most in operational software aren’t UI problems — they’re visibility problems. The job isn’t prettier screens; it’s to stop making people be the system’s error-detection layer.
Designing the Morning: Fixing Distribution Intake from the Inside
Designing the Morning: Fixing Distribution Intake from the Inside
Self-initiated concept · Figma, Claude Code, Cursor · All data fabricated
Ten of us on a retirement plan administration team process ~100 401(k) distribution requests a day, one carrier each, against a two-day timeline. I run this workflow every morning — so I mapped where it breaks and designed a better version.
100+
Requests
2 days
Processing Time
100+
Requests
2 days
Processing Time
The Current Workflow
Each person runs a script that clicks through their carrier’s portal and exports requests to Excel. Everyone emails their file into a chain; one person consolidates all ten and keys each request into PensionPro, our system of record.
The Current Workflow
Each person runs a script that clicks through their carrier’s portal and exports requests to Excel. Everyone emails their file into a chain; one person consolidates all ten and keys each request into PensionPro, our system of record.
Where it Breaks
Script failures are invisible. They stall mid-clickthrough and fail silently — someone just notices a file never arrived.
Aggregation runs through one person. Ten streams, one email chain, one consolidator — a bottleneck and a single point of failure.
Errors surface too late. Duplicates aren’t caught until PensionPro rejects an entry.
The pattern: people are doing the work the system should do — aggregating, catching errors, noticing failures.
The Constraint I Can't Design Away
The deepest fix is upstream — data feeds instead of scripts clicking through portals — but that’s a vendor-and-engineering problem, not a design one. So I scoped to the layer I can design: the surface between the scripts and PensionPro.
The Intake Dashboard
The deepest fix is upstream — data feeds instead of scripts clicking through portals — but that’s a vendor-and-engineering problem, not a design one. So I scoped to the layer I can design: the surface between the scripts and PensionPro.
AN ALL IN ONE DASHBOARD
What This Doesn't Solve
It removes the email relay and surfaces failures — but it doesn’t eliminate manual PensionPro entry, and live aggregation assumes the scripts feed a shared store rather than emailing files. The open question: where’s the line between a useful intake layer and rebuilding a tool the team already pays for? Knowing that line is the job.
What It Reflects
The failures that hurt most in operational software aren’t UI problems — they’re visibility problems. The job isn’t prettier screens; it’s to stop making people be the system’s error-detection layer.
Where it Breaks
Script failures are invisible. They stall mid-clickthrough and fail silently — someone just notices a file never arrived.
Aggregation runs through one person. Ten streams, one email chain, one consolidator — a bottleneck and a single point of failure.
Errors surface too late. Duplicates aren’t caught until PensionPro rejects an entry.
The pattern: people are doing the work the system should do — aggregating, catching errors, noticing failures.
The Constraint I Can’t Design Away
The deepest fix is upstream — data feeds instead of scripts clicking through portals — but that’s a vendor-and-engineering problem, not a design one. So I scoped to the layer I can design: the surface between the scripts and PensionPro.
The Intake Dashboard
One shared queue replaces the relay — the whole team sees the same live picture instead of truth scattered across ten inboxes. A status rail shows every carrier’s script state; a failure shows red the moment it happens. Duplicates are flagged at intake, not at the end. Status is deliberately binary — in PensionPro or not — the only thing that ultimately matters. A “Ran by” column shows who pulled each carrier, since assignment itself happens downstream in PensionPro. And when data needs to leave the tool, export is logged — a trail instead of an untracked loose file.
AN ALL IN ONE DASHBOARD
What This Doesn’t Solve
It removes the email relay and surfaces failures — but it doesn’t eliminate manual PensionPro entry, and live aggregation assumes the scripts feed a shared store rather than emailing files. The open question: where’s the line between a useful intake layer and rebuilding a tool the team already pays for? Knowing that line is the job.
What it reflects
The failures that hurt most in operational software aren’t UI problems — they’re visibility problems. The job isn’t prettier screens; it’s to stop making people be the system’s error-detection layer.