The portal tax

Suppliers are not ignoring your portal because they dislike software. They are ignoring it because it asks them to do their job twice. The PO is already in their system. The packing list is already in their system. The portal wants both again, in your format, with your field names, on your schedule, so that your team can see what their team already knows.

That is the portal tax: the work of maintaining a second copy of a record that already exists. It is paid at the supplier's end, in the hours of a person who could be packing, and it shows up in your data as lateness and gaps.

What a portal actually asks for

A portal is a destination. It has a login, a user model, a permission model and a copy of the data. Every supplier, forwarder and CFS operator in the chain gets an account on your destination, and every destination competes with the one they already use. The bigger your network, the more destinations each partner is asked to visit.

Retailers add another layer. A supplier serving five retailers visits five portals, keeps five copies of the same PO in five shapes, and mints labels inside five different rules. The sixth login is not a feature gap. It is a tax on the relationship.

The tax shows up as behaviour

The first symptom is late bookings. Not because the supplier cannot book, but because the booking waits until someone has time to retype. The second is stale pack data: the cartons were packed days ago and the portal learns about them when the shipment is ready to leave. The third is the phone call: the one that starts with did you get the email, and ends with a spreadsheet attached.

None of that looks like a software problem in the monthly report. It looks like supplier performance. The scorecard says a supplier is slow when the accurate statement is that the record asked too much of them.

The portal is not the problem. The second copy is.

A portal is fine when it is a view of the shared record. It becomes a tax when it is a second place where the same fact must be entered. The distinction is not cosmetic: a view reads what the execution layer wrote, and a copy has to be kept in agreement with it.

The design that removes the tax is the one where the record travels with the work. A supplier packs cartons against the retailer's PO in the same chain the retailer sees. A forwarder books against the same cartons the supplier packed. A CFS operator receives against the same cartons the forwarder booked. Each party is scoped to what it is entitled to see, and nobody retypes a fact that already exists.

Adoption in that model is not a change management programme. It is a link. The invited party opens the chain it is already working on, and the work it does is the update. There is no second system to learn because there is no second system.

What to measure

If you want to know what the portal tax costs you, measure four things: the time from packing finished to the booking being visible, the share of cartons that reach a booking without a manual correction, the number of emails per shipment that carry data rather than questions, and the share of invited partners who used the system in the last thirty days without a phone call.

Those numbers are the tax, expressed in units a finance team can argue with. Then compare them against a model where the record is shared. The difference is not a better portal. It is one less copy of the truth.