Pigment + TeamOhana: Why Headcount Plans Need an Execution Layer

In this article
Never miss new content
Pigment is a strong planning system. We’re built to sit next to it.
Pigment has earned its position as one of the strongest FP&A platforms on the market. Its modeling power, scenario planning, and finance-grade rigor are why so many CFO and VP Finance teams choose it. We hear it from prospects directly: when Finance picks a planning system, Pigment is usually on the shortlist, and often the winner.
This post is not a comparison piece. It is the opposite. Pigment is the financial planning system. TeamOhana is the headcount execution layer that sits next to it. The two solve different problems for different teams, and most companies need both.
If your team is evaluating Pigment, already running it, or comparing the FP&A landscape, this is the part of the stack you may not have priced in yet: what happens to the headcount plan after the model is approved.
Planning is finite. Executing the plan is not.
Headcount is the largest single line item in most operating budgets. It typically accounts for 60 to 80 percent of total spend. The plan to fund it gets built carefully: a model in Pigment, scenarios stress-tested, a number signed off by the CFO. Then the plan is approved, and the work shifts.
Approval is where modeling stops and execution begins. From that moment on, the plan is no longer a number. It is a sequence of decisions across four teams. Recruiters opening reqs. Hiring managers extending offers. HR Business Partners flagging comp adjustments. Finance trying to keep score.
Those decisions do not happen in an FP&A tool. They happen in the ATS, the HRIS, Slack threads, hiring trackers, and the spreadsheet someone built on a Friday afternoon. Start dates slip. Backfills open weeks late. Comp comes in three percent over plan. By the time Finance hears about any of it, the model is already out of date.
This is the execution gap. It is not a Pigment failure. Pigment was not built to coordinate hiring across Finance, HR, and Talent. But the gap is real, and the cost of leaving it open is more than a variance line in the model. If engineering hiring slips, the roadmap slips. If sales hiring slips, the revenue number slips. Headcount plans are the lever behind product and revenue commitments, and when execution drifts from the plan, those commitments drift too.
Consider a simple, common scenario. A hiring manager pushes a start date by two weeks. In a model-only environment, Finance has to find out about it, usually from a Slack message or a weekly sync, then identify who owns the change, chase the recruiter or the HRBP, and manually update the model. Two teams, a time lag, and guaranteed drift. Multiply that across twenty active roles and a planning cycle, and the gap between what the model says and what is actually happening compounds quickly.
Where TeamOhana adds depth
TeamOhana is purpose-built for what happens after the plan is approved. The product was designed around three things that matter most when a headcount plan meets the real org.
Structure around every headcount decision. Every role request, backfill, comp change, start date shift, and org move runs through a defined workflow with an owner, a status, and a timestamp. The plan stops being a number in a model and becomes a live, governed process.
Workflows tied to the operating cadence. Recruiters submit changes inside the tool they already use to run hires. Hiring managers approve from the same record. HRBPs and Finance review and confirm in one place. The four teams executing the plan finally work from the same source of truth, not a tracker, a Slack thread, or an email chain.
Bidirectional connectivity with the systems that matter. TeamOhana doesn’t just read from the HRIS and ATS. It writes back. When a recruiter moves a start date, the financial model reflects it. When Finance approves a comp change, the ATS sees it. The reconciliation work that today eats hours each week happens automatically.
The result is an operating layer the rest of the org actually uses, sitting underneath the financial model the Finance team already trusts.
How TeamOhana and Pigment work together
The architecture is simple. Finance continues to model in Pigment. Budgets, headcount assumptions, and long-range forecasts live where Finance built them. Nothing changes about how Pigment is used as a planning system.
TeamOhana activates the moment a plan is approved. Approved roles, budgets, and headcount assumptions flow from Pigment into TeamOhana as the operating plan. From there, every downstream action runs in a structured workflow: role creation, approval routing, opening the requisition in Greenhouse or another ATS through our native integration, offer extension, and start date adjustment. Talent and HR operate inside TeamOhana, in a workflow designed for the way they actually work.
Changes write back. The integration between TeamOhana and Pigment is a purpose-built API connection we have already built with customers. When the operating reality shifts, and it always does, the update flows from TeamOhana into Pigment automatically. And it flows back to the right line item. Every role in TeamOhana carries a unique headcount ID that ties the budgeted line, say "Software Engineer 1," to the actual hire in the ATS, "Sr SW Eng, Billing." No more manually matching plan to roster. Finance sees the new picture in the model they already use, with the right people tied to the right line items, and without chasing anyone for a status.
TeamOhana also handles the scenario modeling that operating teams actually need day to day. Pressure-testing whether a plan is still achievable as conditions change, including recruiting capacity, comp pressure, and ramp time, happens inside TeamOhana on live data, not in a spreadsheet that goes stale the moment it is saved. Pigment owns the long-range financial scenarios. TeamOhana owns the operational scenarios that determine whether the plan can actually be executed.
The same model works alongside Abacum, Anaplan, and the broader FP&A ecosystem. TeamOhana is built to be the execution layer regardless of where the financial model lives. If your stack already runs one of these tools, or you are still deciding between them, TeamOhana does not change that decision. It complements it.
In practice, the before-and-after is simple. Before: Finance maintains a parallel headcount tracker, chases Talent every Monday for updates, reconciles three versions of reality before the weekly business review, and rebuilds the variance story by hand. After: every change happens inside a structured workflow with an owner, the model updates automatically through the API, headcount IDs map each hire to the right budget line, and Finance walks into the same meeting with a current picture and an audit trail behind every decision.
“If we already have Pigment, why would we need TeamOhana?”
This is the most common question we hear, and the answer is straightforward: the two tools were built for different users and different jobs.
Pigment was built for Finance to model, plan, and forecast. It does that exceptionally well. Its target user is a planner: someone who lives in scenarios, assumptions, and models.
TeamOhana was built for the four teams that execute the headcount plan: Recruiting, Hiring Managers, HR Business Partners, and Finance. Its target users are operators: people running hires, approving backfills, and managing the day-to-day workflow that makes the plan real.
This is why simply adding non-Finance users to an FP&A tool rarely works. Pigment's UX was designed for planners, not operators. There is no out-of-the-box way for a hiring manager to view their plan, model a scenario, or approve a role. There are no native approval workflows. There is no integration to Greenhouse or other ATSes to keep the plan current as hires move. All of that has to be configured by a consulting firm before anyone outside Finance can meaningfully use the tool.
Seats run roughly $2,000 to $3,500 per contributor per year, but the real cost is the buildout on top of the licenses. And after all of it, you end up with a worse version of what an execution layer ships out of the box.
Recruiters and hiring managers cannot be productive in a tool that was never designed for them. The org routes around it, usually by reverting to spreadsheets, which is where most headcount plans actually live today
This is not a Pigment failure. Pigment is doing what Pigment was built to do. The mismatch is between an FP&A tool's planner-first design and the operators who actually run the headcount plan day to day. Recruiters and hiring managers do not work in financial models, and asking them to learn one to update a start date is friction the org will route around, usually by reverting to spreadsheets.
TeamOhana removes that friction. Finance keeps modeling in Pigment. Talent and HR operate in a tool built for how they actually work. The model stays accurate because the workflow keeps it that way.
Where this fits: three common scenarios
Companies currently evaluating Pigment. The Pigment decision is about which financial planning system to standardize on. TeamOhana sits beside that decision, not against it. The strongest deployments we see pair the two from day one, with Pigment for planning and TeamOhana for execution, so the operating layer is live when the plan is approved, not nine months later.
Teams already running Pigment that want stronger headcount workflows. Most Pigment customers we talk to are happy with the financial model and looking for more on the execution side. Headcount workflows are typically a phase-two item in any FP&A implementation, and phase two often arrives 9 to 12 months in. TeamOhana can be deployed in parallel and capture Talent workflows from the start, without waiting for the financial model to be finalized.
Buyers thinking about how to connect planning systems with operating workflows. The category question is shifting from “which FP&A tool do we buy?” to “how do we connect financial planning to operational execution?” TeamOhana is the answer to that second question. It is purpose-built to operationalize headcount plans regardless of where the budget is modeled.
See where TeamOhana fits in your FP&A stack
Pigment is a strong system of record for the plan. TeamOhana is the system of record for what happens after.
Together, they give Finance, HR, and Talent a single, governed way to manage the largest line item on the operating budget, without the reconciliation work that eats hours every week and leaves the model out of date.
If you are evaluating Pigment, running it today, or designing the broader FP&A and operating stack, we’d love to show you how TeamOhana fits in.
Simplifying TeamOhana: your questions, answered.
Pigment was built for Finance to model, plan, and forecast. TeamOhana was built for the four teams that execute the plan: Recruiting, Hiring Managers, HR Business Partners, and Finance operators. Once a plan is approved, execution moves to spreadsheets, Slack threads, and email. TeamOhana closes that gap by operationalizing approved roles across all four teams and pushing live updates back to Pigment on demand. The two tools solve different problems for different users.
No. TeamOhana is not a financial planning tool and does not replace Pigment's modeling, scenario planning, or forecasting capabilities. Finance continues to build and own the plan in Pigment. TeamOhana activates the moment the plan is approved and handles everything that happens downstream: role distribution, approval workflows, ATS writeback, and change management. Think of it as the execution layer that keeps the Pigment model accurate.
Finance builds the plan in Pigment. Once approved, roles flow into TeamOhana as the operating plan. Hiring managers and recruiters work inside TeamOhana to manage approvals, change requests, and backfills. When something changes — a start date slips, a level shifts, a backfill opens — those updates flow back to Pigment on demand via a purpose-built API connection. Finance sees an accurate model without manually pulling from any system.
No. This is one of the primary reasons teams add TeamOhana. Pigment contributor seats run roughly $2,000 to $3,500 per user per year and the platform was designed for planners, not operators. Recruiters and hiring managers have no native approval workflows, no ATS integration, and no intuitive way to update a start date inside a financial model. TeamOhana gives Talent and HR their own workflow layer while Finance keeps doing what they do in Pigment. Zero additional Pigment licenses required.
TeamOhana is the live source of truth between syncs. Every mid-quarter change — start dates, level changes, backfills, comp adjustments — runs through a structured workflow with an owner, a status, and an audit trail. Nothing gets buried in Slack or handled informally. When Finance needs to see the current state, TeamOhana pushes actuals to Pigment on demand, not just at month-end reconciliation.
When Finance approves a role in TeamOhana, an open req is automatically created in Greenhouse, Lever, or Ashby. No manual step between plan approval and pipeline activation. When a recruiter moves a start date, the change runs through a defined workflow and the financial model reflects it. This is writeback, not just read — TeamOhana writes live data back to the ATS and to Pigment.
Minimal. The Docker Head of Finance described it directly: "Finance never had to log into TeamOhana except to approve. They loaded the forecast into Pigment and did their forecasting there. TA and hiring managers maintained the live plan." Finance retains full control of what hiring managers can see and approve but does not need to live in TeamOhana to maintain model accuracy.
Ideally, from day one of the Pigment deployment. Most Pigment customers treat headcount workflows as a phase-two item and get to it 9 to 12 months later. That gap is expensive: execution drifts from the model the moment the plan is approved. TeamOhana can be deployed in parallel while Finance finishes building in Pigment. Talent is operational on day one even before the financial model is finalized.
The Pigment decision and the TeamOhana decision are independent. TeamOhana works alongside Abacum, Anaplan, Planful, and the broader FP&A ecosystem. Whatever planning system Finance standardizes on, TeamOhana sits beside it as the execution layer. The two decisions do not compete.


