Lead form conversion values: flat value or job-ticket estimates?

Picture a plumber getting about 40 quote requests a month from the site form, with maybe a third turning into paid jobs. If the form is a plain conversion with no value, Smart Bidding treats a 200 dollar drain clear the same as a 4,000 dollar bathroom rebuild. My instinct is to assign values from average ticket size by service so bidding can see the difference. Some people argue that value estimates just teach the algorithm to chase whatever is cheapest to fill, and that a flat value is safer until you have real close-rate data. Has anyone set values on non-ecommerce lead forms, and if so, how did you pick the numbers and did your tROAS target hold once you changed them?

Average ticket size overstates what a lead is worth, because only about a third of leads turn into jobs. A $4,000 rebuild is closer to $1,300 per lead once you account for that, and a $200 drain job that closes more often can actually beat it. So multiply ticket size by close rate instead of using the raw average.

Multiplying by close rate is right, but use gross margin per job instead of ticket size if you can get it. A $200 drain that costs $60 in parts and van time can be worth less than a rebuild at a 40% margin, and Smart Bidding will happily optimise for revenue that doesn't pay the bills.

A good rule of thumb is value = average margin per closed job × close rate, but only for services with 20 to 30 closed jobs behind that close rate. Below that, use a flat value. A close rate from five jobs is mostly noise, and noise is what sends bidding after cheap leads in the first place.

Honestly it comes down to whether you can match closed jobs back to the original click. If the office tracks jobs in a spreadsheet with no gclid or phone number attached, you won't get a clean close rate per service, and the "20 to 30 jobs" threshold gets hard to hit honestly. If the form stores the gclid in a hidden field, or the phone number is tracked, you can import offline conversions with the real margin as the value, and Smart Bidding learns from every job instead of a monthly estimate.

Your numbers matter here too. Forty leads a month with a third closing is about 13 jobs a month across all services. Split that between drains, rebuilds and repairs and most services will need a couple of months to reach 20. So the flat value will probably run for the first quarter, which is fine as long as you treat it as temporary and swap it out once the data is there.

For the first quarter, set the flat value in the same units as the future margin number. For a plumber, that's roughly average margin per job times the blended close rate, so about a third of what a job nets. That way the scale stays put when you switch to real values, and you aren't comparing a guess to a margin figure.

Also, don't change values and the tROAS target in the same week. A tROAS target only makes sense against a fixed value scale. If values jump from a flat 150 to job-based numbers in the hundreds or thousands, the target that worked last month can suddenly throttle delivery or overspend. Change the values first, give it a couple of weeks to relearn, and only then adjust the target.

Matching the units is right. I'd also leave the value on the existing lead action alone when you switch. The flat-value history stays in that action, so the model keeps learning from two different scales. It's cleaner to create a separate offline conversion action for closed jobs, import it with margin as the value, and only then demote the lead action to secondary.

Also, Google only accepts offline click conversions up to 90 days after the click. If jobs close slowly, like rebuilds, store the gclid and match it early so you don't lose those imports.

Agreed on the separate action. I'd also keep the lead action as primary until the job action has real volume, because a tROAS target needs enough conversions to learn from. The usual rule of thumb is around 15 conversions in 30 days, and at 13 jobs a month across all services you probably won't hit that per service. So it makes sense to keep the lead action primary for longer and use the job import as a secondary signal to see which leads turn into margin. Demoting the lead action too early can leave bidding with almost nothing to learn from.

Keeping the lead action primary makes sense, but the job import has a catch. Google only feeds primary conversion actions into bidding, so a secondary import is observation only. It'll show you which leads turn into margin, but tROAS won't learn from it. Use it to check the flat value against real margin each month, then promote the job action once it has enough volume to take over.

If you run Bing too, capture the msclkid on the form next to the gclid. Microsoft Ads needs it for offline imports, and storing both now costs nothing.

The monthly check only works if you compare margin per lead rather than per job, and you need the same time window for both. Otherwise a rebuild that closes next month makes the flat value look wrong for no reason. Does the job log record which service each closed job came from?