← Back

Door two

AI ops and systems

Building what the role needed. Thirteen systems in production, roughly 17,000 lines of Python, all of it written since January 2026 alongside the trading role. They run against Shopify GraphQL and four other platform APIs and share one idempotency layer so nothing can run twice.

How it fits together

One store, six families of systems

System map
System map 01 Order operations 02 Customer care 03 NDIS and B2B billing 04 Merchandising 05 Reporting 06 Shared engineering SHOPIFY STORE ONE CATALOGUE, THREE CHANNELS
System map SHOPIFY STORE ONE CATALOGUE, THREE CHANNELS 01 Order operations 02 Customer care 03 NDIS and B2B billing 04 Merchandising 05 Reporting 06 Shared engineering
Every system reads and writes the same store. The shared layer underneath is what stops them colliding.
Engineering practice

The rules the systems follow

  • Draft first, send second. Anything that reaches a customer is written as an internal draft for a person to release. The only exception is a system that writes internal notes and nothing else.
  • Nothing sends twice. A shared idempotency layer records every send, and seven systems import it rather than each reinventing it.
  • Business rules live in code. A rule the script cannot enforce is not a rule, it is a hope.
  • Preview, then apply. Anything that writes to the store runs read only first and prints exactly what it would change.
  • One definition file for metrics. Every report imports the same definitions, so two reports cannot disagree about what counts as a sale.
  • Credentials live in one place and never inside a script.
The inventory

Six families. Thirteen systems.

Thirteen systems, grouped by what they handle. The 25 rows below are the jobs they do, not thirteen separate products.

01

Order operations

  • Purchase order intake with a reader per customer
  • Preorder allocation, oldest order first
  • Exchange orders with free shipping and tax handled
  • Oversold stock detection across continue selling variants
02

Customer care systems

  • Out of stock handler that finds in stock alternatives
  • Faults workflow that detects the fault type and branches
  • Showroom booking with a form, a calendar invite and a sheet
  • Automated PDF invoicing onto the original ticket
  • Support triage filter, calibrated against real tickets and awaiting release
03

NDIS and B2B billing

  • Seven step NDIS order flow from intake form to invoice
  • Plan manager billing with a maintained plan manager database
  • Payment followup, one ticket per company with invoices attached
  • Payment reconciliation from proof of payment to marked paid
  • Store credit issued against line value
04

Merchandising and inventory

  • Stockout lost sales engine
  • Clearance analysis separating dead stock from slow stock
  • Publishing audit finding active products missing from the store
  • Sizing and fitment data across five brands
  • Price lists for government tenders
05

Reporting

  • Reporting engine with one canonical metric definition file
  • Channel mix, cohort and returns reporting
  • Cost audit that pushed corrections back into the store
06

Shared engineering

  • Idempotency layer reused across seven systems so nothing sends twice
  • Credential handling in one place, never in a script
  • Draft first, send second, as a rule enforced in code
Contact

Ecommerce operations, digital operations and online trading roles in Sydney. Business systems and automation roles as well. Either way the work is the same: run the channel properly, then build the systems that make running it repeatable. Available now and open to talking.

Abhishek Rupapara

Sydney, Australia

Ecommerce operations and systems