Operations console and customer service

Period 2026.07 — 2026.08

Orders, purchasing, sale prices, listings, inquiries, refunds, settlement and cash are viewed and handled across 41 work screens. The interface displays backend responses without calculating amounts or determining workflow stages itself. Customer texts go through a handset on a line deepeet runs itself. Inquiries, returns, exchanges and refunds are grouped into claim cases per order.

An operations console for orders, purchasing, pricing and settlement,
with customer texts and claims linked to each order

Team: Solo
Role: Operations screen designServer relay layerPermissions and business boundariesCustomer textingClaim cases

Next.js 16React 19TypeScriptTailwind CSS 4VercelGoPostgreSQL

Three layers of permissions: menu access, admin‑only actions and a server relay that passes only allowed paths
Switching between several businesses in one console, with orders, accounts and supplier execution isolated per business
A sensitive‑data mode that masks contact details and order numbers on screen, and layouts for narrow mobile screens
A texting gateway that sends and receives customer texts through a self‑run handset line and links them to orders
A blacklist that places new orders on hold when customer details match
Claim handling that groups texts, returns, exchanges and refunds into order‑level cases and gets AI classification suggestions from masked input

Two‑way texting that overseas services could not provide

Problem: Overseas messaging platforms did not support two‑way texts for Korean numbers, so customer replies could not be received.
Solution: A handset on a self‑run line serves as the gateway for texts and picture messages. Every sender address is preserved as received, and blocked senders are dropped before storage.

A relay layer that keeps failure types apart

Problem: If the relay layer lumps errors together, timeouts, user cancellations and transport failures become indistinguishable.
Solution: Timeouts return 504, user cancellations 499 and other transport failures 502. A request ID links to backend records, while URLs, bodies and headers stay out of logs. Network errors are not treated as logouts.

Photo request texts racing a cancellation

Problem: If a customer replied or a cancellation arrived after a photo request was scheduled, an unnecessary text could go out.
Solution: Right before sending, the case and the request are locked in order, and replies, refunds and the handling route are checked again. If the cancellation commits first, nothing is sent; if sending is confirmed first, only the remaining requests are cancelled. PostgreSQL concurrency tests verify both cancellation‑first and send‑first execution.

Return collection stopped by a new amount format

Problem: A channel's return response sent the shipping fee as an amount object instead of a number, so the whole list failed to parse and collection stopped.
Solution: Objects, numbers and numeric strings are all accepted, and failures are isolated per collection method. Diagnostics keep only field names and types. Collection resumed after deployment, and missed events were backfilled without sending alerts again.