Order Fulfilment CRM for Console Game Shops

Challenge

The shop sells digital console games, and a purchase can only be completed by signing into the buyer's own PlayStation account. The customer supplies those credentials with the order. So every order needs a person: read the credentials, sign in, make the purchase, mark it done. Scaling that means more people, and the only way to give someone an order was a WooCommerce admin account, which hands them the entire shop, customers, revenue, settings, to fill one order.

Options Considered

1. Give every fulfiller a WooCommerce admin login: rejected. WooCommerce roles are built around running a shop, not around filling a single order; the narrowest role that can still see order details also sees far more than the job requires.
2. Hand orders out manually over spreadsheets or messengers: rejected. Account credentials would end up copied into places nobody controls, and there would be no record of who opened which order, or when.
3. A separate CRM beside the shop, reading orders over the WooCommerce API: chosen. The shop stays the source of truth for orders; the CRM owns the question of who is allowed to see what.

Decision

Build a CRM that pulls orders from WooCommerce as they are created and shows a fulfiller exactly the working set for the order in front of them, nothing else. Four roles carry the access model: administrator, fulfiller, seller and financial manager. An external, untrusted fulfiller gets a scoped account and never touches the WooCommerce admin, which is what made it safe to work with many of them at once. Every action is written to an execution log.

‹›

aA🔒crm.local/home.php

⇧▢+

ЗЗаказыККарточка заказаООчередьРОтчётССебестоимостьПРолиММагазины

Order fulfilment CRM, scrollable snapshot of the demo stand

Order assignment

Navigation

Implementation

A PHP application built on Illuminate components, database, HTTP, validation and events, with PHP-DI for wiring, Phinx for migrations, Monolog for logging and MySQL underneath. It talks to WordPress and WooCommerce over the REST API: a new order appears in the CRM as soon as it is placed in the shop, and the status change back to processed is written to the shop rather than kept in a second system.

The access model is the part that matters. Roles decide which fields of an order a user can read, so the data a fulfiller needs travels no further than the person filling that order, and the execution log records who acted on what.

Outcome

Order handling settled at roughly 10 minutes per order. More importantly, onboarding an external fulfiller stopped being a decision about trust: they get an account scoped to the orders assigned to them, so the shop could run many fulfillers in parallel instead of being limited to the people who could be given admin access.