What is the Customer Portal?
The Customer Portal is Orbita’s published web ordering channel for end customers. It lets buyers place demand into the same order core as email and other intake paths — without creating a parallel order system or bypassing release and fulfillment workflows.
Definition
Portal is a demand intake surface scoped to customer identity. Authenticated portal users submit orders that materialize as standard order and order line records inside the supplier’s company workspace. Portal does not own fulfillment, warehouse scans, or invoice posting — it feeds FAOS.
Portal is explicitly not:
- A second order pipeline with different lifecycle rules.
- A CRM Admin or entitlement console (platform governance stays in CRM Admin).
- A warehouse execution or finance posting interface for customers.
- A public anonymous catalog that leaks other customers’ pricing.
Customer-specific pricing on portal orders must resolve from customer price authority when configured — not from generic inventory defaults presented as customer price.
Portal complements — does not replace — human sales relationships: negotiated exceptions still route through supplier staff inside Office when policy requires approval before release.
Purpose
B2B buyers increasingly expect self-service reordering. Portal reduces email parsing load while preserving operational discipline: every portal order should be releasable, traceable, and invoice-eligible under the same rules as internally entered demand.
- Give repeat customers a controlled ordering experience.
- Reduce manual re-keying from phone or messaging apps.
- Preserve customer isolation — each buyer sees only their scope.
- Improve intake quality with catalog and quantity validation at source.
Workflow
Customer authenticates to portal → selects products and quantities → submits order → FAOS creates normalized order records → release and procurement bridges run → warehouse and delivery workflows proceed → invoice and AR follow finance policy. Portal’s job ends at clean intake; downstream authorities unchanged.
Entitlement determines whether portal is enabled for a company. Disabled modules must not appear as ghost entry points on public marketing alone.
Catalog and pricing visibility
Suppliers configure which SKUs portal buyers may order. Customer-specific price lists apply when the buyer relationship requires negotiated pricing — portal must not expose another customer’s contract rates. Stock availability signals may be shown when configured, but authoritative availability for fulfillment still flows through operational modules after order release.
Status and notifications
Order status progression follows FAOS and downstream workflows. Portal may present status views appropriate to customers — delivery pending, shipped, invoiced — without granting warehouse or finance mutation tools.
Email confirmations and portal UI should use consistent stage vocabulary aligned to order-to-cash playbooks — reducing “your order is processing” ambiguity when finance awaits delivery proof.
Example
A restaurant chain logs into their supplier’s portal every Monday and submits a standing order. FAOS receives it alongside email-derived orders in the same queue. Shortage on one SKU triggers procurement linkage. Pick and delivery proceed in WMS and Office. The customer tracks status through published portal or supplier communication — not by public FAQ reading private data.
If the same customer also sends Excel orders by email, both channels converge to one queue — preventing duplicate fulfillment from parallel pipelines.
A buyer asking “change my delivery address on yesterday’s order” requires authenticated support inside the supplier workspace — portal public FAQ cannot perform the change.
FAQ
- Is Portal on every plan?
- Depends on entitlement and published plan features — confirm on pricing comparison.
- Can portal customers see supplier stock?
- Only what the supplier configures to expose — scoped to their relationship.
- Does portal replace email orders?
- No. It is an additional channel converging to the same order core.
- Who owns portal catalog truth?
- Supplier company product and customer price masters in Office — not buyer-entered free text.
- Can portal users see supplier finance?
- No. AR/AP remain supplier-internal authenticated modules.
- Does portal work on mobile?
- Browser-based ordering — designed for buyer convenience, not WMS floor scan substitution.
Misconceptions
“Portal orders skip release.” False. They enter the same pipeline.
“Portal is a second ERP for customers.” It is ordering intake — not full supplier ERP exposure.
“Anyone with the link can order.” False when authentication is required — open URLs without login are not the default model.
Portal success is judged by reduced re-keying and fewer intake errors — not by maximizing SKUs visible without supplier curation.
When It Matters
Portal matters when repeat B2B order volume is high enough that email parsing becomes a bottleneck — but operational control must remain tighter than a generic ecommerce storefront.
Food service distributors, industrial consumables suppliers, and OEM component vendors with standing weekly rhythms are typical fits. Pure project-based quoting businesses may rely more on quotations workflow than catalog portal — still within FAOS when enabled.
Security reviews should confirm portal accounts are customer-scoped credentials — not shared supplier admin logins forwarded to buyers.