Seller Assistant in Veeqo

Read ready-to-ship orders (status awaiting fulfilment), newest first, paged. For each order pull its customer, destination (city/state/country), sales channel, currency, due date, and its allocations (so you can tell which allocation has no shipment booked yet).

For each order's un-shipped allocation, fetch live shipping rates. Quote orders one at a time, not all at once, to stay within the rate budget.

Buying a label posts a shipment for the chosen rate on that allocation.

A full-width table, one row per order: order number + channel, customer, destination, then three coloured rate columns — Cheapest, One day sooner, Fastest — plus a Recommended column, a Diff column (chosen option's price over cheapest), Due date, Est. delivery of the chosen option, a Buy control, and a details button.

Each rate cell shows service name, carrier, price, and estimated delivery; non-cheapest cells also show the uplift over cheapest. "One day sooner" is the cheapest rate arriving at least a full day earlier than the cheapest option.

Recommended is advisory and picks one of the three per order by a fixed rule (favour a modestly-priced faster option, otherwise cheapest). It defaults each row's buy choice but never locks it — the seller can override per row.

Per row: radio choice of which option to buy (recommended one flagged), a "Buy this label" button, and an eye icon opening a popup listing every rate for that order sorted cheapest-first.

Toolbar: search over loaded orders; select-all-shown (capped at 25); select-all / clear buttons. Filter bar: by recommended option, by carrier, by selection state, and a quotable-only toggle. Every column header is sortable, nulls last.

A buy bar showing count selected and combined cost per currency, with a bulk "Buy selected labels" button. Both bulk and per-row buys show an "are you sure?" confirm (real money, can't be undone), then a per-row status (buying / bought + tracking / failed). Cap of 25 labels per bulk buy. A "Load more orders" control pages further.

Read-only except the label purchases. Max 25 selected at once. Rates are re-checked at the moment of purchase, so a shown price can shift slightly.

Top bar: order number + "Order X of N in the ready-to-ship list", with Previous / Next buttons.

A flags row: "Marked as packed" and "Label bought" indicators.

A two-column grid below that (single column on narrow screens):

Left: a product-image box (up to 4 images) above a line-item list (bold quantity ×, name, SKU under it).

Right: a "Ship to" address block, then a "Pre-selected shipping" rate card showing carrier, service, price, estimated delivery, and a promise-met / missed / unknown badge.

Below the grid: three equal-width action buttons — Mark as packed, Buy label, Print label.

Mark as packed — routine write, no confirm.

Buy label — real-money, must show an "are you sure?" confirm with carrier/service/price and a promise-miss warning before purchase.

Print label — sends the shipping-label template to the print queue, scoped to the allocation; only enabled after a label is bought.

Each action updates the current order in place; Next advances the queue.

Read ready-to-ship orders from the orders list (GET /api/v2/orders): filter to status awaiting_fulfillment and batched = false. Page through all results (100 per page) until every page is loaded. Include allocations, allocation line items, and their sellables so each order carries its allocation IDs, line-item count, total unit quantity, and its distinct variants (SKU + title).

Read company users/employees (GET /employees) for the picker dropdown; a failure here only disables the dropdown, it must not break the app.

Three header counts, each a cheap count-only query (page size 1) reading the total from wherever the orders response actually provides it (check meta.page.total_count, meta.total_count, top-level total_count, and the X-Total-Count header, and use whichever is present): (1) ready-to-ship and not batched, (2) batched = true, (3) status shipped.

Singles tab — single-line orders only (one line item, one variant). Bucket by variant. First emit full batches of 30 orders from each variant's own orders. Then pair up leftover variant groups so a batch holds at most 2 distinct variants and at most 30 orders total; if no partner fits, a variant's remainder becomes its own single-variant batch. Sort batches largest first.

Multis tab — multi-line orders (2+ line items). Pack orders first-fit-decreasing so the sum of line items per batch stays at or under 30. An order with more than 30 line items on its own gets its own batch, flagged as over the cap. Sort batches largest first.

Batch names: Singles <YYYY-MM-DD> #<n> and Multis <YYYY-MM-DD> #<n>.

Rebuild proposals from scratch on every load/refresh, and clear any stale selection when you do.

Header card: title, and three KPI tiles — Ready to ship, In batches, Shipped — showing "-" until loaded, with an aria-busy state.

Two tabs, Singles and Multis, each with: a note line summarising how many batches from how many orders; a "Select all" checkbox with a live "N selected" count; a picker dropdown ("Leave unassigned" plus one option per employee); a "Create selected batches" button that stays disabled until at least one is selected and shows a live count in its label.

Batch tiles in a responsive grid (3 / 2 / 1 columns by width). Each tile: a select checkbox, the batch name, a state pill (Created / Not created) once acted on, a meta line (singles: order count, variant count, total items; multis: order count, line-item total, total items, plus an over-cap note if applicable), variant pills for singles, and an expandable list of the orders it contains with links to each order.

Per-tab and per-row error handling with retry; empty states when a tab has nothing to batch.

The two picker dropdowns stay in sync as one shared choice.

Create batches (POST /api/v2/fulfilment_batches) for the selected, not-yet-created tiles only. Each batch sends its name, the collected allocation IDs from its orders, and the assignee ID if a picker is chosen. Show an "Are you sure?" confirmation first, naming how many batches and whether they'll be assigned or left unassigned. Dispatch in internal waves so no single burst is oversized, but create every selected tile. Mark each tile Created or failed individually, drop created tiles from the selectable set, toast the totals, and refresh the header counts after.

Read-only everywhere except the batch-create write; no other data is modified.

Single-warehouse rule: create one batch per proposal with all its allocation IDs and let Veeqo infer the location from the first allocation; if a proposal spans warehouses Veeqo rejects it, so surface that per row rather than pre-splitting.

Never show a cap or "we only did N" to the operator; every selected tile must be created.

accent #406885, accent-strong #1E313E, accent-tint #AAC5D8, accent-soft #EAF1F6. Use the design-system tokens (op-surface, op-border, op-ink-muted, op-radius-md, op-size-base etc.) for everything else so it sits inside the standard card and spacing system.

Grid of 3, minmax(120px, 1fr) columns, gap of one base unit.

Each tile: 1px solid op-border, op-radius-md corners, padding one base unit, and a background of linear-gradient(180deg, var(--op-surface) 0%, var(--accent-soft) 140%).

A 4px accent bar down the left edge via a ::before (position absolute, left/top/bottom 0, width 4px, background accent).

Label: op-ink-muted, 0.72rem, uppercase, letter-spacing 0.06em, weight 600.

Value: 1.9rem, weight 700, accent-strong, line-height 1.1, font-variant-numeric: tabular-nums.

display: inline-block, border-radius 999px, padding 3px 10px, font-size 0.78rem, weight 600.

Background accent-tint, text accent-strong, small right and bottom margins so they wrap cleanly.

Same 999px rounded shape, 3px 10px, 0.78rem, weight 600.

Created uses the success tint/strong tokens, failed uses the danger tint/strong tokens, pending uses the info tint/strong tokens.

1px solid op-border, op-radius-md, padding one base unit, subtle 0 1px 2px rgba(30,49,62,.05) shadow, overflow-wrap: anywhere so long SKUs don't overflow.

Selected state (checkbox checked): accent-coloured border, a 0 0 0 2px var(--accent-tint) glow ring plus the base shadow, and a soft linear-gradient(180deg, accent-soft 0%, surface 60%) wash. Drive it off .batchItem:has(.batchCheck:checked).

Responsive grid: 3 columns default, 2 under 820px, 1 under 540px; full-width notes and empty messages span all columns.

Flex row, 2px bottom border on the strip, each tab a borderless button with a 3px transparent bottom border that turns accent when selected (aria-selected="true" → accent-strong text, accent underline). Hover tints the background accent-soft.

accent-strong, ~1.2rem, letter-spacing -0.01em. Spinners: 2px border ring with an accent top-colour, and respect prefers-reduced-motion (drop the animation).

One bin at a time, not the whole warehouse at once. The staff member advances through bins in sequence.

Within a bin, one card per item, laid out for reading at arm's length on the floor: large product name and SKU, large text, generous spacing, big touch targets.

A number input per item for the physical count, with large plus/minus buttons as well as direct entry so it's usable one-handed.

As a count is entered, show the difference between the counted figure and the system figure (e.g. "System 40, counted 37, short 3"), with the gap visually flagged (colour/label) so discrepancies stand out on the spot.

Progress through the walk (which bin you're on, how many left).

A summary/reconcile view before saving, listing every item where the count differs from system stock.

Mobile/tablet-first: large fonts, high contrast, big buttons, minimal chrome, readable in a warehouse aisle.

Remember progress across a refresh or reopen so a half-finished walk resumes where the staff member left off, without caching a stale copy of stock data.

One warehouse per session.