369+beds delivered
8communities
20kgplastic diverted per bed
← Back to Wiki

Community Goods Tracking Model

How we track essential goods through their full lifecycle — from deployment to replacement — so communities get better products and less money leaks out.

Why Track?

In remote communities, essential goods like beds, washing machines, and fridges fail at alarming rates. One Alice Springs provider sells $3M/year of washing machines into remote communities — most end up in dumps within months. Without tracking, the same failing products get re-procured endlessly.

Our tracking model answers six questions:

  1. What is in community right now?
  2. Who bought or supplied it?
  3. How long does it last?
  4. What fails, and why?
  5. What gets repaired, replaced, or dumped?
  6. How much money leaks out through repeat procurement of low-lifecycle products?

First Principles

Track the product, not the order
An order is a financial event. A product is a physical thing in community with a lifecycle.
Capture at point of support
The only reliable interaction is a short form on a phone. Capture lifecycle events when people ask for help.
Structured pick-lists first
Free text is hard on phones with poor connectivity. Use dropdowns and checkboxes before long text.
Replacement = procurement signal
When a product is dumped, that's not just support — it's a signal that procurement needs to improve.
Separate known from estimated
Don't mix confirmed data with guesses. Mark confidence levels.
Keep it small enough to use
A model nobody fills in is worse than no model. Optimise for actual field use.

Product Lanes

We start with four product families because they combine high spend, high freight burden, high failure risk, and direct health impact:

🛏️
Beds
Active
🧺
Washing Machines
Active
🛋️
Mattresses
Planned
❄️
Fridges/Freezers
Planned

Core Entities

1. Asset

One physical product in community. Every Stretch Bed and washing machine gets a unique ID and QR code.

  • unique_id — e.g. SB-0142
  • product_type — stretch_bed, washing_machine
  • community — where it is now
  • status — deployed, needs_repair, retired, dumped
  • claimed_by — household or person (via QR scan)

2. Lifecycle Event

Anything that happens to an asset after deployment. Captured via QR support form.

  • event_type — check_in, issue_reported, repair, replacement, disposal
  • condition — good, needs_repair, damaged, missing
  • failure_cause — wear, rust, mould, frame_damage, electrical_fault, freight_damage
  • outcome_wanted — repair, replace, pickup, assessment
  • safety_risk — boolean flag for urgent issues

3. Usage Data (Machines)

Telemetry from connected washing machines via IoT sensors.

  • cycle_count — wash cycles per day/week
  • energy_kwh — power consumption
  • heartbeat — last communication timestamp

How It Works in Practice

1
Deployment: Bed arrives in community. Worker scans QR, registers in asset system.
2
Claim: Recipient scans QR on their phone. Links their identity to the asset. Gets SMS support channel.
3
Support: When something breaks, scan QR → fill structured form → support ticket created → GHL workflow triggered.
4
Insight: Lifecycle events aggregate into failure patterns. "Canvas tears after 2 years in dusty conditions" becomes a design improvement.
5
Procurement signal: When a competitor's washing machine gets dumped after 3 months, that's evidence for why communities should procure better products.

The Economic Argument

Without lifecycle tracking, remote communities are trapped in a cycle of cheap procurement and rapid failure. By tracking what lasts and what doesn't, we can prove that a $500 Stretch Bed lasting 10+ years costs less than replacing $50 beds every 6 months — and the data makes the grant case for quality goods.