It matters more than it looks. A mission planned carefully for repeatability and measurement quality, flown clean and processed well, can still land at the client as a mess: a multi-gigabyte file they can't open, a link that only works on your machine, or a file-transfer link that expires in seven days. The delivery stage is what decides whether the client experiences the job as professional.
Where the workflow actually breaks
When processing finishes, everything you made lives somewhere the client can't reach: on your workstation, on a localhost address, or as an orthophoto GeoTIFF several gigabytes in size that ordinary photo software won't open. The point cloud is a .laz the client has no software for. The textured 3D model is an OBJ that falls apart the moment one of its three files gets separated from the others.
The default fallback is to zip the output folder and send it. That is not a delivery at all. You are handing the client your unfinished work and asking them to finish it. They open it, find files they can't read, and email you asking what to do with them. The last stage of a careful workflow ends up being the least careful part of it.
What the client actually needs
Three different people want three different things out of the same job, and treating them as one is the most common delivery mistake:
- The client who commissioned the flight wants to see the site, understand what you found, and show it to someone else. They need a viewer and a report. Most don’t have GIS software and won’t be installing any.
- The surveyor or engineer downstream wants georeferenced data to work with: the orthophoto as a GeoTIFF, the DSM, sometimes the point cloud, with the coordinate system stated.
- You, eighteen months from now, want the full output and the processing settings so a repeat flight is comparable. That's an archive, not a delivery.
Sending the full export to the client who commissioned the flight only looks generous. You are passing the work along to someone who cannot use it. The client who commissioned the survey needs the smallest, clearest subset, and that's exactly the part that's easiest to get wrong.
What a professional delivery looks like
A professional delivery meets a short list of conditions:
- One link, not six attachments across three emails.
- A viewer the client can pan, zoom and, for a survey, measure in, directly in the browser, with nothing to install.
- The quality report and the relevant images alongside it, in the same place.
- Something that opens on a phone as well as on a desktop.
- A link that still works next year, not one that expires in a week.
- Branded to you, the operator, not a generic file-sharing page.
Meet those and the client never has to ask you what to do with the files. It's also the part of the workflow with the fewest dedicated tools, which is why so many operators rebuild it by hand on every job.
Closing the gap: the delivery layer
Processing software makes the data. It does not package that data for a non-technical client, and it was never meant to. That packaging is a separate step, and it's worth treating as one.
In practice it means: publish the 3D model to a web viewer the client can open in a browser, export the orthophoto as a browsable map the client can open, and collect those alongside the quality report and a selection of images, then put the whole set behind one access-controlled link.
A dedicated client-delivery platform handles this last step. It doesn't process anything itself. It takes the viewer links you already have, holds the report and images next to them, and gives the client one branded link with a single access code instead of a folder of files. For inspection work, some of these tools include an in-browser thermal viewer, so the client reads temperatures directly without specialist software. A few platforms now target this stage specifically. DronePortal is one; it is worth comparing against whatever fits your own delivery volume and hosting requirements.
Where it fits after UgCS
The delivery stage is the end of a chain that starts at flight planning. The repeatability and measurement quality you build into a mission in UgCS (terrain-aware routes and consistent overlap, the sensor path calibrated to the job) are what make the result worth delivering well in the first place. A sloppy delivery wastes a well-planned flight; a clean delivery lets that quality reach the person who paid for it.
So the full workflow reads: plan in UgCS, fly, process in your photogrammetry software, deliver through a client portal. Each of the first three stages has a dedicated tool. The fourth deserves one too,and the measurement quality only survives the whole chain if the delivery preserves it: the coordinate system stated, the report attached, and a viewer the client can actually measure in.
The delivery step is also where planning decisions become visible. If a corridor mission was flown with consistent altitude and overlap, the orthophoto the client scrolls through is even edge to edge, and a measurement taken in the viewer holds up. If overlap dropped on one leg, that is where the model thins and where a client's measurement goes soft. Whatever coordinate system you set at planning has to reach the delivered file intact, or the surveyor downstream is stuck.
FAQ
Do I need to reprocess anything to deliver this way?
No. Delivery is a separate stage after processing. You keep your existing workflow in UgCS and in your processing software exactly as it is, and add the finished results: the viewer link, the report, the images. Nothing is recomputed and none of your processing settings change.
What does the client need installed?
Nothing beyond a browser. The point of a delivery layer is that the client opens a link and sees the viewer, the report and the images, on desktop or phone, without GIS software, a specialist app, or a download.
Can I deliver a photogrammetry or mapping result this way?
Yes. You publish the 3D model or orthophoto to a viewer that opens in a browser, then bring that link plus the quality report and images into the delivery. Software that only produces local files needs that one extra publishing step first.
What about large files like point clouds?
Many clients never open it. Keep the point cloud in your archive and send it only to a surveyor or engineer who explicitly asks, with the EPSG code, the height reference, and whether it's classified. A .laz without that information comes straight back.
Is the data hosted in Europe?
Hosting location and data protection matter when the end client is European and the imagery shows their site, so it is worth confirming with whichever delivery tool you choose. DronePortal, for example, is EU-hosted and GDPR-aligned.
This guide was contributed by the team at Droneview.be, which builds client-delivery tooling for drone operators.