Photo Delivery Turnaround Time

When a client asks how long delivery takes, they are asking about one span of calendar time. Inside that span there are two clocks running, and they behave nothing alike.

The first clock is work. It runs when you are at the desk and stops when you are not. Culling, editing, retouching, exporting. You can speed it up by working faster, by editing less, or by hiring. It is the clock every photographer already budgets for.

The second clock is waiting. It runs whether or not you are at the desk, and nothing you do at the desk makes it shorter. A client who takes eleven days to choose their album images has added eleven days to your turnaround, and you spent none of them working. A gallery that sits unopened in a spam folder for a week is a week of your promised span gone.

Most published turnaround promises quote the first clock and get judged on the sum of both. That is the whole problem in one sentence. If you promise three weeks because three weeks is what the editing takes, every round trip in the delivery is being paid for out of a budget that does not have room for it.

Here is the delivery half of a normal job, broken into round trips. The column that matters is the third one. A step you control can be planned. A step that hands control to somebody else is the one that decides your safe promise.

Add up the work rows and you get a number in hours. Add up the waiting rows and you get a number in days, sometimes weeks. That asymmetry is why a photographer who edits quickly can still deliver late, and why buying a faster machine does not fix a turnaround problem.

This takes about twenty minutes and it does not require any new software. Open your last five delivered jobs and write down five dates for each: the shoot date, the date you first sent a gallery, the date the client opened it, the date the selection came back, and the date of the final handoff.

Now compute four gaps per job and look at the worst case in each column rather than the average. Your promise has to survive your bad jobs, not your good ones.

Two of those four gaps are the client's. That is the finding most people are surprised by, and it changes what you should promise. A single date that silently includes somebody else's decision time is a promise you have handed to a third party to keep on your behalf.

The cleanest fix costs nothing and is not a software change. Stop quoting one date. Quote a sequence, and name which parts depend on the client.

A staged promise reads something like this: a small preview within a few days of the shoot, the full edited gallery by a stated date, then the retouched selections within a stated number of days after the selection arrives. The last clause is the one that does the work. It converts your most dangerous span from an open commitment into a conditional one, honestly and in advance.

Pair it with a selection deadline in the same sentence. A client given a gallery and no date will take as long as life allows. A client given a gallery and a date to choose by usually meets it, and the ones who do not have been told in writing what happens next.

On buffers: build one, and do not spend it in advance. If your worst recent job took four weeks, promise five and deliver in four. The delivered-early feeling is the cheapest goodwill in this business, and it comes from setting the number correctly rather than working faster.

Be precise here, because this is where most delivery software oversells. A gallery platform cannot edit your photos. If the shoot-to-first-send gap is your worst number, no delivery tool will save you a day, and you should stop reading marketing pages and go look at your culling and your presets instead.

What a tool can remove is round trips. On clientgallery.io, these are the specific ones, and nothing beyond them is claimed.

Read that table as a list of hours and small delays removed, not weeks. The honest summary: this shortens the admin around the edit and gives you visibility into the client's clock. It does not touch the edit itself.

Three cases where you should keep what you have and spend the money elsewhere.

Your bottleneck is genuinely the editing. If shoot-to-first-send is three weeks and everything after it is three days, the delivery layer is not your problem. Changing it will not save you a day. Culling harder, building better presets, or sending the first pass to an editor will.

Your deliverable is not a JPEG. clientgallery.io hosts JPG and PNG. No RAW, no video. If your handoff is master video files or raw negatives, this is the wrong shape of tool and you need a transfer service or a drive.

You are buying a store, not a delivery. If your revenue comes through print sales inside the gallery, the print automation is what you are paying for, and a flat-price delivery tool with no store attached is a downgrade for that business. This page is about the calendar, not about sales.

If the calendar is the problem, the companion pages go deeper on the mechanics: reducing the time you spend delivering covers the work rows in the first table, and how long clients should have to choose covers the single waiting row that costs you the most.

This page states no external figure and no industry average, deliberately. No turnaround survey we could verify was worth putting your contract on, so none is quoted and none should be inferred from the examples above, which are illustrative shapes rather than measurements. The clientgallery.io plan and fair-use figures referenced here, and every product behaviour described in the tool table, were checked against the running product on 12 September 2026.