The Ramp Problem, the $16M Tax, and What Salesforce Didn't Put in the Press Release

The hire looks right on paper. The margin doesn't show up.

That's not a hiring problem. That's a math problem. It shows up the same way every time: the revenue projection supports the headcount, the timing feels right, and then three months later you're carrying cost you can't bill yet.

Three things worth your time this week.

---

You're Not Hiring Too Fast. You're Hiring Without a Ramp Model.

Most operators staff to a revenue number. That's the wrong number.

The revenue projection tells you what you need at full utilization. It doesn't tell you what you'll actually bill in months one, two, and three while the new hire is finding their footing and getting into the flow of the operation. That gap between hire date and full billability eats margin before the revenue arrives.

The fix isn't slower hiring. Slower hiring costs you differently. The fix is building the ramp into the math before you approve the headcount.

Before a hire is approved, someone should be able to answer three questions: How long does it take this role type to reach full billability in this operation? What does that lag cost at current margin? Can the operation absorb that cost without stressing the P&L?

If you can't answer those three questions, you're guessing.

The growth initiative I ran at Amerit that drove $30M+ in unforecasted revenue didn't happen because we hired fast. It happened because we built a capacity model first, understood the ramp mechanics, and sequenced hiring against what the operation could actually absorb. The 46.7% EBITDA beat against plan came from a team that understood the difference between staffing to a projection and staffing to a billable ramp curve. Those are not the same number.

One more thing: data lag makes this worse. If the projection you're hiring against is four to six weeks old in a fast-moving operation, it's already stale. Reduce the lag before you trust the projection.

---

The $16M Disruption Tax Is Mostly a Governance Problem

A new Coupa report shows procurement-driven supply chain disruptions are costing companies roughly $16 million a year. The headline reads like a macro volatility story. It isn't.

Read past the number and what you find is mostly internal process failure. Undefined exception paths. No early-warning visibility. Vendor relationships managed reactively. The disruption isn't the problem. The absence of a governance layer that sees it coming is.

Most of these losses are paid on predictable problems. A vendor misses a signal. A procurement exception gets handled informally. A risk that should have triggered a flag three weeks earlier gets absorbed as a fire drill. These aren't acts of God. They're governance gaps.

The operators who absorb disruption at lower cost have a few things in common: a single intake path for exceptions, a regular vendor review cadence, defined early-warning signals for their highest-risk supply categories, and assigned ownership on each one.

None of that requires a new platform. It requires a decision about who owns what and a cadence that creates visibility before the damage is done.

Lean supply chains don't become fragile by design. They become fragile when operators interpret lean as just-in-time without building the process discipline to absorb shocks. $16M a year says most companies haven't built it yet.

---

Salesforce Just Launched an Operations Agent. Do This First.

Salesforce dropped Agentforce Operations this week. The pitch: it converts slow, fragmented back-office processes into automated, agent-driven workflows. Box launched a similar product the same week. The demos are clean.

Here's what the press release left out.

Fragmented processes don't become clean when you hand them to an agent. They become faster and more fragmented. An agent executing an undefined process doesn't pause to ask for clarification. It runs what it was given and produces an output. If the input has gaps, workarounds, and undocumented exceptions, the agent will run those through at scale.

Before you evaluate this product or anything like it, do this work first.

Sit with the people who actually run the processes you're considering automating. Not the documented version. The real version, including the exceptions and the steps that only work because a specific person knows how it goes. Write it down. If explaining a step requires naming a specific person who "just knows, " that's a documentation gap and the agent will fail there.

Then define what success looks like before go-live. What metric moves? By how much? In what timeframe? If you can't answer that before deployment, you won't be able to substantiate ROI after.

The AI observability software category exists for a specific reason: organizations are paying a second cost to diagnose problems created by skipping process documentation before agent deployment. That's a sequencing problem, not a technology problem.

Agentforce Operations might be the right tool for your operation. That question is secondary. The primary question is whether your back-office processes are defined clearly enough to hand off to an agent.

Audit what you have. Document the real workflow. Then evaluate the tool.

---

The Takeaway

This week, pick one recurring back-office process your team complains about and ask them to walk you through every step, including the workarounds they use when the official process breaks. Write it down. That document will tell you more about your operational risk than any vendor demo will.

---

If any of this is landing close to home, hit reply. The ramp model problem and the process documentation gap before agent deployment are both things I work through with operators at Decion. Happy to think through it with you.