The decision queue: what the project is waiting on at your end, and what each wait costs in weeks

The article beside this one explains the shape of this package: why you build and advertise at the same time, what a month of development costs in months of campaign, and what you must own at the end.

It describes the project. This one describes the other half, the one nobody discusses before signing: what the project is waiting on at your end. Because a build of this kind almost never stops for want of development — it stops for want of an answer.

The list is short and always the same: the catalogue, the prices and who may change them, the delivery zones, the returns policy, the stock truth, the bank file, the words and the photographs, and the person who approves. None of those lines is technical and none of them appears on a specification.

This article gives that queue in order, says what each wait costs, and explains why we will not give you a project duration.

The article beside this one says the catalogue is the real project. That is right, and it translates into something very concrete: the catalogue is data you hold, not something a supplier produces for you.

What is asked for is not a handsome layout. It is a list where each product has a stable reference, a name that does not change from one row to the next, a category, a price, and — the item most often missing — a decision about what distinguishes two variants of the same article.

The variant question is the one that costs most when it is settled late. Are a size and a colour two products or one product with two options? Both answers are defensible, they produce different sites, and changing your mind after the catalogue has been imported means re-entering the catalogue.

The second point is reference stability. A spreadsheet where the same article is written three ways across three tabs cannot be imported automatically: it has to be read by hand, and that is work nobody planned for because it resembles neither development nor data entry.

The good news is that this work pays far beyond the site. A clean catalogue is what makes product pages, campaigns, marketplaces and cost analysis possible. It is the only line in this queue that keeps its value even if the project stops.

Almost every project treats returns as a text to be written at the end of the build. It is a management decision with consequences for the store room, the till and the accounts, and it has to be taken before the site announces it.

The questions are concrete and can be answered in one meeting: within what period, in what condition, with or without original packaging, who pays for the return, and in what form the customer is refunded — same payment method, credit note, or exchange.

The last is the heaviest and nobody anticipates it. Refunding a card is not the same operation as handing back cash: it goes through the payment system, it leaves a trace, it has a delay, and it requires that somebody at your end has the right to initiate it.

You also have to decide who physically receives the return. A parcel that comes back with nobody knowing which order it belongs to becomes an object in a corner, and the customer waiting for their refund ends up writing publicly — that is the mechanism by which an absent returns policy becomes a reputation problem.

Written beforehand, this policy fits in ten lines and takes a day to build. Written afterwards, it means reworking the checkout, the invoicing and sometimes the accounts, for an identical result.

This is the most underestimated line in the whole queue, and it is nearly always what delays going live. A commerce site needs a photograph and a few lines for each product, and neither exists yet.

The volume surprises people. A hundred references means a hundred photographs and a hundred descriptions; that is not an afternoon, and it cannot be done in one go the night before launch. Nobody estimates it at the start because, in a meeting, "we have the photos" means images exist somewhere.

Quality matters less than consistency, and that is good news. Photographs taken on a phone, against the same background, at the same distance, in the same light, produce a catalogue that looks like a catalogue. Superb photographs taken in ten different conditions produce a site that looks assembled.

For text, the useful rule is to start with the twenty products that carry most of your sales and accept a short description for the rest. A site waiting for a hundred perfect descriptions does not launch; a site launched with twenty good pages and eighty adequate lines fills itself in while trading.

The decision to take is simply this: who does this work, when, and against which list. Given to nobody, it is done by the owner, in the evening, late — which is the scenario this section exists to prevent.

We build the decision queue at the first meeting, with who settles each line, what it blocks, and the date it is expected. We reread it at every progress meeting, before discussing what has been developed.

We do the catalogue work with you rather than for you: we supply the format, we import what can be imported automatically, and we hand you the list of ambiguities to settle — because a variant decided by us is a commercial decision taken by somebody who does not sell your products.

We refuse to give a project duration. We give task durations, the queue, and the freeze date; assembling those three into a calendar presumes knowing your response times, which only you can estimate.

We refuse to start building a checkout while the delivery zones, the returns policy and the stock rule are unwritten. That is not an administrative requirement: those three decisions change the structure of what is built, and taking them afterwards costs a rework you pay for.

And we refuse to write your terms of sale and returns policy for you. We give you the list of points to settle and we format them once settled — but these are undertakings your business makes to its customers, and a supplier who invents them has you signing theirs.