Taglinks
GasTag — Internal System Flow (Full Detail)
⬡
GasTag
QR Cylinder Reorder System
INTERNAL — FULL SYSTEM DETAIL
Version 2.0 · May 2026

Contents

1 · Platform architecture 2 · Vendor & QR onboarding 3 · Client lifecycle 4 · Address confirmation 5 · System notes
Diagram 1

Platform architecture

Three-tier structure. Super-admin controls vendor registration and QR batch ordering. Each vendor has an isolated portal. Clients interact via a single QR tag (one per client) that opens their profile — within which multiple appliances and cylinders are managed.

Key model clarification Each client has ONE QR keyring tag linked to ONE client profile. Multiple appliances (stove, geyser, braai etc.) and their associated cylinders are registered within that single profile. Notifications fire per appliance; the reorder form lists all appliances for selection. There is no separate tag per cylinder.
System / automated
Vendor action
Client touchpoint
Super-admin dashboard Registers vendors · orders QR batches (one tag per client) · submits print files · manages notification templates Platform operator only — not visible to vendors or clients Vendor admin portals (one per gas supplier) Client list with appliance breakdown · inbound reorder alerts · delivery confirmation per appliance · usage stats · week+3 flags Vendor A portal Clients + their appliances Vendor B portal Clients + their appliances Vendor N portal Clients + their appliances ··· Client touchpoints (ONE QR tag per client) Single tag links to one client profile · profile holds all appliances and cylinders · scan 1 = registration · scan 2+ = reorder form Client A (1 tag) Profile: stove 9kg · geyser 19kg 2 appliances tracked independently Client B (1 tag) Profile: stove 9kg only 1 appliance tracked Client N (1 tag) Profile: stove · braai · geyser 3 appliances tracked independently Shared notification engine Email + push per appliance · 6-week / 3-week / due-date alerts · week+3 escalation flag · delivery confirmation · stats summary
One tag per client — key principle A single QR keyring tag is issued per client. It opens their full profile. All cylinders and appliances are managed within that one profile. There is no separate tag per cylinder or appliance.
Notifications are per appliance Even though there is one tag, the notification engine tracks and alerts per appliance independently. A stove reminder and a geyser reminder may arrive weeks apart. Each message prompts the client to scan their (single) tag.
Reorder form When a registered client scans their tag, they see all their appliances listed. They select which cylinder(s) they are reordering for. Multiple appliances can be ordered in one scan session.
Notification channels Email and push notifications only. No SMS or WhatsApp. Push requires the client to have the vendor-branded PWA or app installed.
Diagram 2

Vendor & QR onboarding

How a new vendor is activated and how their branded QR keyring tags (one per client, not per cylinder) reach clients. Super-admin driven. The QR code is unique per client and unregistered until first scan.

Super-admin registers new vendor Company name · contact · branding assets · region System creates vendor portal Credentials issued · branded subdomain assigned Super-admin orders QR batch Quantity = expected number of clients for this vendor System generates unique QR codes One per client slot · state: unregistered · linked to vendor · scan 1 opens registration Profile created on first scan only Print-ready file submitted to printer QR code + vendor branding · domed sticker spec for keyring tag Printer produces branded keyring tags Vendor gives tag to client as freebie · one tag per client
One tag per client — not per cylinder The batch quantity ordered equals the expected number of clients, not cylinders. A client with three appliances still only receives one keyring tag. All appliance data lives in the profile that tag unlocks.
QR state: two states only Unregistered (scan → registration form, profile created) and Registered (scan → client profile / reorder form). State changes once on successful registration. No per-appliance QR state.
Diagram 3

Client lifecycle

Full flow from first scan through registration and appliance setup, per-appliance notification cycles, reorder via single tag, vendor delivery confirmation, stats recalculation, and back to next cycle. Notifications fire independently per appliance; the client always uses the same single tag to reorder.

System / automated
Client action
Vendor action
Decision / gate
— REGISTRATION — Client scans QR tag (first time) State: unregistered → registration form opens in browser Client completes registration Name · email · delivery address · notification preference (email / push / both) Appliance 1: type · cylinder size · estimated duration Option to add further appliances now or later via portal Client adds further appliances (optional) Each appliance: type · cylinder size · est. duration — all within same profile System creates client profile + seeds predictions One prediction per appliance using industry avg. for that cylinder size · QR state → registered The following notification cycle runs independently for each appliance within the client's profile — NOTIFICATION CYCLE (per appliance, within one client profile) — System schedules alerts for this appliance Based on predicted empty date for this cylinder size + appliance type 6-week alert (email + push) "Your [appliance] cylinder is due in ~6 weeks — scan your keyring tag to reorder" 3-week alert (email + push) "Your [appliance] cylinder is due in ~3 weeks — scan your keyring tag to reorder" Due-date alert (email + push) "Your [appliance] cylinder is due now — scan your keyring tag to reorder" Reorder received within 3 weeks? no yes Week+3 flag in vendor portal Client flagged per appliance · vendor may follow up — REORDER — Client scans their single QR tag Registered state → client profile opens Reorder form: all appliances listed Client selects which appliance(s) to reorder Client confirms delivery address Pre-filled · editable with permanent-change prompt Client submits reorder Order acknowledgement sent to client Email + push · "order received · delivery est. [date]" Vendor receives reorder alert in portal Client name · address · appliance(s) selected · cylinder size(s) Vendor delivers cylinder(s) — POST-DELIVERY + NEXT CYCLE — Vendor confirms delivery in portal Per appliance · logs date · clears escalation flag if set System recalculates usage per appliance Actual duration vs. history · updates prediction per appliance "[Appliance] lasted X months · next due est. [month year]" — sent to client ↻ repeats per appliance · actual stats from cycle 2+
Single tag, multiple appliance cycles The client has one tag. The system tracks N appliance cycles within their profile. Reminders reference the specific appliance by name. The reorder form shows all appliances so the client can select the one(s) they need.
Prediction model Cycle 1 uses the industry average for that cylinder size. From cycle 2, the client's own actual usage history per appliance drives the prediction. Each appliance builds its own history independently.
Escalation Week+3 flags are raised per appliance. A client could have a stove flagged while their geyser is not. Confirming delivery for that appliance clears only that flag.
Adding appliances Clients can add new appliances at registration or at any time via their client portal. Each new appliance starts at cycle 1 (industry avg. baseline) and builds its own usage history from first delivery.
Diagram 4

Delivery address confirmation

Shown within the reorder form after the client selects which appliance(s) to order. Registered address pre-filled. If the client edits it, a prompt prevents accidental permanent overwrites.

Delivery address step (in reorder form) Registered address pre-filled Client edits the address? no — confirmed yes Client enters new address System asks: permanent change? "Update your registered address too?" yes no Registered address updated New address is new default Registered address kept New address: this order only Client submits reorder Order acknowledged · vendor alerted
UX intent The permanent-change prompt prevents clients accidentally overwriting their registered address when delivering to a temporary location. The prompt fires only when they edit — not on every reorder.
Portal update Clients can also update their registered default address at any time via their client portal, independently of placing an order.
Section 5

System notes & open questions

Prediction engine — cycle 1 Baseline uses industry average for cylinder size. Confirm whether averages are held per size only, or also per appliance type (stove vs. geyser usage can differ significantly even for the same cylinder size).
Push notification infrastructure Push requires a vendor-branded PWA or native app. Supplier to advise on implementation — single shared app vs. per-vendor branded apps.
Multi-appliance reorder in one session The reorder form lists all registered appliances. Confirm whether the client can tick and submit multiple appliances in one session, or whether each is a separate submission.
Escalation timing Week+3 flag raised if no reorder recorded after due-date alert. Confirm: 3 calendar weeks (21 days) or 3 rolling days per business rules?
Address handling — confirmed One-time address overrides at reorder are not persisted. Only explicit permanent-change responses update the registered default. Confirmed as intended.
Tag model — confirmed ONE QR keyring tag per client. Multiple appliances/cylinders managed within one profile. No per-cylinder tags. Confirmed as intended.
GasTag · Internal system specification · v2.0 May 2026 · Confidential