Drone Deliverable Handoff Checklist: What Leaves Your Office

The Deliverable the Client Couldn’t Open

An operator emails a 4.2 GB GeoTIFF orthomosaic. The client’s email server rejects it — 25 MB attachment limit. The operator resends via Google Drive link. The client’s IT department blocks external cloud storage links as a security policy. Two days of back-and-forth before the file actually transfers. The ortho was perfect. The delivery was amateur.

Second scenario. An operator delivers an orthomosaic in EPSG:4326 — WGS84 geographic coordinates. The client’s CAD technician imports it into AutoCAD Civil 3D configured for State Plane NAD83 in US survey feet. The ortho loads at the origin — latitude/longitude decimal degrees plotted as linear units. It’s a microscopic speck at coordinates (39.7, -104.9) instead of spanning the project area at (3,143,000, 1,786,000). The CAD tech emails: “The file is broken.” It’s not broken. It’s in the wrong coordinate system for their software, and no projection file was included.

Third scenario. An operator delivers a contour file and orthomosaic. No accuracy statement. No metadata document. The client’s surveyor asks: “What’s the accuracy of this data?” The operator says “centimeter-level.” The surveyor asks: “Based on what? How many GCPs? What were the checkpoint residuals? What CRS? What vertical datum?” The operator has the answers buried in the processing quality report — but didn’t include them in the delivery. The surveyor won’t sign off on the data until the accuracy documentation arrives. Another round of back-and-forth. Another delay.

Three different problems. One root cause: no handoff checklist. The data was good in all three cases. The delivery process made it look unprofessional.

You spent hours in the field placing GCPs, flying the mission, verifying overlap, running QA. You spent more hours in the office processing the data, checking alignment, reviewing checkpoint residuals, exporting deliverables. All of that work gets judged by what arrives in the client’s inbox and whether they can use it without calling you first.

This is the checklist that makes the handoff match the quality of the work.

File Formats by Deliverable Type

What your client’s software actually needs. Bookmark this table.

The format decision should happen before processing, not after. Ask the client what software they use during the scope phase and record it in the project specification — which you verified on the pre-flight checklist. CAD users need DXF and State Plane coordinates. GIS users need GeoTIFF and Shapefiles. Web viewers need tiles or compressed formats. Don’t assume. Ask.

A few format-specific notes worth knowing:

• GeoTIFF compression. An uncompressed orthomosaic for a 50-acre site can run 4—8 GB. LZW compression reduces that to 1—3 GB with no quality loss — it’s lossless. JPEG compression inside a GeoTIFF reduces file size further but introduces artifacts in areas of uniform color and can degrade elevation data in DSMs. Use LZW for survey deliverables. Save JPEG compression for web-only preview images.

• LAZ vs. LAS. LAS is the uncompressed point cloud format. A 500 MB LAZ file decompresses to 3—5 GB as LAS. Every major point cloud viewer — CloudCompare, Global Mapper, QGIS, Pix4Dsurvey, TBC — reads LAZ natively. There is no reason to deliver LAS unless the client specifically requests it. Deliver LAZ. Save them the storage and the transfer time.

• DXF vs. Shapefile for contours. If the client works in AutoCAD, Civil 3D, or MicroStation, deliver DXF. If they work in ArcGIS, QGIS, or Global Mapper, deliver Shapefile. If you don’t know, deliver both. A contour file in both formats adds 20 MB to the delivery package and eliminates a round-trip email asking for the other format.

• Sidecar files matter. A GeoTIFF without a .prj file works in most GIS software — the CRS is embedded in the GeoTIFF header. But AutoCAD Civil 3D reads the .prj file for coordinate system assignment. A DXF without a .prj leaves the CAD user guessing which coordinate system the file uses. Include .prj and .tfw (world file) with every raster deliverable. Include .prj with every DXF and Shapefile. These are small text files — kilobytes — that prevent the most common import failure.

Coordinate System Documentation

Include this with every delivery. Every. Single. One.

This one document prevents the most common downstream integration failure: the client importing your data into their existing project and watching it land in the wrong location. You spent an entire section of the processing checklist getting the coordinate system right. Document it so the client’s software can use it correctly.

Create a metadata document — plain text, PDF, or included in the delivery README — with the following:

• Horizontal CRS. Full name, EPSG code, and human-readable description. Example: “NAD83(2011) / Colorado North (EPSG:6428), US Survey Feet.” Not just the EPSG code. Most non-GIS professionals don’t know what an EPSG code means. Spell it out.

• Vertical Datum. NAVD88 with geoid model specified. Example: “NAVD88 (Geoid18), US Survey Feet.” The geoid model matters — Geoid12B and Geoid18 produce different orthometric heights from the same ellipsoidal height. The difference is typically 0—4 cm in the continental US, but it’s a difference, and the client’s surveyor will ask which geoid model you used.

• If ellipsoidal heights: State it explicitly. “Heights are ellipsoidal (WGS84), not orthometric (NAVD88). Apply geoid correction for orthometric elevations.” Ellipsoidal heights are the GPS default. Many clients — especially those in construction and civil engineering — expect orthometric heights referenced to NAVD88. If you deliver ellipsoidal heights without stating it, the client’s surface model will sit 20—35 meters above or below reality. They will call you. The call will not be pleasant.

• Projection file (.prj). Include a .prj file with every raster and vector deliverable. Most GIS software reads this automatically. AutoCAD Civil 3D requires it for automatic coordinate system assignment. Without it, the user has to manually assign the coordinate system — and they will guess wrong. A .prj file is a 200-byte text file. Include it.

• Coordinate units. Specify meters, US survey feet, or international feet in plain language. Don’t rely on the EPSG code to communicate units. The client’s project manager reading the delivery email doesn’t look up EPSG codes. Tell them: “All coordinates in US survey feet.”

This document takes 5 minutes to create. You can template it and fill in the project-specific values for each delivery. It prevents the most expensive phone call you’ll make this month — the one where you explain why the orthomosaic is “in the wrong place” because the client’s software couldn’t identify the coordinate system automatically.

Accuracy Statement

This is what makes your deliverable defensible. Without it, your data is just pictures and elevation models with no stated reliability. No surveyor, engineer, or project manager can use data they can’t qualify.

Include in every delivery:

• GCP count and distribution. “8 ground control points distributed across the survey perimeter and interior. 3 independent checkpoints used for accuracy validation.” State both counts. The distinction between GCPs and checkpoints matters — GCPs constrain the model, checkpoints validate it. If you used all your control points as GCPs and held none as checkpoints, state that too and acknowledge the limitation.

• Checkpoint RMSE. “Independent checkpoint RMSE: 2.1 cm horizontal, 3.4 cm vertical.” Checkpoints, not GCPs. GCP residuals show how well the model fits the control. Checkpoint residuals show actual accuracy on independent validation points. Report both, but the checkpoint RMSE is the number that matters for accuracy claims. This is the number the client’s surveyor will look for first.

• Processing software and version. “Processed in Pix4Dmatic 1.65” or “Agisoft Metashape Professional 2.1.3.” Version matters. Different software versions use different algorithms, different camera calibration models, different densification methods. The same dataset processed in Metashape 2.0 and Metashape 2.1 can produce measurably different results. State the version. If the data is ever questioned or reprocessed, the version number tells the reviewer exactly what algorithms produced it.

• Flight parameters. Altitude AGL, ground sample distance (GSD), frontal/lateral overlap percentages, platform and sensor used. Example: “DJI Matrice 350 RTK with Zenmuse P1, 35mm lens. 80m AGL, 2.1 cm/px GSD, 80/70 frontal/lateral overlap.” This information lives in your post-flight QA log. Copy it into the accuracy statement.

• Positioning method. “GCP-controlled with RTK base station on known control point” or “PPK-corrected using CORS station COPR, baseline 12 km.” The positioning method determines the error budget. A client evaluating accuracy needs to know whether positions were autonomous (meter-level), RTK/PPK-corrected (centimeter-level), or GCP-controlled (centimeter-level with independent validation).

• Date of acquisition. The flight date, not the delivery date. Survey data is time-stamped to the acquisition date. A grading project changes daily. An orthomosaic from March 15 delivered on March 30 represents conditions on March 15. State the flight date prominently.

• Known limitations. Water bodies where the surface model has no data. Dense vegetation where the DSM represents the canopy, not the ground. Areas excluded from the survey due to airspace restrictions or site access. Construction equipment that occluded portions of the surface. State what the data covers and what it doesn’t. A client who discovers a limitation themselves loses trust. A client who reads about a known limitation in your documentation appreciates the transparency.

Format this as a single-page PDF or as the first section of the quality report. Short, factual, no marketing language. This document goes into the project file and may be referenced in engineering reports, permit applications, or litigation. Write it like a professional signed it — because you are, and your name is on it.

File Transfer and Naming

How the files get from your machine to the client’s. The logistics seem trivial until they fail, and they fail more often than the processing does.

Naming conventions. Use a consistent scheme: ProjectName_Deliverable_Date_CRS. Descriptive filenames eliminate ambiguity when the client has 15 drone survey deliverables from different dates in the same project folder.

Examples:

• SiteA_Orthomosaic_2026-05-18_SP-CO-North.tif
• SiteA_DSM_2026-05-18_SP-CO-North.tif
• SiteA_Contours_1ft_2026-05-18_SP-CO-North.dxf
• SiteA_PointCloud_2026-05-18_SP-CO-North.laz
• SiteA_AccuracyStatement_2026-05-18.pdf
• SiteA_QualityReport_2026-05-18.pdf

Include the contour interval in the contour filename. Include the CRS abbreviation in every geospatial file. Include the date in ISO format (YYYY-MM-DD) so files sort chronologically. Never use spaces in filenames — use underscores. Spaces break scripts, command-line tools, and some FTP clients.

Folder structure. Organize the delivery in a single root folder with clear subfolders:

SiteA_Drone_Survey_2026-05-18/
├── Orthomosaic/
│   ├── SiteA_Orthomosaic_2026-05-18_SP-CO-North.tif
│   ├── SiteA_Orthomosaic_2026-05-18_SP-CO-North.tfw
│   └── SiteA_Orthomosaic_2026-05-18_SP-CO-North.prj
├── DSM/
│   ├── SiteA_DSM_2026-05-18_SP-CO-North.tif
│   ├── SiteA_DSM_2026-05-18_SP-CO-North.tfw
│   └── SiteA_DSM_2026-05-18_SP-CO-North.prj
├── Contours/
│   ├── SiteA_Contours_1ft_2026-05-18_SP-CO-North.dxf
│   └── SiteA_Contours_1ft_2026-05-18_SP-CO-North.prj
├── PointCloud/
│   └── SiteA_PointCloud_2026-05-18_SP-CO-North.laz
├── QualityReport/
│   └── SiteA_QualityReport_2026-05-18.pdf
├── README.txt
└── SiteA_AccuracyStatement_2026-05-18.pdf

Everything in one root folder. One ZIP or one shared folder link. The client downloads once and has everything organized. No hunting through email threads for “the other file I sent yesterday.”

README.txt. Include a plain-text README in the root of every delivery folder. Contents: project name, flight date, operator name and company, CRS summary (repeat the full CRS specification from your metadata document), list of deliverables with a brief one-line description of each file, and contact information for questions. Plain text, not Word. Every operating system on the planet opens .txt files without additional software. Every IT department allows .txt files through their email filters.

Transfer method. Size dictates the method:

• Files under 2 GB: cloud storage link — Google Drive, Dropbox, OneDrive. Set the link to allow download without requiring the recipient to have an account on that platform.
• Files over 2 GB: dedicated large-file transfer — Masv.io, WeTransfer Pro, or a client-specified FTP/SFTP server. Masv handles files up to 15 TB with no compression artifacts and provides delivery confirmation.
• Never email attachments over 25 MB. Most enterprise email servers reject them silently — no bounce notification, no error message. The file just disappears.
• Never assume the client’s IT policy allows your preferred cloud storage provider. Government agencies block Google Drive. Construction firms block Dropbox. Financial institutions block everything that isn’t their own approved platform. Ask the client what transfer method their organization supports. Ask during the scope phase, not on delivery day.

Delivery confirmation. After sending the transfer link, follow up with a brief email listing the deliverables, the CRS, and any relevant notes. Ask the client to confirm they can access and open the files. Delivery is not complete when you send the link. Delivery is complete when the client confirms receipt and can open the data. Track this. A simple “Received, files open fine” email closes the loop. If you don’t hear back within two business days, follow up.

Client Communication

The handoff is not a file transfer. It’s a professional communication that sets the context for how the data will be used. The email or cover letter accompanying your deliverables is the first thing the client reads. Make it count.

• Project summary. Two to three sentences: what was flown, when, what’s included. “Drone survey of the 42-acre grading project at 1234 Industrial Blvd, flown 2026-05-04. Delivered as an orthomosaic, DSM, 1-foot contours, and classified point cloud. All data in NAD83(2011) / Colorado North, US survey feet, NAVD88 (Geoid18) vertical.” Short. Factual. Everything the project manager needs to forward to the engineering team without additional context.

• Recommended uses. State what the data is suitable for and what it’s not. “Suitable for preliminary grading design, cut/fill volume calculations, and progress monitoring. Not suitable as a boundary survey, ALTA/NSPS compliance survey, or construction staking control.” This protects both the client and you. The client knows the boundaries of the data’s applicability. You have a written record of what the deliverable was intended for if questions arise later.

• Known limitations. Repeat the key items from the accuracy statement in the delivery email. The client’s project manager may never open the accuracy statement PDF, but they will read the email. Mention: areas excluded from coverage, vegetation type (DSM represents canopy, not bare earth), water bodies with no surface data, any GCPs excluded during processing, and the resulting accuracy figures. One paragraph. Direct.

• Contact for questions. Your name, email, phone number. If the client’s CAD technician has a coordinate system question at 2 PM on a Tuesday, they should be able to reach you directly. Responsive support after delivery is the single biggest differentiator between operators who get repeat work and operators who don’t. Answer the phone. Return the email within a few hours. The technical support you provide after delivery is part of the deliverable.

• Next steps, if applicable. If this is part of a recurring engagement — monthly progress flights, quarterly volumetrics — state the next scheduled flight date. If the client needs additional processing — DTM extraction, cross-sections, change detection against previous flights — mention your availability. This is not a sales pitch. It’s project continuity. The client should know what comes next without having to ask.

The Complete Deliverable Handoff Checklist

Print this. Run through it before every delivery leaves your office.

Download the Deliverable Handoff Checklist PDF

Get the complete deliverable handoff checklist as a printable PDF. File formats, accuracy documentation, coordinate system specifications, and client communication — the difference between a file dump and a professional delivery.

Download the Deliverable Handoff Checklist →

This is part 6 of the 7-part Drone Mapping Checklist Series. Previous: Processing Checklist. Start from the beginning: Why Every Drone Mapping Mission Needs a Checklist — the manifesto that started this series.

This is the final phase article in the Drone Mapping Checklist Series. Six phases. Six checklists. Every step between arriving on site and delivering the final product to the client’s desk. Pre-flight verification, mission planning, GCP deployment, post-flight QA, processing, and now deliverable handoff. If you haven’t yet, download the Master Checklist — all six phases in one printable document. Print it, laminate it, keep it in the truck. The checklist doesn’t make you a better operator. It makes sure your best work actually reaches the client that way.