An order is in a message thread. The address is in another message. Someone has packed it, but nobody is sure whether the customer has confirmed the colour.
When this happens, the first thing I would change is the way the order is recorded. You may not need a new application yet. A shared spreadsheet can be a useful starting point if the team agrees on what each row means and keeps it current.
The aim is to answer three questions quickly: what is happening, who is handling it, and what needs to happen next?
Give every order one row and one reference
Use one row per order, with a reference that will not change when the sheet is sorted. A simple sequence such as ORD-001, ORD-002 and ORD-003 works for an example sheet. Avoid using a customer's name as the only identifier, because names can repeat.
If two people create orders, agree on how references are assigned so they do not both use the same number. For a small manual system, one person can issue the reference when an enquiry becomes an order. You can automate that later if it becomes a bottleneck.
Keep the full conversation in its original channel. The tracker should hold the essential facts and the next action, not every message the customer has ever sent.
Start with these columns
- Order reference and date received.
- Customer name or another identifier your team recognises.
- Product, option and quantity.
- Agreed total and a separate payment status.
- Order status.
- Person responsible.
- Next action and follow-up date.
- Last updated date and a short factual note.
Add delivery details only where the people fulfilling the order need them. Restrict access to the sheet, avoid public sharing links and do not put payment passwords or card details in it. A shared workflow does not mean every person needs access to every customer detail.
Use statuses that mean something
Here is a starting sequence: New enquiry, Awaiting confirmation, Confirmed, Preparing, Dispatched, Completed. Keep Cancelled available as a separate outcome.
Write one sentence explaining each stage. “Confirmed” might mean the customer has agreed to the product, quantity and total, with any payment condition met. “Dispatched” should mean the parcel has actually left, not that you hope to send it tonight.
Payment status should be separate. A dispatched cash-on-delivery order and a paid order are not the same thing. Use the words that fit your actual payment and delivery process.
For returns or exchanges, add a clear next action and an agreed way to track the unresolved work. Do not mark an order completed simply to make the list look tidy.
What a useful row looks like
This is fictional sample data:
ORD-014 | Navy tote, 2 pieces | Awaiting confirmation | Owner: Mira | Next action: confirm strap colour | Follow-up: Thursday afternoon | Note: customer asked for a colour photo.
The useful part is not the number of columns. It is that another team member can understand what happens next. “Talked to customer” is a weak note. “Sent colour options; waiting for a choice” gives the next person something to work with.
If you are losing enquiries before they become orders, start with these Bangla reply and follow-up templates.
A short daily routine keeps the sheet useful
At the start of the day, look at overdue and today's follow-ups. Check orders waiting on your team first. Assign anything with no owner. At the end of the day, update changed statuses and give every open item a next step.
Avoid keeping a second “real” list in somebody's personal notebook. If the shared sheet is supposed to be the record, changes need to reach it. Keep a recoverable copy and know who is responsible if a row is accidentally changed.
Try the process with a small set of fictional orders before adding live customer information. Ask a teammate to find an order and explain its next step. If they cannot, simplify the labels before adding more features.
When a spreadsheet stops being enough
Consider a dedicated tool when staff need different access, people repeatedly overwrite each other, or the same information must be entered in several places. Reliable reminders and a clear change history may also justify a more structured system.
That decision should come from a repeated problem you can describe. Read when a business needs a dashboard, or try TapuLab's fictional enquiry demo to see what a more structured workflow can look like. The generated cover image for this article is illustrative, not a client operation.