B2B Customer Portal: A Manufacturing Order-Status Pilot

A B2B customer portal is a private website where authorised people from a business customer can view agreed information or request a service. For a manufacturer, a useful first version can show order-line progress, confirmed dispatch details, and approved documents. It should not expose the factory's entire ERP simply because a customer has a login.

This guide helps owners, sales coordinators, and project leads at small manufacturers in India and other markets scope an order-status pilot. The proposed fields and tests are planning recommendations, not a claim that Ploqy sells a ready-made portal or that a portal will produce a particular business result.

Start with one recurring customer question

Collect a few genuine order-update requests your team receives. Are buyers asking whether an order was accepted, which lines have shipped, where to find a dispatch document, or when someone will confirm a revised date? Choose one question with a dependable source record and an accountable owner.

Keep the first release read-only if the purpose is visibility. Price negotiation, order amendments, payments, new quotations, and drawing approvals introduce separate workflows. A portal that displays a requested delivery date must not accidentally present it as a confirmed commitment. Write these exclusions into the brief.

The manufacturing website project brief covers public capability pages and enquiry collection. A private portal serves existing authorised relationships. The manufacturing CRM guide covers internal enquiry ownership; neither should be confused with customer access to operational records.

Define who can see which customer records

Map people to an approved customer account and, where needed, a specific plant or purchasing group. Do not grant access simply because an email address shares a company domain. Decide who verifies invitations, approves additional contacts, removes leavers, and reviews access when a buyer changes roles.

Authentication establishes who signed in. Authorisation decides what that person may access. OWASP's authorisation guidance recommends denying access by default and checking permissions on every request. Apply this requirement to order details, search results, exports, and document downloads, not just navigation menus.

As a concrete platform example, Microsoft Power Pages table permissions distinguish contact-related access from access associated with the signed-in person's account. This illustrates a design choice, not a product recommendation: should a buyer see only assigned orders, or every permitted order for an account? Confirm the required relationships and supported controls with your implementation team.

Publish customer-safe statuses, not raw factory labels

Create a short mapping between internal events and external messages. An internal operation finishing does not necessarily mean the order can ship. Inspection, packaging, documentation, and dispatch approval may remain. Have the relevant business owner approve both the mapping and its wording.

• Order received: received for review, not yet a confirmed delivery commitment.
• Order confirmed: accepted scope and the agreed date are available.
• In progress: work is underway; show only milestones you can maintain reliably.
• Part dispatched: identify the dispatched quantity, unit, line, and shipment reference.
• Fully dispatched: all agreed quantities have a confirmed dispatch record; this is not proof of delivery.

These are suggested labels, not a universal standard. Include an explicit route for a date awaiting confirmation or an order requiring clarification. Keep internal supplier disputes, costing, employee comments, and unapproved explanations out of the customer view.

Show what is known and when it was checked

For every displayed field, name its source, owner, update method, and maximum acceptable delay. A controlled staff update may be enough for a small pilot; an integration can follow when the source and mapping are stable. Avoid calling information live unless the update behaviour supports that description.

Display the last successful source update with an understandable time zone. If an update fails, show that the information is delayed and offer a contact route. Do not replace an unknown shipment quantity with zero, or leave a stale promised date looking newly confirmed. The ERP integration guide explains field ownership and recovery in more detail.

Keep estimated, requested, and confirmed dates separate. A buyer in another time zone should be able to understand the commitment without guessing which local calendar day applies. Agree whether a date refers to factory dispatch or arrival before displaying it.

Treat downloads as part of the access boundary

List the documents customers genuinely need, such as an approved order acknowledgement or dispatch note. Decide who releases each file, which account and order it belongs to, its revision, and how a replacement is identified. Do not automatically publish every attachment from an internal order record.

Require the developer to protect the file itself, not merely hide its link. In an authorised test environment, a document belonging to Customer A must remain unavailable to Customer B even when B knows its address. Avoid placing private documents in a public website folder. Search-engine blocking is not a substitute for access control.

Agree retention and download behaviour with the business owner. Revoking access can prevent future authorised retrieval, but it cannot erase a copy someone already downloaded. Include only information approved for sharing with that customer.

Walk through a split-shipment example

Hypothetical pilot: Customer A orders 100 brackets on order TEST-401. The factory confirms a first dispatch of 60 pieces; the remaining 40 await a confirmed dispatch date. These quantities and references are test data, not a customer case study.

1. The approved buyer sees TEST-401, its line description, ordered quantity, and confirmed first shipment of 60 pieces.
2. The page shows 40 pieces outstanding and marks their dispatch date as awaiting confirmation rather than copying the first shipment date.
3. The released dispatch note belongs to that shipment and account. An internal quality note stays private.
4. A delayed source update leaves the last successful update visible with a delay notice.
5. Customer B's test user cannot retrieve the order or file. Removing A's test user's access also prevents further access under the agreed session-revocation policy.

Ask the buyer and order coordinator to explain the same record independently. If one reads fully dispatched while the other sees an outstanding balance, fix the model before adding more screens.

Use a buyer acceptance checklist

• Account separation: two approved test accounts cannot see each other's orders, search results, or files.
• Access lifecycle: invitations, role changes, expiry, and revocation work for the agreed users and sessions.
• Order meaning: partial shipments, outstanding quantities, units, and date types are unambiguous.
• Document release: only approved files appear; superseded versions are handled deliberately.
• Freshness: a failed update is visible without turning missing data into a misleading status.
• Usability: buyers can read order lines, download permitted documents, and request help on a phone and with a keyboard.
• Recovery: the team can pause publication of updates and identify the last trustworthy customer-visible record.

Run permission tests only on systems and accounts you are authorised to test. This checklist supports business acceptance; it does not replace a professional security review. Agree authentication, session controls, logging, backups, patching, and incident responsibilities before using real customer data.

Compare proposals against the same portal scope

Give each supplier the same sample order, account-access rules, status mapping, document list, update delay, and acceptance tests. Ask which requirements use existing capabilities, which need custom work, and what recurring hosting, identity, support, and maintenance dependencies apply. Do not assume a login page includes these responsibilities.

For a pilot, record repeated status questions, update corrections, failed access tests, and buyer feedback. Compare what your team observes before expanding scope. A portal is useful when customers can trust the limited information it publishes and staff can explain how it got there.

Discuss the workflow through Ploqy Technologies' manufacturing software development service. For public pages around it, see website development for manufacturers. Confirm feasibility, integrations, and security responsibilities during scoping.