A B2B customer portal can let buyers request changes to existing orders without another email thread. But a request to change a quantity or delivery date is not the same as an approved change. Mixing the two can leave customers and fulfillment staff working from different agreements.
This implementation guide focuses on that boundary: how a development agency can build a request, review, and confirmation workflow around your existing order system. For general portal feature selection, use the separate checklist linked below.
Related service: CRM, ERP and web application development- 01Customer signs in
- 02Submits a request
- 03Team reviews it
- 04Customer provides missing information
- 05Both sides see the outcome
SECTION 01
Keep the request separate from the confirmed order
Give each request its own identifier and a reference to the order version the customer saw. Record the requested fields, the reason, supporting information, and who submitted it. Keep the current order unchanged until an authorized person accepts the proposal and the order system confirms the update.
Define a short state sequence such as submitted, under review, awaiting customer response, accepted, or declined. An accepted decision may still be waiting to reach the order system. Show that distinction rather than displaying a new delivery date before the authoritative record has changed.
SECTION 02
Illustrative example: a business customer requesting a change
Imagine a supplier whose customers request changes to ongoing orders. The portal could display the customer's orders, collect a change request against one order, and show whether the request is awaiting review, needs information, or has been accepted. Staff still decide whether the requested change is feasible.
Submitting a request must not immediately rewrite the agreed order. If a customer asks for a delivery date that is unavailable, the team can propose an alternative and record the customer's response. A confirmed change can then update the authoritative order system through an agreed integration or reviewed handoff.
This example is illustrative. Its acceptance test is specific: a customer submits a request, a staff member returns a question, the customer replies, and the final decision is visible to permitted people on both sides.
SECTION 03
Separate requesting authority from approval authority
One customer company may have several users who can view orders but only a designated buyer who may request commercial changes. On your side, order support may ask for information while an operations manager approves the final change. Define these roles explicitly and remove access when a user leaves.
OWASP's authorization guidance supports checking access on each request. Ask for tests that change record identifiers, reuse old download links, and attempt access after a role is removed. The portal must enforce the boundary on the server, not only hide links in the interface.
If a request includes a revised purchase order, protect that attachment under the same customer boundary. Preserve its relationship to the request and the final decision. Do not replace an earlier attachment without retaining enough history for staff to explain what was approved.
SECTION 04
Resolve conflicting changes before applying an approval
Suppose a customer asks for more units while a warehouse employee starts fulfilling the order. Recheck the order version and fulfillment state before applying the accepted request. If the original conditions no longer hold, send the change back for review with an explanation instead of overwriting the newer state.
Show the current value beside the requested value and make staff confirm the intended revision. Use clear labels and error feedback, following the form design principles in W3C's tutorial. Preserve the customer's draft when a validation error occurs; do not imply that a failed submission has been received.
SECTION 05
Keep the first release connected but manageable
Start with one change type, such as a requested delivery-date adjustment before fulfillment. Record an external update reference and reconcile accepted requests against confirmed order revisions. A failed connection should leave visible pending work with an owner, not encourage staff to submit the same update blindly.
Ask the agency to separate interface development, authentication, permissions, integrations, file handling, and support in the proposal. For a U.S. or international customer base, confirm language, time-zone, and data requirements explicitly instead of assuming every region needs identical behavior.
At handover, include account administration instructions, monitoring, recovery steps, and a demonstration using separate customer organizations. A portal is ready for acceptance when the task works end to end and the access boundary has been tested, not merely when the screens look complete.
SECTION 06
Frequently asked questions
Should a customer's portal request immediately change an order?
Only if the agreed business rules explicitly allow it and the order system confirms the change. For reviewed changes, keep the request separate until an authorized decision and a successful update are recorded.
Can the portal connect to our CRM or ERP?
That depends on the existing system's supported interfaces, permissions, and commercial access. Verify those capabilities and field ownership before promising a live connection.
What happens if two people request different changes?
Retain both requests, check the current order version before approval, and route incompatible changes for review. Do not let the last form submitted silently overwrite an earlier confirmed decision.
PRIMARY REFERENCES
Sources and further reading
These references cover the standards, platforms, or published prices discussed in the guide. Worked examples and checklists are our editorial guidance.
- Authorization Cheat SheetOWASP Foundation
- Accessible forms tutorialWorld Wide Web Consortium
EDITORIAL METHOD
About this guide
We use AI to assist with drafting and editing. Catapult AI Work is responsible for the published content. Examples illustrate possible approaches; they are not client case studies unless identified as such.
Budget examples are not Catapult package prices. Check linked provider pages for current fees and plan limits before making a purchase.
Read the editorial policy