Re-architecting how a talent marketplace tracks time

Operations were running on spreadsheets, portals, and people

Across the company's operational teams, three truths kept surfacing: spreadsheets were the real operating system, portals were just submission mechanisms, and people were the integration layer holding it all together. Time tracking sat at the center of that — feeding invoicing, client reporting, and revenue.

The weekly time-tracking cycle consumed hours of manual work, depended on knowledge that lived in individual people's heads, and required synchronous handoffs between teams just to reconcile the same underlying data. It worked — but it didn't scale, and it was fragile.

One dataset, four teams, and no shared source of truth

• A long, manual weekly cycle. A multi-step process repeated every week, measured in hours, with high-severity pain points and no standardization between team leads.
• Fragmented inputs. Multiple portals and operating spreadsheets, each with its own quirks, none talking to the others.
• People as the integration layer. Cross-team handoffs were synchronous — they required both sides available at the same time, and reconciliation lived in meetings and memory rather than systems.

A four-stream audit before any solution

I ran a structured audit across the four teams that touch time data — operations, client experience, finance, and the cross-team handoffs between them — documenting every workflow, pain point, and edge case. Grounding the findings in real day-in-the-life stories made the abstraction legible to leadership and surfaced the requirements that a tool would actually have to meet.

One data layer, four role-specific views

The synthesis was a single operating model: every input flows into one shared data layer, and each team reads from it through a view built for the question they own — then automated outputs replace the manual reconciliation that used to happen in meetings.

A rigorous build-vs-buy decision, not a gut call

With requirements in hand, I built a scoring model of 87 must-have and nice-to-have requirements across 12 candidate tools, then ran a build-vs-buy analysis weighing a configured platform against a custom build on cost and time-to-value. A short list of tools cleared the must-have threshold, and the analysis pointed clearly toward buy — giving leadership a defensible, numbers-backed recommendation rather than a preference.

A phased plan designed for adoption, not just delivery

• Five phases, sequenced for momentum. Quick wins on the existing tool start immediately while vendor selection runs in parallel; a pilot with a subset of users precedes full cutover; the revenue layer waits until the core has earned a full quarter of production trust.
• Four change-management pillars — sponsorship, training, communication, and support — each with a named owner, because the audit only pays off if adoption is real.
• Explicit decision gates. Each phase advances only through a gate with a named decision-owner, so the organization never drifts into commitments it didn't consciously make.

Taken to leadership — and approved

I ran the leadership review with the company's operating executives, walked them through the findings and the proposed rollout, surfaced concerns early, and left with explicit approval to proceed to vendor evaluation, along with confirmed commitments from each team lead and named owners for the change-management pillars.

Note: this initiative is in active rollout — discovery, architecture, and the decision are complete; efficiency figures are validated targets, not yet realized results.