CONCEPT Cited by 1 source
Partner portal interactive planning¶
Definition¶
Partner portal interactive planning is a B2B UX shape where partners / merchants / suppliers interact with a vendor-hosted portal that exposes data + decision recommendations + a what-if interactive mode. The portal's three faces:
- Dashboard — KPIs, inventory health, fulfillment metrics, pricing context, replenishment status.
- Batch recommendations — the vendor's recommendation-engine output from the latest scheduled batch run (e.g. daily).
- What-if / interactive mode — the partner can mutate planning parameters (inventory settings, target service levels, budget constraints) and re-run the recommendation engine on demand to see alternative outcomes.
Architectural implications¶
- Dual-mode backend. The recommendation engine must run in both a batch (high-throughput, cost-efficient) mode and an online (interactive, low-latency) mode. Often delegated to the same algorithm behind two different delivery mechanisms — see patterns/async-sqs-lambda-for-interactive-optimisation.
- Consistency invariant. The online what-if results and the batch recommendations must agree when the inputs agree — otherwise partners lose trust in the tool. See patterns/online-plus-offline-feature-store-parity.
- Async UX. Interactive optimisation is often seconds-to-minutes in wall-clock (not milliseconds), so the UX is typically "submit → poll → show result" with a progress indicator, not synchronous request-response.
- Persistence of what-ifs. User-triggered parameter changes are typically persisted so that: (a) subsequent batch runs reflect the user's latest settings, and (b) the portal can show the same recommendation on next page load without re-computing.
Canonical instance (Zalando ZEOS)¶
Zalando B2B partners use the ZEOS partner portal to:
- See a "holistic picture of inventory health and other metrics and KPIs."
- Read daily replenishment recommendations produced by the batch path of systems/zeos-replenishment-recommender.
- Interactively mutate inventory settings; the portal queues a request on SQS, Lambda re-runs the optimiser with multi-threading, result lands in S3 + event-stream notification. The inventory-setting change is also persisted to the offline feature store so the next daily batch run reflects it.