Most mapping jobs are finished long before they are delivered. The capture is done, the model is processed, the report is written — and then the handoff turns into a zip file, a drive folder, and a follow-up email explaining which file is the one to open.
That last mile is where jobs lose clarity. Clients cannot open a raw LAS file. Orthomosaics arrive without context. 3D models sit next to supporting PDFs that nobody can find later. The work is excellent. The delivery is not.
What clients actually need
A client rarely needs every intermediate product from the processing machine. They need a way to see the site, understand what was captured, and return to the same record later.
That usually means:
- A georeferenced map they can pan and zoom without GIS software
- A 3D view of the mesh, splat, or point cloud when the job requires it
- Imagery, video, or panorama context for the same location
- The report, CAD sheet, or notes that interpret the capture
- One place to return when a question comes up six weeks later
If those pieces live in different tools, the client is not receiving a project. They are receiving a scavenger hunt.
Why generic file transfer falls short
Dropbox, WeTransfer, and email are fine for moving bytes. They are a poor substitute for project delivery.
Typical failure modes:
- The client cannot open LAS, LAZ, E57, or a tiled 3D dataset.
- Folder names make sense to the operator and to nobody else.
- The “final” ortho is sitting next to three earlier exports.
- There is no in-browser view, so the first reaction is another software install.
- The link expires, the folder is copied, and nobody knows which copy is authoritative.
File transfer answers “did it arrive?” Project delivery answers “can they use it?”
A cleaner handoff sequence
1. Decide the client-facing set
Before you export, list the rooms the client will actually open. A drone mapping job might be an orthomosaic, a PDF report, and a few site photos. A reality-capture job might be a point cloud, a mesh, and annotated views. Everything else stays internal.
2. Keep the formats in their native role
Do not flatten a spatial dataset into a screenshot just to make it shareable. Keep the ortho as an ortho, the cloud as a cloud, and the report as a report — then present them together. Screenshots are supporting context, not the deliverable.
3. Put the job in one project
The client should receive one link to the project, not a list of viewers and folders. Maps, models, media, and documents belong to the same site record so the conversation stays attached to the work.
4. Check the experience before you send it
Open the share as a client would. Confirm the default view, the labels, and that the files you intended to hide are actually hidden. Delivery is a presentation, not a dump of the working directory.
What to send instead of a zip
When the job includes more than a single PDF, prefer a workspace the client can open in a browser. That is the difference between transferring files and delivering a mapping project.
SpearAtlas is built around that model: one project for the capture, with maps, point clouds, 3D models, Gaussian splats, imagery, video, and reports available from the same client-facing experience.
The format still matters. The organization matters more.