A textile order is not one thing, and that is the automation problem

Where an order actually lives while it is being made

Ask four people in a Faisalabad unit where an order has reached and you will get four defensible answers. The greige register says the fabric left for processing. The processing house says the lot is in the machine. The stitching floor has half of it. The packing hall has a partial. Each of those statements is true, and none of them is the answer the buyer asked for.

The merchandiser is the human integration layer that resolves this. Their day is spent phoning stages, reconciling what they hear, and translating it into something that can be said to a buyer without promising more than the floor can deliver. It works, and it does not survive growth, because a merchandiser can hold five orders in their head and not fifty.

The automation that fits a manufacturing business is stage level rather than order level. Each stage records what it received, what it passed on, and when, at the moment it happens. The order status is then computed rather than assembled by phone, and the question a buyer asks has one answer that everybody can see.

The reason to do this is not reporting. It is that a delivery date becomes calculable from actual stage completion rather than from intention. A lot that has been sitting at processing for three days longer than planned is a delivery problem that is currently discovered in week six and could be visible on day three.

• Each stage records receipt and dispatch quantities at the moment goods move
• Lot numbers carried through every stage rather than renamed at each one
• Planned duration per stage, so an overrun raises itself instead of waiting to be found
• Shortfalls and rejections recorded as they happen, not reconciled at packing
• One computed order status, visible to merchandising without a round of phone calls

The job work problem: half your process is in someone else's building

Very few Faisalabad units own every stage. Weaving may be on contract, processing at an outside house, embroidery or printing somewhere else again. These partners are not going to log into your system. They have their own way of working, and any plan that depends on changing it will fail quietly.

The workable approach meets them where they already are. A lot leaving your gate carries a number. The processing house sends a message when it is received and another when it is dispatched, in whatever mix of language and format they normally use, from the phone they already have. Those messages are read, matched to the lot, and turned into status. Nothing is asked of the partner beyond what they were already willing to do.

This is where the constraint on the technology sits. A message saying the lot is ready is not a status update until it has been tied to a specific lot number with a quantity, and where that link is unclear the system must ask a person rather than assume. A confident wrong status is worse than no status, because production planning will act on it.

Export documents and the discrepancy that costs you the payment

The commercial risk in export documentation is not the effort of producing the documents. It is that a bank examines them against the terms of the credit and will not pay while they disagree. A description that does not match the wording in the credit, a quantity outside the permitted tolerance, a shipment date past the stated latest date, a port named differently on two documents: any of these turns a completed shipment into a delayed payment and an argument.

This is checking work, which is exactly the work people do worst when tired and best when it is mechanical. The terms can be extracted from the credit or the purchase order once. Every document produced afterwards is checked against those extracted terms before submission, and anything that disagrees is raised with both values shown side by side.

The same applies to buyer specifications inside the order. Carton markings, packing configuration, labelling requirements and shade approval references are all stated somewhere in the buyer's documents and are all things a rushed packing hall gets wrong. A checklist generated from the buyer's own instructions is more reliable than a checklist someone typed from the last order for a different buyer.

None of this replaces the documentation team. It removes the class of error that is caused by comparing two documents by eye at eleven at night.

What a factory floor will actually use

Software that assumes a desk does not survive in a production hall. The people who hold the information are moving, their hands are occupied, the noise is constant, and network coverage inside a shed is not what it is in the office. Any system that requires ten fields to be filled will be filled in at the end of the shift from memory, which produces data that looks complete and is not.

What works is short and specific. One message or one scan per movement, with the smallest possible number of values: lot number, quantity, stage, done. Anything else the system should derive for itself. If a value cannot be derived, ask for it later from a supervisor rather than at the point of movement.

Deciding this correctly is most of the design work, and it cannot be done from a specification document. It requires watching a shift, or at minimum a video walkthrough with the supervisor narrating what actually happens rather than what the process says happens.

Working with a firm that is not on your floor

Wobble is an AI automation company based in Karachi and works with Faisalabad units remotely. There is no local office and no local team, which is worth stating plainly given how many suppliers in this category imply a presence they do not have.

For factory work the remote arrangement carries one genuine limitation, and it is the point above. Nobody can design a floor level capture step well without seeing the floor. The way around it is a proper mapping phase at the start: a walkthrough on video with the people who do the work, the actual registers and slips photographed, and the first version deliberately narrow so it can be corrected against reality within weeks.

After that phase, most of the work is configuration, integration and operation, all of which happen in your accounts and are unaffected by where anyone sits. Ownership should be settled before the first build: accounts in your company name, administrator access held by you, and the workflow logic exportable.

When the floor has to change before the software can

If lot numbers are not used consistently, or the same lot gets renamed at each stage, stop and fix that before automating anything. Every workflow described here hangs on one identifier surviving the whole process. Without it, the system will produce confident nonsense.

If your unit runs a small number of large repeat orders for one or two buyers, a well maintained spreadsheet and a disciplined merchandiser will outperform a system for a long time. The case for automation strengthens with the number of concurrent orders and the number of parties involved, not with turnover.

If the real constraint is machine capacity or power availability, better visibility will tell you what you already know and change nothing. Visibility is worth buying when there are decisions you would make differently if you could see, and it is worth asking which decisions those are before commissioning anything.

And if supervisors are measured in a way that makes an honest delay look like a personal failure, the data will be optimistic no matter what system captures it. That is a management problem and it has to be addressed first, or you will automate the reporting of a fiction.

Common questions

How can a textile unit track production automatically?

By capturing movement at each stage instead of asking for order level status. Each stage records what it received and what it passed on, against a lot number that survives the whole process, at the moment goods move. Order status is then computed from those events rather than assembled by phone, which also makes an overrunning stage visible in days rather than weeks.

Our processing and embroidery are done by outside units. Can that be included?

Yes, provided the design does not require them to adopt your software, which they will not do. The practical approach reads the messages they already send from the phones they already use, matches them to a lot number, and turns them into status. Anything that cannot be matched confidently is held for a person rather than guessed at, because production planning will act on a wrong status.

Can automation check export documents before we submit them?

It can do the comparison work, which is where the errors come from. Terms are extracted from the credit or purchase order once, and every document produced afterwards is checked against them for description wording, quantity tolerance, dates and port naming, with disagreements shown side by side. A person still signs off. What goes away is the class of error caused by comparing documents by eye late at night.

Will workers on the floor actually use it?

Only if it asks for very little. One message or scan per movement with the fewest possible values, and everything else derived by the system. Anything longer gets filled in at the end of the shift from memory, which produces data that looks complete and is not. Getting this right requires watching a shift rather than writing a specification.

Do you have an office in Faisalabad?

No. Wobble is based in Karachi and works with Faisalabad units remotely, with no local team. The one place this genuinely costs something is designing floor level capture, which is why the first phase is a mapping walkthrough on video with the people doing the work, and a deliberately narrow first version that gets corrected against reality quickly.

What should we fix before starting?

Lot identity above everything else. If a lot is renamed or renumbered between stages, no amount of software will reconcile it. After that, agree planned durations per stage so overruns can raise themselves, and make sure supervisors are not penalised for reporting an honest delay. Optimistic data is a management problem that automation will faithfully preserve.