What Are Estimated Work Hours on a Quote?

Estimated work hours on a quote are the hours of real work the routing would consume, not the elapsed span between the quoted start and end dates. The two numbers appear side by side on the same row and they measure completely different things, which makes this one of the easiest figures in a quoting module to misread. In EDGEBIC by User Solutions the hours come from a simulation that runs the real scheduling engine against the plant's real current load, sums what the work centers were actually allocated, and prices that.

How it works

When a quote is simulated, the engine creates a temporary job for the quoted product and quantity and schedules it exactly as it would schedule a real order: the same shifts, the same holidays, the same work center capacity, the same setup times, and the same existing job load. It then reads off the resulting window, sums the hours allocated to each work center, prices them, and deletes the temporary job. Nothing is written to the production plan, which is why simulating twenty times a day disturbs nothing.

Two outputs come from that single run, and they answer different questions:

The gap between them is everything the plant is not working: nights, weekends, plant closures, and the time a job spends waiting behind other work already committed on the machines it needs. None of that is labor, and none of it should be priced as labor.

The scale of the difference is easy to underestimate. A job that begins on a Friday afternoon and finishes on a Monday morning spans roughly sixty-six clock hours and may contain six hours of real work. Cost the span and you have quoted eleven times the labor the job consumes.

Sub-assembly content is included in the hours automatically. If the quoted product's routing references a sub-assembly, that child's own routing hours roll into the total, recursively through any depth, and the per-step quantity multiplier is honored so two children per parent unit counts twice. The requirement is simply that each sub-assembly has a routing, since a roll-up can only sum work that is described somewhere. See what is a sub-assembly in manufacturing.

A concrete example

Take a quote for 200 units of a widget whose routing runs saw, then mill, then assembly.

The simulation allocates 20.5 hours to the saw, made of half an hour of setup plus 200 units at 0.10 hours each. The mill gets 101.0 hours: one hour of setup plus 200 at 0.50. Assembly gets 30.0 hours at 0.15 per unit. The estimated work hours therefore come to 151.50.

The dates come back as a window from the twentieth of July to the fourteenth of August, which the quote reports as 25 days of lead time.

Both numbers are correct and neither substitutes for the other. 151.50 hours is what the shop will spend and what the labor cost is built from. Twenty-five days is what the customer waits, and most of that span is closed evenings, weekends and the job's turn in the queue behind the several hundred hours of other work already sitting on the mill that month.

Notice what happens if the shop gets busier. Add another large order onto the mill and re-simulate: the hours stay at 151.50, because the work content of the product has not changed, while the end date moves out, because the queue got longer. Anyone watching only the date would conclude the job became more expensive. Anyone watching only the hours would conclude nothing changed at all. Reading both is the point.

How EDGEBIC uses it

The quote grid puts estimated hours next to the simulated start and end dates and next to estimated cost, profit and margin, so the relationship is visible on one row. A details window goes further and shows which work center was allocated which hours on which days, which is the fastest way to see where the content of a job actually sits.

The hours figure has one job in the costing chain: it is the quantity that gets multiplied by each work center's rate to produce the labor half of the estimate. That rule, and the material half beside it, is set out in what is the labor and material cost basis on a quote. The date side of the same run feeds the promise, described in what is estimated lead time on a quote.

Once a quote is converted into an order, the estimate travels with it, and the quote keeps a column showing quoted hours against the hours actually burned on the linked order, with a dash on the right until actuals begin arriving. That comparison is where a shop learns whether its routing rates are honest, and it only works because the hours were stored as work content rather than as a span. The reality side of it is defined in what is planned vs actual hours.

Two habits are worth keeping. Simulate before sending rather than relying on the preliminary routing arithmetic, because only the simulation includes current shop load. And when quoting hours to a customer, say the word "work" out loud, so nobody later compares your six hours against their sixty-six and calls it a discrepancy.

The takeaway

Estimated work hours are the labor content of a job; the quoted date span is the customer's wait. One prices the work, the other answers the delivery question, and the difference between them is simply the time the plant is closed or busy elsewhere. Report both, price from the hours, and keep the comparison against real consumed hours once the job runs. To see the figures side by side in a working system, explore EDGEBIC, and if you are arriving from the older Resource Manager lineage, the move from RMDB to EDGEBIC maps the equivalents. For neighboring terms, read working day vs calendar day in scheduling and what is a quote status.