Plaza OMS

Control orders, exceptions, and fulfillment from one place.

Plaza OMS is the order management module for Plaza, an online retailer of physical consumer electronics like smartphones and laptops. It is designed for operations, customer support, finance, and inventory teams to manage the full order lifecycle with clear status separation, auditability, and exception handling. The module reduces manual reconciliation, prevents fulfillment mistakes, and gives each role the exact tools and permissions needed to work orders safely.

Business Goals

  • Reduce order handling time per exception case by 30% within 3 months of launch.
  • Cut order-payment-shipment reconciliation mismatches by 50% within 90 days.
  • Decrease cancellation and refund processing turnaround time to under 1 business day for standard cases within 2 months.
  • Achieve at least 95% of orders processed without manual intervention by the end of the first quarter after launch.
  • Provide finance with a daily close-ready order, payment, and refund report that is available before the start of each business day.

User Goals

  • Let operations staff find any order quickly by ID, customer, phone, SKU, status, date, or payment method.
  • Help support agents see the full order, payment, shipment, and activity history in one screen.
  • Allow inventory teams to reserve, release, and adjust stock accurately when orders change.
  • Enable finance to approve or reconcile refunds, cancellations, and duplicate payments with traceability.
  • Give fulfillment teams clear next actions for picking, packing, shipping, and failed delivery recovery.

Non-Goals

  • Building a warehouse management system for bin-level picking or pallet movement.
  • Building the customer-facing storefront checkout experience.
  • Automating tax calculation or invoicing beyond passing required data to finance systems.
  • Supporting digital-only products, subscriptions, or service bookings in the MVP.

Nadia, Customer Operations Lead - Nadia manages a small support team handling order issues, customer complaints, and escalations. She needs a reliable way to understand what happened to an order and take the correct next action without switching between multiple systems.

Nadia, Customer Operations Lead

  • As a customer operations lead, I want to search orders by customer name, order ID, or phone number, so that I can answer customer inquiries quickly.
  • As a customer operations lead, I want to see the order, payment, shipment, and activity timeline on one page, so that I can understand the full history before acting.
  • As a customer operations lead, I want role-based controls on cancellation and refund actions, so that only approved staff can make financially sensitive changes.

Reza, Fulfillment Supervisor - Reza oversees packing and shipping for consumer electronics orders. He needs to know which orders are ready to prepare, which are blocked by stock issues, and what to do when shipments fail.

Reza, Fulfillment Supervisor

  • As a fulfillment supervisor, I want to see orders by preparation and shipment status, so that I can prioritize the right queue.
  • As a fulfillment supervisor, I want partial shipment support, so that available items can ship without waiting for the entire order.
  • As a fulfillment supervisor, I want failed delivery cases to reopen the order flow appropriately, so that support and finance can continue the case correctly.

Mina, Finance Analyst - Mina reconciles payments, refunds, discounts, and shipping fee reversals across payment gateways and the finance ledger. She needs deterministic statuses and clear audit trails to close books correctly.

Mina, Finance Analyst

  • As a finance analyst, I want every payment and refund to have a unique transaction reference, so that I can reconcile them with the gateway and ledger.
  • As a finance analyst, I want to see how cancellations affect discounts and shipping fees, so that I can post accurate adjustments.
  • As a finance analyst, I want to review exceptions such as duplicate payments or successful payment without order confirmation, so that I can clear financial holds safely.

Order Listing, Search, and Filters · High priority

  • Provide a fast, searchable order list that supports daily operations and exception handling.
  • Display orders with order ID, customer, created time, order status, payment status, shipment status, channel, and amount.
  • Support search by order ID, customer name, phone number, email, SKU, and payment reference.
  • Provide filters for date range, status combinations, payment method, shipment method, warehouse, and assigned team.
  • Allow sorting by newest, oldest, amount, and last activity.
  • Persist user filter preferences per role so return visits are efficient.

Order Detail and Activity History · High priority

  • Show a single operational view of the complete order lifecycle and all related events.
  • Show order header, line items, pricing breakdown, discount allocation, shipping fee, taxes if applicable, and customer contact data.
  • Show separate timelines for order events, payment events, shipment events, and manual interventions.
  • Capture who performed each action, when it happened, and the reason code or note.
  • Expose linked records for payment attempts, shipment labels, carrier events, cancellation records, return records, and refund records.
  • Prevent editing of historical records; only append new events.

Lifecycle Status Management · High priority

  • Manage order, payment, and shipment statuses independently with allowed transitions and validation rules.
  • Maintain separate status models for order status, payment status, and shipment status.
  • Define allowed transitions such as created to confirmed, confirmed to preparing, preparing to shipped, shipped to delivered, and delivered to closed.
  • Block invalid transitions unless an authorized exception workflow is used.
  • Support edge cases where payment succeeds before order confirmation or before inventory is reserved.
  • Allow partial shipment to update shipment status while keeping remaining lines open.

Cancellations, Returns, and Refunds · High priority

  • Handle full and partial cancellations, returns, and refunds with clear effects on inventory and financial records.
  • Support full cancellation before shipment and partial cancellation at line-item level where policy allows.
  • On cancellation before pick/pack, release reserved inventory back to available stock.
  • On cancellation or return, reverse discounts and shipping fees according to configurable business rules and reason codes.
  • Support full refund, partial refund, and refund hold states with gateway references.
  • Require finance approval or system rules for sensitive refund scenarios, such as duplicate payment or post-shipment return adjustments.

Roles, Permissions, and Reporting · Medium priority

  • Restrict actions by role and provide essential reporting for operations and finance.
  • Provide role-based permissions for viewing, editing, cancelling, refunding, and closing orders.
  • Support at least these roles: operations agent, fulfillment supervisor, finance analyst, and admin.
  • Limit reporting to actionable reports for open orders, exception backlog, failed deliveries, cancellations, and refund aging.
  • Allow CSV export for approved roles only.
  • Log all permission-denied attempts for audit review.

Operational Entry Point

  • User signs in through Plaza staff SSO and lands on the order list tailored to their role.
  • The system shows default filters based on the user’s team, such as open exceptions or today’s shipments.
  • User searches or filters to find the target order in under 10 seconds for common cases.
  • User opens the order detail view and sees the latest status, recent events, and recommended next action.
  • User completes an action such as confirm, cancel, refund, or mark shipped, with validation and audit logging.
  • The system confirms the update and refreshes related payment, shipment, and inventory records within the same session.

1. Find the order

  • Users start with a searchable list and narrow the result set using business-relevant filters.
  • Search must support partial matches and exact order ID lookup.
  • No result state should suggest alternate identifiers and recent history.
  • Filters must combine without losing list performance.

2. Review lifecycle state

  • The order detail page presents separate but linked status tracks for order, payment, and shipment.
  • Show the latest state first, then the full event history below.
  • If statuses conflict, surface a warning banner with the reason and owner team.
  • Readonly users can inspect but not modify the record.

3. Take an operational action

  • Authorized users can confirm, reserve, cancel, ship, refund, or escalate based on policy.
  • Each action requires validation against current status and role permissions.
  • Show required reason codes for cancellations, returns, failed delivery, and exception overrides.
  • Prevent duplicate actions by locking the latest transaction during submission.

4. Handle exceptions

  • The system detects and routes abnormal cases such as payment success without confirmation or duplicate payment.
  • Create an exception state with ownership, timestamps, and recommended resolution path.
  • Support manual resolution with comments and full audit trail.
  • Keep financial and fulfillment records consistent even when one subsystem fails temporarily.

5. Close and reconcile

  • Once delivery, refund, or cancellation is completed, the order can be closed and reported.
  • Closure requires all dependent records to be in terminal or approved pending states.
  • Closed orders remain searchable and exportable but cannot be edited.
  • Reconciliation views should show outstanding mismatches for finance follow-up.

Advanced Controls and Edge Handling

  • Partial cancellation of individual line items with proportional discount and shipping fee allocation.
  • Partial shipment with remaining lines left open and visible to fulfillment.
  • Duplicate payment detection with automatic flagging and finance review queue.
  • Failed delivery reattempt workflow with carrier update history.
  • Manual exception override for authorized supervisors with mandatory reason and audit trail.

Interface Principles

  • Dense but readable tables with sticky columns for order ID, status, and last update.
  • Color coding for order, payment, and shipment statuses with accessible contrast and text labels.
  • Timeline view optimized for scanning recent events and escalations.
  • Keyboard navigation and screen-reader support for high-volume operations use.
  • Fast initial load and incremental data fetch so list pages stay responsive under heavy usage.

Nadia receives a customer call asking why a laptop order is stuck. She searches the order number, opens the detail page, and immediately sees that payment succeeded but inventory reservation failed because one item was oversold. The timeline shows exactly when the mismatch happened, who touched the order, and what action is available next.

She routes the case to fulfillment, where the supervisor reserves replacement stock and moves the order to preparation. Finance later sees the same event trail, confirms there is no duplicate charge, and approves the final settlement. Instead of three separate follow-ups across chat, spreadsheets, and gateway dashboards, Plaza OMS gives the team one source of truth and a clean path to resolution.

User-Centric Metrics

  • Median time to locate an order from the list page is under 10 seconds for common searches.
  • At least 90% of standard cancellations are completed without handoff between teams.
  • At least 95% of order detail views include a complete visible history for payment, shipment, and manual actions.
  • At least 85% of exception cases are resolved from the order detail screen without opening an external tool.

Business Metrics

  • Reduce manual reconciliation effort for order exceptions by 30% within 3 months.
  • Increase successful same-day resolution of customer order issues by 20% within 90 days.
  • Reduce refund processing backlog by 25% within the first quarter after launch.
  • Improve order lifecycle data completeness so finance close requires fewer manual adjustments month over month.

Technical Metrics

  • 99.9% monthly uptime for the order management service.
  • P95 order list and order detail response time under 2 seconds for standard queries.
  • All state-changing actions recorded with immutable audit events and actor identity.
  • Zero unauthorized state transitions in production after release, measured by audit logs and validation failures.

Tracking Plan

  • order_list_viewed with role, filters applied, and result count
  • order_searched with search type, query length, and match success
  • order_detail_opened with order status, payment status, and shipment status
  • order_action_submitted with action type, reason code, and role
  • order_action_succeeded with duration and downstream systems touched
  • exception_created with exception type, source system, and owning team
  • refund_or_cancellation_completed with amount, fee impact, discount impact, and settlement status

Technical Needs

  • Backend service for order orchestration using a transactional API layer, ideally Node.js or Java with PostgreSQL.
  • Event-driven architecture for status changes using Kafka or AWS SNS/SQS to decouple payment, inventory, and shipping updates.
  • Read-optimized search index using Elasticsearch or OpenSearch for fast filtering and lookup.
  • Immutable audit log storage in PostgreSQL append-only tables or a dedicated event store.
  • Role-based access control integrated with the company identity provider.
  • Background workers for reconciliation, retries, and webhook processing.
  • API idempotency keys for state-changing operations to prevent duplicate actions.

Integration Points

  • Payment gateway such as Stripe, Adyen, or a local acquirer with webhook support.
  • Inventory service or ERP inventory feed for reservation and release.
  • Shipping provider APIs such as DHL, FedEx, Aramex, or local courier aggregators.
  • Finance or ERP system such as NetSuite, SAP, or a general ledger export pipeline.
  • SSO identity provider such as Okta or Azure AD for staff authentication.

Data Storage & Privacy

  • Store customer contact data only as needed for operational use and mask sensitive fields by role.
  • Apply least-privilege access controls and log every sensitive view or export.
  • Retain order and financial audit records according to company policy and applicable tax or accounting rules.
  • Support deletion or redaction requests only where legally permitted, while preserving required financial records.
  • Treat payment tokens and card data as gateway-managed; never store raw card details in Plaza OMS.

Scalability & Performance

  • Optimize for high read volume during support and fulfillment peaks with cached list queries and indexed filters.
  • Use asynchronous processing for webhook events, reconciliation, and report generation to keep the UI responsive.
  • Design list pagination and server-side filtering to avoid loading large order sets into the browser.
  • Implement retry and dead-letter handling for integration outages without blocking the core UI.

Potential Challenges

  • Status drift between payment, order, shipment, and inventory systems can confuse users; mitigate with explicit separate statuses and event timestamps.
  • Duplicate payments may appear when gateway webhooks retry; mitigate with idempotency keys and duplicate-reference detection.
  • Partial cancellation and partial shipment can complicate financial allocation; mitigate with deterministic line-item allocation rules and audit trails.
  • Carrier or inventory outages can delay order progression; mitigate with queued exception states and operator-visible retry controls.
  • Permission mistakes could expose sensitive actions; mitigate with role-based authorization, approval thresholds, and audit logging.

Team & resourcing - Small cross-functional team - 3 engineers, 1 product designer, 1 QA engineer, part-time PM, and shared support from finance and operations.

Phase 1: MVP foundation · Weeks 1–4

  • Core data model for orders, payments, shipments, statuses, and audit events
  • Role-based login and permissions
  • Order list with search, filters, and basic sorting
  • Order detail page with timeline and linked payment/shipment records
  • Initial integration contract stubs for inventory, payment, and shipping systems

Phase 2: Lifecycle execution · Weeks 5–8

  • Confirm, reserve, prepare, ship, and deliver workflows
  • Separate status transition validation and state machine rules
  • Cancellation and refund flows for full and partial cases
  • Inventory release and payment refund event handling
  • Exception queue for payment-success-without-confirmation and insufficient stock

Phase 3: Operational resilience · Weeks 9–12

  • Partial shipment support
  • Failed delivery handling and reattempt flow
  • Duplicate payment detection and finance review queue
  • Essential operational reports and CSV export for authorized users
  • Improved audit visibility and reconciliation views

Phase 4: Hardening and rollout · Weeks 13–16

  • Performance tuning for search and detail pages
  • Monitoring, alerting, and dead-letter recovery
  • UAT with operations, fulfillment, and finance teams
  • Documentation for business rules and exception handling
  • Controlled rollout with feature flags and rollback plan

Paste this into Cursor, Bolt, Lovable, or v0 to start building.

Build an Order Management module for Plaza, an online retailer of physical consumer electronics (smartphones, laptops, accessories). Create a production-ready internal web app for operations, fulfillment, finance, and support teams.

Use a modern stack: Next.js 14 with TypeScript, Tailwind CSS, shadcn/ui, PostgreSQL, Prisma, and a lightweight event log pattern. Include role-based authentication with SSO-ready auth scaffolding, server-side filtering, and an audit trail for all state-changing actions.

Primary screens:
1. Order list page with search, filters, sorting, pagination, saved filter state per role
2. Order detail page with order header, line items, pricing, customer info, separate order/payment/shipment statuses, and activity timeline
3. Exceptions queue for payment-success-without-confirmation, insufficient stock, duplicate payment, partial shipment, failed delivery
4. Finance view for refunds, cancellations, shipping fee reversals, and reconciliation status
5. Admin settings for roles, reason codes, and allowed status transitions

Core workflows:
Users can search orders by order ID, customer name, phone, email, SKU, or payment reference. They can view separate statuses for order, payment, and shipment. They can perform authorized actions such as confirm order, reserve inventory, cancel full or partial order, create refund, mark shipped, mark delivered, and resolve exceptions. Every action must create an immutable audit event with actor, timestamp, reason code, and before/after state.

Business rules:
Maintain separate status models for order, payment, and shipment. Allow only valid transitions. Support full and partial cancellations, returns, and refunds. On cancellation before shipment, release reserved stock. Track discount and shipping fee effects on refunds and cancellations. Support partial shipments without closing the entire order. Detect and flag duplicate payments and successful payment without order confirmation.

Data model should include: Order, OrderLine, Customer, Payment, Shipment, InventoryReservation, Refund, Cancellation, Return, AuditEvent, User, Role, Permission, ExceptionCase, and StatusTransitionRule.

Build API routes, database schema, seeded demo data, and polished UI states for empty, loading, error, and permission-denied cases. Add analytics event hooks for list viewed, search performed, detail opened, action submitted, action succeeded, and exception created.

Acceptance expectations: fast search, clear status separation, complete audit history, safe permission checks, and deterministic handling of cancellations, refunds, partial shipments, and delivery failures.

Business Idea

Act as a Senior Product Manager specializing in ecommerce. Create an implementation-ready PRD for the Order Management module of “Plaza,” an online retailer selling physical consumer electronics such as smartphones and laptops. Write the PRD in Persian for the design, engineering, operations, and finance teams. Before writing, ask up to five essential questions about the business model (direct retail or marketplace), current problems, payment methods, inventory and fulfillment operations, and MVP constraints. Wait for my answers. Label remaining unknowns as assumptions or open decisions. Include the problem statement, goals, users and roles, MVP scope and exclusions, core workflows, business rules, prioritized requirements, and testable acceptance criteria. Cover: - Order listing, search, filters, details, activity history, and role-based permissions. - The order lifecycle: placement, payment, inventory reservation, preparation, shipping, and delivery. - Separate order, payment, and shipment statuses, with clear transition rules. - Full and partial cancellations, returns, and refunds, including their effects on inventory, discounts, and shipping fees. - Key exceptions: successful payment without order confirmation, insufficient stock, duplicate payments, partial shipments, and failed delivery. - Dependencies on inventory, payment gateways, shipping providers, and finance systems. Limit MVP reporting to essential, actionable reports. Define KPIs precisely. Avoid unnecessary scope expansion and unsupported policies or numerical targets. End with key risks and decisions required before development.

Make My PRD

Design by The Resonance | Powered by GPC – The AI Transformation Company