Cube vs. Mosaic for Field Service Contracts and Parts Margin

Imagine a customer on a flat annual service contract who has two equipment failures in the same month, each requiring a technician dispatch and parts that cost more than that month's pro-rata share of the contract fee. On a pure revenue-recognition basis, the contract still recognizes its usual monthly amount; the problem only shows up when you compare that recognized revenue against the actual technician hours and parts consumed against it.

A model that doesn't track contract-level cost against contract-level revenue will show the same healthy margin every month, right up until enough customers have a heavy month at once and the blended margin drops without warning.

If your team already tracks technician hours and parts cost against each service contract in a spreadsheet, even roughly, Cube's approach of syncing that spreadsheet against dispatch and parts inventory data keeps the cost-to-serve calculation where it's understood, with less manual pulling from a field service management system each month.

Once you're running a meaningful base of service contracts alongside project-based repair work, a dashboard that shows blended margin, contract margin, and time-and-material margin separately can flag which revenue type is actually driving profitability. Confirm in a demo that Mosaic can split those two revenue types cleanly rather than reporting one blended number, since averaging them together hides whether your contract pricing is actually covering its cost to serve.

A common mistake is renewing service contracts at the prior year's price plus a flat increase without checking whether that customer's actual technician hours and parts usage justified the original price. Build a per-contract cost-to-serve view into the model so a renewal conversation is grounded in what that specific customer actually costs you to service, not a blanket assumption applied across the whole book.

Jirav's driver-based approach is useful when you're planning to add service contracts and need to know how many additional technicians that growth requires, since technician capacity, not sales volume alone, is usually the real constraint on how many new contracts a field service business can take on without extending response times.

Parts inventory for equipment repair sits in an awkward spot between fast-moving consumables and slow-moving specialty components that might sit on a shelf for a year waiting for the right failure. A forecast that treats all parts inventory as one turnover assumption will misjudge cash tied up in the slow-moving specialty stock; separate the two categories so a purchasing decision on a rarely used component doesn't get evaluated against the turnover expectations of a common consumable part.

A technician's day is split between scheduled preventive maintenance visits, which you can plan a route around, and emergency breakdown calls, which can't be scheduled and often mean bumping other work. A forecast that assumes every technician hour is equally plannable will overstate how many contracts your current headcount can actually support, since emergency calls eat capacity that scheduled-visit planning assumed was available. Build a buffer into technician utilization assumptions based on your own historical mix of emergency versus scheduled dispatches, not a generic industry rule of thumb.

Export a quarter of technician time entries and parts usage tied to specific contracts and see how cleanly that maps into either platform's expected structure, since a field service system that doesn't tag time and parts to a contract number by default will need that fixed before any dashboard or spreadsheet sync can produce a trustworthy cost-to-serve figure. Confirm the export includes travel time as well as on-site time, since travel is a real cost against a contract even though it doesn't show up on an invoice line, and a model that ignores it will understate what a geographically spread-out contract base actually costs to support.

Test these points before moving cost-to-serve tracking:

• Export a quarter of technician time entries and parts usage tied to specific contracts and test how they map into each platform.
• Confirm your field service system tags time and parts to a contract number by default, and fix that first if it does not.
• Check that each tool can split contract margin from time-and-material margin instead of reporting one blended figure.
• Verify that scheduled and emergency dispatch hours can be forecast as separate capacity lines.
• Separate fast-moving consumable parts from slow-moving specialty parts before loading inventory data.