Custom order tracking portal
A shipment link answers where a parcel is after dispatch. Your customers may need answers much earlier: has the order been accepted, is artwork approved, what is being prepared, and which lines remain open? ALCA builds focused order-status portals around the records and stages your operation can reliably confirm.
Follow the example workflowWhere work stalls
The ERP owns the accepted quantity, a production board owns preparation, and a carrier supplies shipment updates. Customers should see a coherent view with each system’s responsibility defined. A portal should not invent a new order truth that staff must maintain separately.
A “shipped” label can be misleading when four units have left and eleven remain. Buyers need line quantities, shipment associations and the next confirmed step. The order summary must reflect unfinished work even when one package has a valid tracking link.
A polished timeline does not make a delayed source current. Show when the underlying information was last confirmed, distinguish planned dates from actual events and give customers a useful next contact when an update is unavailable.
Input → decision → confirmed result
Read the accepted order and its line identifiers from the designated source. Confirm the customer account, quantities and permitted contacts before exposing the record in the portal.
Show an agreed prerequisite such as artwork approval or specification confirmation when the order needs it. Identify an outstanding customer action without exposing internal commercial notes or another account’s material.
Translate approved internal stages into plain customer language. Display a confirmed milestone or carefully labeled estimate; do not imply exact live production progress from a single task update.
Identify the lines and quantities ready to leave. Prepared does not mean dispatched. Keep remaining quantities and any documented hold visible at the appropriate customer level.
Associate each confirmed shipment with its actual lines and quantities. Show multiple shipments separately and keep the order partially fulfilled until all uncancelled quantities meet the agreed completion condition.
Display supported carrier events for the relevant shipment with their source and timestamp. A carrier’s delivery event applies to that shipment; it does not close unrelated lines or resolve an open return.
Calculate completion using the agreed order rule and display any remaining issue separately. Preserve the history, confirmation documents and support path within the customer’s authorized account scope.
At the decision gate
An order waiting for a specification, approved artwork or a resolved exception gets a clear hold reason that the customer is allowed to see. State who should act next and keep the previous confirmed milestone visible.
Each shipment carries its own line quantities and status. The order remains open while uncancelled quantities are outstanding, even if one shipment is delivered. Readiness, dispatch and delivery are separate facts.
Preserve the last confirmed state, mark that updates are delayed and show its timestamp. Do not advance the timeline or replace an old estimate with a fresh-looking date merely because the portal refreshed.
Records & business rules
Consider an illustrative order with ten display stands and five sign kits. Four stands have been dispatched; the remaining stands are still in production and all sign kits are packed. Open quantity here means ordered minus cancelled minus dispatched. Delivery and returns are tracked separately.
| Order line | Ordered | Cancelled | Dispatched | Open | Customer status |
|---|---|---|---|---|---|
| A · Display stands | 10 | 0 | 4 | 6 | Partially dispatched; 6 in production |
| B · Sign kits | 5 | 0 | 0 | 5 | Packed; awaiting dispatch |
| Order total | 15 | 0 | 4 | 11 | Partially fulfilled; order remains open |
On smaller screens, swipe the table or focus it and use the arrow keys.
Agree what confirmed, in preparation, on hold, ready and dispatched mean for each source. Several internal steps may map to one customer milestone. Keep finance notes, machine details and internal assignments private unless the customer has a reason and permission to see them.
Payment, fulfillment, delivery, cancellation and return status answer different questions. A paid order is not necessarily ready; a fulfilled order may have an open return. Preserve those dimensions and derive a concise summary rather than forcing every event into one linear progress bar.
Keep the source order ID, line IDs, shipment IDs and customer-account mapping together. A purchase-order number supplied by a buyer may repeat across accounts and is not sufficient authorization or a universal record key. Reconcile totals and duplicates before publishing an updated summary.
Distinguish an estimated dispatch date from a confirmed event, with the relevant timezone and last source update. Define how old each source may be before the portal shows a warning. If no dependable estimate exists, show the current stage and next update path instead of a fabricated delivery promise.
When the normal path breaks
Compare source revisions or verified event timestamps where available and reconcile the authoritative record. An older “preparing” event must not overwrite a later confirmed dispatch. Some changes are valid reversals, such as a voided shipment; preserve their reason instead of assuming status can only move forward.
Apply its confirmed quantity to the correct line and retain the balance. Reject or flag impossible totals, such as dispatched quantity exceeding the permitted quantity without a documented correction. Do not mark the whole order delivered because a carrier completed one of several packages.
Keep the last confirmed view available only within the agreed freshness policy and label the delay. Alert the internal owner and retry with controlled limits. If the data is too old to be useful, show that current status is unavailable and offer a support path; do not show an empty order as cancelled.
Bring through the authorized revision, cancellation or corrected quantity from its owner and explain the visible change. A customer change request is a pending request until accepted by the operating system. The portal must not present a requested cancellation or address change as already completed.
Keep the portal’s confirmed order state independent of notification delivery. Retry a failed message without creating a duplicate milestone, and record its result. If a carrier is unsupported or a tracking code is invalid, show the known dispatch fact and an appropriate contact instead of an invented tracking result.
Access & accountability
Check the authenticated contact’s relationship to the customer account on every request, including search, downloads and shipment details. A head-office buyer and a branch contact may need different visibility. Test direct links and guessed identifiers; a filtered order list alone does not protect the underlying records.
The portal reads only approved fields through a controlled server connection. Keep ERP credentials out of the browser and avoid sending hidden internal fields to it. Apply the same account boundaries to cached responses and exported documents so a shared cache cannot reveal another customer’s order.
A read-only first release can answer order questions while preserving existing authority for changes. If cancellation, address edits or reorder actions are added later, each needs validation, permissions and a confirmed destination result. A public link or reference-only lookup is unsuitable for confidential account records without an explicitly assessed access model.
Buy, configure or build
Check its native order history, customer access, partial fulfillment and supported tracking first. Shopify, for example, already documents order-status pages and multiple fulfillments. A business that needs standard shipment visibility may already have the necessary feature. Additional design or configuration can be enough; split shipments alone do not justify custom development.
ERP-connected portal products can provide detailed order, line, shipment and document visibility. Compare their account model, supported ERP version, refresh behavior and customer-facing stages with actual sample orders. Confirm that required data is accessible and that staff can maintain the product before selecting a separate integration layer.
Custom work may fit when pre-shipment stages live in a proprietary production system, a customer hierarchy cannot be represented safely by available products, or several sources need a company-specific view. Define the precise missing behavior. ALCA can build that view while the ERP continues to own orders and existing carriers continue to own their delivery events.
Scope & acceptance
Collect the recurring customer questions, then identify which system can answer each one. Review complete, held, partially fulfilled and cancelled orders. Confirm integration access and customer-account mappings early; a portal cannot repair information that the operation never records or make an unavailable interface accessible.
Document stage meanings, quantity arithmetic, date labels, freshness limits and visible fields. Prototype the partial-order example with staff and representative customer roles. Decide how holds and corrections appear before choosing colors or animation, so the interface communicates a dependable operating rule.
Expose a bounded group of orders and test account isolation, multiple contacts, direct document links, delayed sources and out-of-order events. Compare the portal against source records with the operations team. Keep an internal exception queue and a way to pause publication when reconciliation fails.
Track portal adoption, status-question volume per order, stale records, quantity mismatches and failed notifications. Establish a baseline before rollout and review changes in order mix. Name the person responsible for source mapping when the ERP or production process changes; a portal needs continuing operational ownership.
Relevant ALCA work
AlcaStars demonstrates an account-based platform with business profiles and distinct experiences for consumers, merchants and creators. That is a transferable account-platform pattern. It is not presented as a manufacturing, ERP order-tracking or freight-portal deployment.
Before you decide
Yes, when the relevant system records dependable milestones and you choose to expose them. Production, preparation, specification review or ready-to-dispatch can be useful stages. We avoid presenting an estimated percentage as measured progress or revealing internal notes simply because those fields are available.
Yes, when source data identifies which quantities belong to which lines and shipments. The order summary must retain its open balance, while each shipment has its own tracking information. Existing commerce and ERP portals often support this already, so that capability is checked before recommending a custom build.
There is overlap after dispatch, but this workflow centers the accepted customer order and its pre-fulfillment stages. A freight operation centered on TMS records, dispatch, bills of lading and proof of delivery needs the logistics shipment-portal scope. The two can connect without treating an order and a shipment as the same record.
Connected systems
Plan ongoing account documents, requests and collaboration around the status view.
Assess authorized ERP and production interfaces, ownership and reliable updates.
Give staff a reliable way to record the stages customers need to see.
Connect customer order visibility with the wider commerce operation.
Use the specialist workflow for freight, TMS records and shipment documents.
Set the access boundaries and identify the first useful customer task.
Technical references
Reviewed September 10, 2026. These references describe platform capabilities; access, plans and the final design must be verified for your account. They do not imply a vendor partnership.
Existing storefront status, supported carrier updates, customer verification and multiple fulfillments.
The distinction between payment, fulfillment and return status when evaluating native capabilities.
Start with one workflow
Name the system that owns your orders, the stages customers need to see and where status updates become unreliable. Include whether orders have multiple lines or shipments. A fictional example is useful; customer records and system credentials are not needed.
Map your order status workflowUse our existing project brief. No credentials or customer records needed.