Importing COD orders from a Google Sheets spreadsheet

The columns: what is required, what helps

A row becomes a lead once the platform can answer four questions: who the customer is, what number to call, which product was ordered, and how much the courier must collect. Everything else is useful but optional.

How a row becomes a lead

Reading is not simple copying. Every row goes through the same checks as a manual entry: the phone number is normalised, the city is matched against the delivery city list — including its spelling variants — the SKU is looked up among the products you are allowed to sell, and the total is compared with the sum of the prices. A row that clears all of this becomes a lead and joins the confirmation queue.

A row that fails one of them is not skipped: it becomes a damaged lead, with its row number and the exact reason. That difference matters in practice, because an integration that quietly skips doubtful rows leaves the seller to discover three days later that sales went missing.

Finally, every processed row is recognised by the content of its mapped columns. One useful consequence: adding or editing a column that is not mapped — an internal note, a tracking column, a colour — re-imports nothing. Another, just as useful: correcting a row that failed is enough for it to be retried on the next pass, with nothing to delete and nothing to ask for.

Rows that arrive badly, and what causes it

The failure reasons are nearly always the same, and they nearly always come from the sheet rather than from the import.

• A phone number turned into a figure — The spreadsheet turned "0612345678" into "612345678" by dropping the leading zero. The column has to be forced to text — this is the leading cause of damaged leads.
• A city written differently — An abbreviation, a typo, a district name instead of the city. Matching covers many variants, but not all; the city is then settled on the call.
• A missing or free-text SKU — The column holds the product name instead of its reference. The lead is damaged, and the reason names which column was read as the SKU.
• A total with a symbol or separator — "299,00 DH" is understood, but a cell holding free text is not. An amount has to stay an amount.
• Two columns with the same name — Two identical headers make the mapping ambiguous; they are told apart by their column letter, but renaming them is better.
• An empty row in the middle — No effect: empty rows are ignored, and the rows after them keep being read.

Why a sheet is a good start and a poor system of record

This is worth saying plainly, because nobody says it at the moment you connect your first sheet: a spreadsheet is an excellent entry point and a very poor system of record. The reasons only appear with volume.

First, a sheet has no state. Nothing in it says who was called, when, with what outcome, or where the parcel is. So the seller adds status columns and updates them by hand — and past a few dozen orders a day, they are no longer up to date. Second, a sheet has no lock: two people working in it at the same time overwrite each other, and an agent can call a customer who was already called.

Third, a sheet does not work out what you earned. The profit on an order depends on the product price, the confirmation fee, the city's delivery fee, and the return fee when the parcel comes back. A formula written by hand survives neither a change of fees, nor a return, nor a partially delivered order.

So the sheet keeps its role, and it is a useful one: it is the collection point, because a form knows how to write into it. What happens after the lead arrives — the call, the parcel, the collection, the profit — belongs to order management, and that is exactly the boundary the import moves to the right place.