The B2B Portal Decision at Rehman Textiles
Rehman Textiles is a second-generation fabric wholesaler in Faisalabad with annual revenue of PKR 1.2 billion from 180 retail buyers across Punjab and Khyber Pakhtunkhwa. Orders arrive by phone, WhatsApp and fax, then get keyed into a legacy ledger by six order clerks. The owner estimates a 3.2% order-entry error rate, and average order-to-dispatch time is 11 days. Average order value is PKR 850,000 on 45-day credit. Twenty-two buyers generate 61% of revenue, and two of them have formally asked for API-level stock and price feeds. A local vendor has quoted PKR 6.5 million to build a B2B ordering portal plus PKR 1.2 million a year for hosting and support. The six field agents, who earn commission on orders they personally key in, have told the owner the portal will "cut them out". The owner has three months before the peak wedding-season window and no in-house IT staff beyond one network administrator.
1. Should Rehman Textiles build the portal? Build the case quantitatively and state what evidence would change your answer.
Read the worked answer
Yes, but scope it - the arithmetic supports a pilot, not a full roll-out.
Cost side: PKR 6.5M build amortised over three years is about PKR 2.17M a year, plus PKR 1.2M support = roughly PKR 3.4M a year.
Benefit side: a 3.2% error rate on PKR 1.2 billion of order value means about PKR 38.4M of order value is mis-keyed each year. Even if rework, returns and credit notes cost only 20–25% of that affected value, the annual loss is PKR 7.7M–9.6M. Cutting errors by half recovers PKR 3.9M–4.8M - already above the run-rate cost. Shaving dispatch from 11 days to 7 also pulls cash forward on 45-day terms.
What is missing before committing:
- The cost per error, not just the rate. A wrong shade on a PKR 850,000 order is not the same as a wrong delivery address.
- Whether buyers will actually self-serve. Ask the top 22 for a written commitment to place at least half their orders online.
- Redundancy risk: the vendor is local and small; the 61% of revenue concentrated in 22 accounts cannot sit on an unsupported system.
Decision: approve a scoped build for the 22 key accounts plus API feeds for the two requesters, at roughly PKR 3.5M, and hold the remaining spend until error and adoption data from that pilot justify it.
2. The field agents are the main internal obstacle. How should the owner restructure their incentives, and what is the risk of getting this wrong?
Read the worked answer
The agents' objection is economic, not sentimental. They are paid on orders they key in, so a portal that removes keying removes their income even though the customer relationship is still theirs. No amount of explanation fixes that; only the commission rule fixes it.
Recommended redesign:
- Pay commission on all orders from each agent's assigned accounts, regardless of channel - portal, phone or API. Account ownership, not data entry, becomes the unit of payment.
- Reset targets upward at the same time, so the agent does not simply collect the same commission on unchanged volume.
- Add a scored component for credit collection and range expansion, which are the two things the portal genuinely cannot do.
Risk of getting it wrong:
- If commission stays channel-based, agents will quietly steer buyers back to phone orders and the portal will show false low adoption - the owner will then conclude "buyers don't want it" when the truth is "staff don't".
- If the new rule has no target reset, the company converts a variable selling cost into a fixed entitlement.
- Agents also hold the informal credit-risk knowledge on 180 retailers. Cutting them out of the loop removes the only early-warning system on bad debt.
Measure success as share of account volume ordered online, not total portal logins.
3. Timing: the peak season starts in three months. Recommend a go-live plan and defend the sequencing.
Read the worked answer
Do not go live for all 180 buyers before or during peak season.
Reasoning:
- Peak season is when errors cost the most and when clerks, agents and the warehouse have zero slack to absorb a learning curve. A failure lands on the 61% of revenue concentrated in 22 accounts.
- A three-month build with one network administrator and a local vendor has schedule risk that is near-certain to slip into the peak window.
Sequenced plan:
- Weeks 1–8: build only catalogue, order entry, credit-limit check and the two API feeds. No loyalty features, no analytics dashboard.
- Weeks 9–12: pilot with 6–8 cooperative key accounts at, say, 20% of their order volume, with clerks double-keying as a control. Run it before peak load testing, not during.
- Peak season: freeze. Portal available but optional; agents and clerks fully staffed.
- Post-season: open to the top 22, then the rest, on evidence of error rate and cycle time.
Guardrail: define a rollback trigger in advance - for example, if pilot order error rate exceeds the ledger baseline for two consecutive weeks, the portal is switched off without debate. Committing to the trigger before launch is what stops a bad pilot from being defended as a success.