Three quotes land for the same project. Two are within 10% of each other; the third is 40% cheaper. The instinct is to negotiate the cheap one down further. The better instinct is to ask the cheap one which paragraphs are missing from its proposal — and to do the same check on the others before assuming similar prices means similar work.
If you've ever lined up three drone LiDAR proposals next to each other and tried to compare them on price, you've probably noticed how hard the comparison actually is. The proposals all list scopes that sound similar; they all promise accuracy bands that sound comparable; the prices vary in ways that don't seem explained by the visible content.
The thing nobody quite tells you: in this market, the diagnostic signal lives in what proposals don't say rather than what they do. Most buyers are evaluating proposals on content; the proposals are constructed around omitting the items that would force commitments operators don't always meet.
This article is the working pattern for reading proposals properly — the structure of a typical document, the items that quietly go missing, the phrases that should trigger follow-up, and the diagnostic questions worth asking before any contract is awarded.
Most LiDAR proposals follow a similar structure:
A proposal can hit all seven sections and still leave the specific items that determine engineering-grade vs marketing- grade delivery quietly undefined.
Eight items that routinely go missing — each one a specific commitment that reputable operators include and marginal ones omit:
1. PPK explicitly. The proposal says "GNSS-corrected trajectory" or "RTK-grade positioning" without specifying that post-processed kinematic correction against a logged base will be used. RTK without PPK is acceptable for some work and inadequate for engineering-grade. The omission lets the operator deliver whatever's cheaper. (See RTK vs PPK.)
2. Whether control checkpoints are independent. Proposal references "ground control" or "AHD tie" without distinguishing between marks used in calibration (guaranteed to fit) and marks withheld for validation (the actual accuracy measure). Without the distinction, "validated against control" can mean either.
3. Archive retention. Proposal makes no mention of how long raw source data (RINEX, sensor logs, trajectory archive) will be kept after delivery. Some operators retain indefinitely; others purge at delivery. Reprocessing 18 months later requires the archive to exist.
4. Sign-off authority for QA. Proposal references "QA process" without specifying who signs off the deliverable. Independent sign-off (someone other than the processor) is the convention for mature operators; self-signoff is the default for less mature ones.
5. Cover-class stratification in residuals. Proposal commits to "±20 mm RMSE accuracy" without committing to reporting residuals stratified by cover class. A capture that's tight on bare ground and loose under canopy averages out to the headline number while hiding the real picture.
6. Reprocess pricing. Proposal covers the fresh capture but says nothing about what happens if reprocessing is needed later. Operators with a published reprocess pricing schedule are transparent; operators without one will quote whatever the market will bear when the request arrives.
7. Specific LAS version and tile structure. Proposal commits to "LAS deliverables" without specifying LAS 1.2 vs LAS 1.4, LAZ vs LAS, tile size, naming convention or manifest format. The delivered files may need conversion before they can be used.
8. Independent insurance certification access. Proposal mentions "fully insured" without offering to provide certificate of currency. Most contracts that require certificate provision encounter it as a delay at contract execution.
Three reasons proposals routinely omit the specific items:
Template inheritance. The proposal is a copy of a previous proposal that was a copy of one before it. The template captures historical project scope at some level of detail; specific operational items get smoothed over because they vary project to project.
Defer-detail language. Phrases like "standard methodology" and "industry best practice" let operators commit to something without committing to what. Buyers who don't pin down the language inherit whatever the operator's standard turns out to be.
Avoiding pinning down. An operator who can sometimes deliver PPK + independent checkpoints + 12-month archive but not always benefits from leaving the proposal vague. The work that happens matches the project's specific needs; the work that doesn't happen doesn't surface as a contractual gap.
For most marginal proposals, the vagueness isn't deliberately misleading — it's the path of least resistance. The fix is to ask buyers ask the diagnostic questions rather than accepting the template.
Five questions that cut through the vagueness in any proposal:
1. "Will the trajectory be PPK-corrected against a logged base station, and can I see the base RINEX with the deliverable?"
Yes/no answer. Reputable operators answer yes immediately. Marginal ones explain why PPK isn't necessary for this scope, which is sometimes a legitimate argument and sometimes a signal.
2. "What proportion of the control checkpoints will be independent of the calibration, and will the QA pack report residuals at the independent marks specifically?"
The right answer specifies a number (minimum 20 marks independent) and confirms the QA pack will distinguish calibration-used vs independent. Vague answers about "all control" without the distinction are warning signs.
3. "What's your archive retention policy for raw source data, and what's your reprocess pricing schedule?"
Reputable operators answer 12+ months with a schedule. Marginal operators answer "we keep it for a while" without specifics.
4. "Who signs off the QA pack and what's their role relative to the processing team?"
Independent reviewer = mature operator. Same person who ran the processing = signal worth weighting.
5. "What's the specific LAS version, tile structure and manifest format for the deliverable?"
Specific answer (LAS 1.4 LAZ, 500 m tiles, JSON manifest) = ready for delivery. Vague answer ("standard formats") = expect to clarify and possibly convert.
A reputable operator answers all five without difficulty. An operator who pushes back ("that level of detail isn't usually needed at proposal stage") is signalling something.
Specific words and phrases in proposals that warrant a clarifying question:
Each is politely vague enough to slip past casual reading. Each is worth pinning down in writing before contract.
The flip side — specific commitments that mature proposals include:
A proposal containing these specifics is making concrete commitments. A proposal lacking them is making aspirational ones.
A useful triangulation rule: same project specifications, different reputable operators, should produce quotes within 10-25% of each other. Beyond that gap, the proposals aren't quoting the same work.
When the gap is large:
The cheap proposal is almost always the vague one. Lower price reflects scope interpreted more loosely. The operator isn't lying — they're committing to less than the buyer intended.
The expensive proposal is sometimes over-spec, sometimes just thorough. Worth asking the expensive operator to walk through their inclusions vs the others.
The fix isn't to negotiate the cheap proposal down to match the others. It's to pull the cheap proposal up to the same specification (which will move its price toward the others) or accept the lower-spec scope explicitly with the cost saving.
A subtle but useful signal: how the proposal begins.
Substantive cover letter from senior people — engagement. The operator is treating your project as something specific, not a template submission.
Boilerplate cover letter — template work. May still deliver well; signals that the proposal author hasn't necessarily internalised your project's specifics.
Cover letter mentions specific aspects of your project not in the RFQ — strong signal. Operator has read the RFQ, asked clarifying questions internally, and is positioning around your actual situation rather than the generic case.
This signal correlates with delivery quality in our experience but doesn't predict it perfectly. Worth weighting; not worth deciding on alone.
Three patterns we see when buyers evaluate proposals inadequately:
Comparing on price without checking specifications match. The 40%-cheaper proposal turns out not to include PPK, archive retention, independent QA sign-off, or cover-class stratification. It is genuinely cheaper for less work.
Treating missing items as "operator will probably do it anyway". Sometimes true; sometimes false; never written down. The proposal that doesn't commit is the proposal that doesn't deliver.
Not asking the diagnostic questions before awarding. The five questions above take a single round of email each and cost nothing to ask. Operators happy to answer pass; operators who deflect signal something. Skipping the questions is the cheapest of the false economies in survey procurement.
Capture proposals are routinely written around omitting the specific items that would force commitments operators don't always meet. Reading them effectively means looking for what's missing — PPK explicitly, independent checkpoints, archive retention, sign-off authority, cover-class stratification, reprocess pricing, format specifics, insurance access.
Five diagnostic questions cut through the vagueness. Vague phrases that should trigger follow-up are easy to spot once you're looking. Quotes that look comparable on price often aren't — gap larger than 25% means different work.
The cheap-and-vague proposal isn't a bargain; it's a scope risk priced as a deal. The fix is the diagnostic questions before awarding, not negotiation after.
If we're in the stack and you'd like us to walk through our proposal alongside the others — including the items we've made specific commitments on and where we're being deliberately vague — happy to do that on a call. Honest comparison is in everyone's interest.
The brief-side companion to this evaluation piece — six items to put in your RFQ so the proposals you receive have to commit to them.
Once a proposal has passed evaluation and the project is awarded, the structured first-project test that validates whether the proposal commitments translate into actual delivery.