What to Put in a Drone Survey RFP

Most drone survey RFPs we see are one paragraph long. They name the site, ask for "aerial mapping" or "a drone inspection", and ask for a price. Then three bids come back with three very different numbers, and the buyer has no honest way to compare them — because each bidder has quietly scoped a different job to fit their own price.

The fix is not a longer document. It is a document that answers a short list of questions the operator will otherwise answer for you. Here is what belongs in a drone survey RFP, in the order it matters.

Start with the decision, not the deliverable

One sentence at the top of the RFP does more work than the rest of the document: what decision does this data have to support?

A volume that feeds an inventory reconciliation, an inspection finding that feeds an integrity decision, a surface that gets imported into a design model, a progress record that may end up in a claim — each of these implies a different level of rigour, a different quality-assurance step, and a different price. An operator who knows the answer can scope correctly. An operator who does not will scope to whatever makes the bid look attractive.

Say the decision, say who will use the file, and say what software it has to open in. Then let the bidders tell you what that requires.

Scope: area, access and repetition

• The area. A boundary file or coordinates, not a description. "The east yard" is not an area; a polygon is.
• What is inside it that matters. Structures to be captured in detail, ground that only needs coverage, anything explicitly excluded.
• Access and escort. Who lets the crew in, what orientation is required, what the lead time is on a gate. This is the single most common cause of a wasted mobilisation.
• Live operations. Working equipment, traffic, lifts, flaring, other contractors, aviation activity on or near the site.
• Repetition. Whether this is a one-off or the first of a recurring cycle. A survey designed to be repeated and compared is built differently from a one-time capture, and the price of the series is not the price of the first flight multiplied out.

Accuracy: state it, and state how it is proven

"Survey grade" is not a specification. It is a marketing phrase, and every bidder will agree they meet it.

A usable accuracy clause has three parts:

1. The requirement itself — horizontal and vertical stated separately, because they are not the same and vertical is almost always the harder one.
2. How it will be verified — independent check points that were not used in the processing, reported against the delivered product. A residual on the control the operator already used to build the model is a self-marked exam.
3. What is delivered as proof — an accuracy or control report, not a verbal assurance.

Do not specify the method. If you write "must use RTK" or "must place twelve ground control points" you have taken responsibility for the result away from the operator and given it to yourself. Specify the outcome and the verification, and let the bidder choose how to achieve it — our post on how many ground control points you actually need covers why that choice is genuinely job-dependent, and RTK vs PPK covers the trade-off between the two positioning approaches.

Coordinate system and vertical reference

This is the clause most often missing, and it is the one that turns a good survey into an unusable file. Name the horizontal coordinate system, the datum and epoch, and the vertical reference the elevations must be on — and if the site has its own grid, say so and say who holds the transformation.

Deciding this after the data is processed is expensive; deciding it in the RFP costs nothing. Our post on which coordinate system your drone survey should be in walks an Alberta buyer through the choice.

Deliverables, named individually

List the products, not the category. For a mapping scope that usually means some subset of:

• Orthomosaic, with the ground sample distance it must meet
• Digital surface or terrain model, and which of the two — they are different products and the difference matters when there is vegetation or equipment on the ground
• Point cloud, in a named format
• Contours at a stated interval
• Volumes against a defined base surface, with the base surface defined in the RFP rather than assumed
• Annotated inspection imagery, and whether findings must be severity-ranked
• A written report, and who it is addressed to

Then add the clause everyone forgets: native and interchange formats, not just a PDF. A report you cannot import is a report you will pay someone else to recreate.

Data ownership, retention and confidentiality

Say who owns the raw imagery and the derived products, how long the operator keeps the data and where, whether it may be used as a portfolio or marketing example, and what happens to the files when the contract ends. If the site is sensitive, say that publication consent is withheld by default rather than assuming the operator will guess. Our post on drone data ownership and retention sets out the terms worth naming.

Compliance, asked for as evidence

Ask for attachments, not assurances:

• Pilot certification appropriate to the operations the job requires, and evidence it is current
• Aircraft registration for the aircraft actually being used
• Aviation liability insurance certificate at the limit your contracts require, naming your organisation where you require that
• Confirmation that any airspace authorisation needed for the site is the operator's responsibility, and that the check happens before mobilisation
• Site safety documentation to your standard — hazard assessment, emergency response, and whatever contractor-management system you use
• Data-handling and retention practice, in writing

Our drone contractor compliance self-check is a ten-item version of this you can run against a bid package in a few minutes, and the 2026 Alberta RPAS compliance guide explains what each item means.

Schedule, weather and the exceptions clause

Ask for a turnaround commitment measured from completion of data capture rather than from the site visit, and ask which deliverables land on that date and which follow. Then write the exceptions honestly: weather and airspace authorisation are real, and an RFP that pretends otherwise gets bids that pretend otherwise. Name them as exceptions with a re-attempt commitment, so a stand-down is a process instead of a dispute. Our post on what actually causes survey delay is a useful cross-check on any schedule you are offered.

Ask for one sample, and read it

Request a redacted deliverable from comparable work — not a portfolio image, the actual report or model a client received. It tells you more about a bidder than every other page of their submission combined, and it is worth reading the way its intended user would: can a specific finding be located quickly, does every measurement say what it was measured against, and would it still make sense to somebody who was not on the call.

The short version

If you only have half a page, cover these eight lines:

1. The decision this data supports, and who uses the file in what software
2. Boundary, access arrangements and live-operations constraints
3. Horizontal and vertical accuracy, with an independent verification method
4. Coordinate system, datum, epoch and vertical reference
5. Deliverables named individually, in native and interchange formats
6. Data ownership, retention and publication consent
7. Certification, insurance and site-safety evidence as attachments
8. Turnaround measured from data capture, with named weather and airspace exceptions

Bids written against that list are comparable. Bids written against "please quote aerial mapping" are not, and the cheapest one is usually cheapest because it left something out.