On This Page
Identify what each company is actually supplying
Treat supplier labels as the start of the conversation. For evaluation purposes,
separate four functions:
- Manufacturer: supplies the aircraft or payload, publishes supported
configurations and limits, and defines product support and warranty terms.
- Dealer or distributor: supplies equipment and may handle setup, training,
repairs, or warranty coordination. Confirm which services are included in its
proposal.
- Integrator: connects the proposed equipment and software to a defined
task, including custom hardware, data transfer, or business-system connections
where needed.
- Service provider: performs the work and delivers an agreed output,
potentially leaving aircraft ownership and operation outside your
organization.
These functions can overlap. For example,
Drone Nerds describes platform,
sensor, and software selection alongside custom solutions and training. That
illustrates the scope a supplier may offer; a service description does not
establish the quality of a particular implementation.
Ask each bidder for a responsibility schedule naming the legal supplier, any
subcontractors, the included services, and the party responsible for each
acceptance requirement. Identify who will diagnose a failure that crosses
company boundaries, such as images reaching the cloud but arriving without
usable asset identifiers.
A manufacturer-led purchase can fit a team that already has the technical staff
to deploy and support a documented configuration. An integrator becomes more
useful when the task requires custom payload behavior, connections to existing
systems, or coordinated support across vendors. If the organization mainly needs
periodic finished inspections, compare that ownership commitment with a service
contract. The
drone inspection services guide
explains how to evaluate the latter's scope and quality.
Set the requirements before comparing proposals
Write a short mission statement that names the asset or area, required
observation, operating conditions, delivery deadline, and team receiving the
result. Replace “high-quality inspection” with a description of the views or
measurements that team must use to make its decision.
Separate mandatory requirements from preferences. A missing required export or
unsupported operating condition should be resolved before a better camera
specification earns the proposal extra consideration. Avoid an overall score
that lets several attractive extras conceal one essential failure.
Use the following matrix as a request-for-proposal starting point. Its questions
are editorial procurement recommendations drawn from the technical and
test-method sources below, not universal acceptance thresholds.
Scroll horizontally to compare all columns.
Send the same requirements to every company. Record exclusions and assumptions
in a separate schedule so a narrowly scoped bid does not look equivalent to a
complete delivery.
Define the data delivery and acceptance checks
Specify both the product your team will use and the underlying records it needs
to verify or reuse that product. For an inspection, that may mean original
images tied to asset and component IDs, capture dates, observations, and
explicit missing-coverage notes. For mapping, agree the required imagery or
surface model, coordinate reference system, units, and accuracy-assessment
report.
File names alone are insufficient.
Esri's Site Scan export documentation
distinguishes a PNG orthomosaic preview suitable for presentation from the TIFF
used for raster analysis. It also describes LAS and compressed LAZ point clouds
and advises checking whether the receiving software accepts LAZ.
Ask the intended recipient to open and use a sample delivery in the actual
application and version your organization runs. Confirm that it lands in the
right location, retains the required attributes, and supports the intended
measurement or review. A file opening successfully is only the first check.
For mapping work, have the responsible geospatial specialist define the accuracy
quantities, independent checks, and reporting method before bids arrive. An
aircraft positioning claim should not become the acceptance limit for the final
map. The drone survey accuracy guide develops the questions to put to the
supplier.
For repeated inspection work, test retrieval as well as delivery: can a reviewer
find the same component from the previous visit and distinguish a new
observation from an old one? Agree who corrects incomplete or misidentified
records and what constitutes an accepted delivery.
Make integration responsibilities explicit
Break integration into the aircraft-to-payload connection, the
capture-to-processing workflow, and the handoff into your organization's
systems. For each connection, ask what data or command crosses it, what software
or hardware is required, and who maintains it.
For a custom payload, request documentation covering mounting, mass and balance,
power, data transfer, capture triggering, and supported aircraft/software
combinations. Have the supplier demonstrate the required functions on the quoted
configuration. Assign separate acceptance checks to physical installation,
capture, and usable output so an installation sign-off does not silently cover
all three.
For software, replace “open API” with a short list of required operations. An
application programming interface might be needed to
retrieve original files,
match observations to assets, or create a maintenance record. Specify the
required fields, permissions, failure notifications, and retry behavior, then
test those operations. Name the owner of any custom connector and agree how it
will be maintained after a vendor update.
Mixed-fleet support needs an explicit check. The
DJI FlightHub 2 FAQ says drones
from other manufacturers cannot connect. Do not infer direct aircraft
connectivity from the broader description “fleet management.” Verify each
required function separately for each proposed platform. Use the
commercial drone fleet management software guide
when developing that software requirement list.
Have your IT team settle account ownership, access roles, data location,
retention, bulk export, and network dependencies before acceptance. Ask what the
crew can complete without internet access and how incomplete transfers are
recovered. Require the integrator to identify which behaviors it controls and
which depend on another provider's service.
Compare lifecycle costs on the same basis
Choose a common evaluation period and workload, then ask every company to price
the same scope. Include acquisition, payloads, integration, training, operating
labor, maintenance, consumables, software, processing, storage, and eventual
migration or retirement. Identify bundled items so they are not counted twice.
A useful planning formula is:
Lifecycle cost = acquisition and integration + training and setup + operating
labor + maintenance and consumables + software and data services + expected
rework and downtime costs + retirement and migration costs − recoverable
residual value.
Populate it with dated supplier quotes and your own documented assumptions.
Treat downtime, future workload, and resale value as uncertain inputs, and
compare how the result changes when those assumptions change. The formula
defines a budgeting boundary; it does not provide a market-price estimate.
Also compare cost per accepted delivery:
Cost per accepted delivery = lifecycle cost over the evaluation period ÷
deliveries meeting the agreed acceptance requirements in that period.
Use the same delivery unit for every proposal, such as a complete reviewed asset
inspection. Define rework consistently: extra flights to finish one inspection
should not inflate the count of accepted deliveries.
Ask the supplier to separate one-time charges, recurring fees, usage charges,
and optional services. Request written terms for renewal, storage, processing
allowances, additional users, repairs, and data retrieval at contract end. The
FlightHub 2 FAQ, for example, says expired storage prevents adding new data
while existing data remains accessible. That is a provider-specific term, not an
assumption to make about every platform or the complete set of services that
expire.
Finally, assign costs to an owner. A connector maintained by your own staff
still belongs in the comparison even when the supplier's invoice contains no
integration-support fee.
Verify the claims that can change the purchase
Maximum performance: ask for the conditions behind an advertised number. DJI
lists a 55-minute maximum flight time for the
Matrice 350 RTK, measured at
approximately 8 m/s without payloads, in windless conditions, until the battery
reached 0%. That does not establish working endurance with your sensor, transit,
capture task, and landing reserve. Request a mission estimate for the quoted
configuration and validate it through an appropriate trial.
Operational permissions: distinguish an aircraft feature from permission to
use it in the proposed operation. In the United States,
FAA commercial-operator guidance
explains the Part 107 route and notes that some operations require waivers. Ask
the proposed operator to identify the applicable operating basis and any needed
permissions. A supplier's general “compliant” label does not answer that
question.
Test credentials: ask who ran the test, what method was used, which
configuration and pilot were involved, and what the result measures.
NIST explains
that its drone methods measure system capabilities and pilot proficiency;
organizations set their own acceptance thresholds. It also states that NIST does
not train or certify people. Treat the actual test record as the evidence,
rather than assuming a badge proves suitability.
Support promises: request the scope, exclusions, escalation process, and
written response commitments for your region and equipment. Distinguish an
initial response from a completed repair or restored service. Ask who pays for
shipping, replacement equipment, recalibration where relevant, and diagnosis
when the fault crosses a custom integration.
For references, seek a completed project with comparable data requirements and
operating conditions. Ask what was delivered, what required rework, and who
resolved problems after handover. Where the customer permits it, compare a
sample deliverable with the proposed acceptance requirements. A recognizable
customer name alone does not answer those questions.
Choose through a representative acceptance trial
Give shortlisted companies the same task, required deliverables, and acceptance
method. Use the equipment and software in the proposal, and record the crew
arrangement and conditions. If a supplier substitutes equipment, record the
difference and resolve it before treating the result as evidence for the
purchase.
Have the receiving team evaluate the resulting files and workflow, not just
watch the flight. Include a normal capture, the required export or integration,
retrieval of the completed record, and a supported demonstration of how an
incomplete transfer is detected and recovered. Agree the test's limits; one
successful trial is not proof of reliability in every environment.
Require the final handover to include the configuration record, sample accepted
delivery, known limitations, operating and integration documentation, account
ownership, and support responsibilities. List unresolved items with a named
owner and an acceptance condition. Put any essential future feature into a
separately defined delivery milestone; do not treat a roadmap promise as an
available capability.
Choose a manufacturer-led route when the documented system fits and your team
can own the remaining integration. Choose an integrator when it demonstrates the
required connections and accepts responsibility for maintaining them. Choose a
service arrangement when the real requirement is a repeatable finished output
and ownership adds responsibilities your organization does not need. In every
case, award against demonstrated requirements and a complete scope, with
unresolved mandatory items settled before acceptance.
Source notes
Last checked: September 9, 2026.
