Twelve Laptops, Four Hundred Chairs: Choosing a Tracking Mode
Twelve laptops need twelve records. Two hundred plastic chairs need one record and a count. Choosing the wrong tracking mode is the decision that quietly determines whether your register is maintainable — and it is much harder to reverse than to make.
A conference centre in Nairobi owns roughly four hundred stacking chairs. They live in three stores, they get moved for every event, some are cracked, and about thirty go missing each year in a way nobody can reconstruct. Somebody sensible decides to put them in the asset register. Two days later there are four hundred asset records, each with a code, each with a barcode label nobody has printed, each requiring a movement entry when a chair crosses the compound. The register is abandoned within a month, and the chairs are once again untracked — but now there is also a dead register, which is worse than none, because people cite it.
The mistake was not enthusiasm. It was tracking mode, chosen once at registration and awkward to undo afterwards.
Two modes, and what each one is for
Every asset is registered as either individually tracked — the default, one record per physical thing — or as a quantity pool, where one record carries a quantity and the system tracks how many are in each place rather than which one is where.
Individual tracking
- One record per physical unit, with its own code and barcode
- A unique serial number, which is the real reason to choose this
- Complete movement history for that specific unit — every custody change, in order
- Condition tracked per unit, so you know which one is damaged
- Warranty expiry per unit, which is per-serial in practice anyway
- Retirement per unit with its own reason and date
- Cost per unit, which is what a depreciation schedule wants
- Expensive to maintain at volume, and the expense is per movement
Quantity pool tracking
- One record with a quantity, and balances per place
- A balance row per combination of custodian, department, warehouse, location, status and condition
- So "18 in good condition at the Mombasa store" and "4 damaged at the same store" are separate lines
- Movements carry a quantity and shift counts between balances
- No per-unit history, because there are no units to have histories
- One barcode for the whole pool — scanning tells you the kind of thing, not which one
- Condition is a bucket you move quantities between, not a property of a chair
- Cheap to maintain, and stays accurate because updating it is one number
The balance structure is the part worth reading twice. A pool is not simply a number with a location — it is a set of counts across the full combination of who holds them, which department and warehouse and location they sit in, what status they are in and what condition they are in. That is considerably more informative than a single total, and it is why pool tracking is a real answer rather than a concession.
Deciding, with the questions that actually discriminate
Which mode for what
| Asset | Mode | The deciding question |
|---|---|---|
| Laptops, phones, tablets | No | No |
| Vehicles, generators, plant | No | No |
| Power tools, testing equipment | No | No |
| Stacking chairs, tables, tents | No | No |
| Uniforms, PPE, helmets | No | No |
| Office furniture | No | No |
| Radios, scanners, keys | No | No |
Built and maintained Configurable by you, not maintained by us Not built
One question separates these cases better than any other: would anybody ever need to ask "which one?" If the answer is yes for warranty, insurance, a loss report, a maintenance history or a custody dispute, track individually whatever the volume. If the answer is genuinely no, pool it — and be honest, because the aspirational answer is always yes and the maintained answer is what determines whether the register is true in eighteen months.
Why the choice is hard to reverse
Neither direction converts cleanly, and for asymmetric reasons.
Going from individual to pool means collapsing many records into one and abandoning their separate histories. The information is not deleted, but it stops being organised in a way you can use — you had four hundred movement trails and now you have counts. Going the other way is worse: converting a pool into individual records means creating the units that never existed, which requires somebody to physically go and identify four hundred chairs and assign codes to them. That is not a data migration, it is a field exercise, and it is the same work you avoided at the start plus the work of reconciling it with balances that have moved since.
So the practical advice is to decide deliberately at registration, and if you are genuinely uncertain about a category, start a small subset individually rather than committing the whole population either way. Twenty desks tracked individually will tell you within a quarter whether anybody is actually maintaining the movements, and that is the only test that matters.
The barcode consequence nobody anticipates
A barcode is unique per asset record. For an individual asset that means one label per unit, which is what you want. For a pool it means one barcode representing the whole pool, so scanning a label on a chair identifies the kind of chair, not that chair.
This is fine and it changes what a scan means. Scanning an individual asset says "this specific unit is here, now, with this person". Scanning a pool label says "this kind of thing is involved" and you then enter a quantity. If your intended workflow is a store worker scanning items out one by one and having each scan be self-sufficient, pooling breaks that assumption — the quantity always has to come from somewhere. Worth knowing before you print labels rather than after.
What AWRA OpsHub does today
- Two modes per asset — individual, the default, and quantity pool with a pool quantity.
- Pool balances held per combination of custodian, department, warehouse, location, status and condition, each with its own quantity and last-movement timestamp.
- Pool movements carrying a quantity, an action, the source, from and to balances, condition before and after, and an expected return date.
- The same approval, rejection, GPS coordinates and scan-event linkage on pool movements as on individual ones.
- Both modes available when converting stock into an asset, so a bulk purchase can become a pool directly.
- Unique serial number and barcode per asset record, enforced within your organisation.
What it does not do
- No conversion between modes. Nothing splits a pool into individual assets or merges individuals into a pool. Practically, changing your mind means re-registering.
- No per-unit history in a pool, by definition — you cannot ask what happened to one particular chair.
- No serial numbers within a pool, so a pool of items that do have serials loses them.
- No individual warranty tracking within a pool, since warranty expiry is a property of the single pool record.
- No automatic reconciliation of pool balances against a physical count — you compare and adjust.
- No per-unit cost within a pool, so a pool holds one purchase cost figure rather than a value per item.
- No minimum-quantity alerting on a pool, so a pool depleting through attrition does not warn you.
The absent conversion is the reason this article exists. Every other limitation here is a reasonable consequence of what a pool is; that one is a genuine gap, and it means the decision carries more weight than it appears to at registration. When in doubt, pilot a subset individually rather than committing a whole category.
Running a pool well
Five habits that keep a pool honest
- Use the condition dimension rather than a separate damaged pool. Balances already split by condition, so moving four chairs from good to damaged at the same location is one movement. A second asset record called "Chairs (broken)" is a workaround for something that is already supported, and it will drift.
- Reconcile counts on a fixed rhythm, not when something feels wrong. A pool degrades gradually through unrecorded movements, so quarterly for high-turnover pools and annually for stable ones. Adjust to the physical count and record why, because the size of the gap is the number that tells you whether your process is working.
- Pool by the attribute people actually ask for. Sizes for uniforms, capacities for tents, colours only if somebody genuinely requests by colour. One pool per meaningful variant, and no more — every extra pool is another balance set to maintain.
- Put attrition in the notes when you adjust. "Twelve written off after the December event" is the sentence that turns a shrinking count into a manageable fact. Without it, the pool just gets smaller and nobody can say whether that is normal.
- Do not pool anything a named person must personally return. This is the line worth defending. The moment a specific individual is accountable for a specific object, you need individual tracking, however identical the objects look — a pool can tell you four radios are with the security team and never which one Mwangi has.
The failure to design against is abandonment
A register with four hundred individually tracked chairs and no movement entries for eight months is worse than no register at all, because it looks like a record and people quote it. A pool showing "around 380, last counted in March, 22 damaged" is less precise and enormously more useful, because it is true and somebody is maintaining it. Precision you cannot sustain converts into inaccuracy you cannot see — and the only tracking mode that works is the one your team will still be updating next year.
Our take
Ask one question per asset category: would anybody ever need to know which one? If yes — for warranty, insurance, a loss report, a maintenance history or because a named person must return that specific object — track individually regardless of volume. If genuinely no, pool it and use the condition and location dimensions that pool balances already give you rather than inventing separate records for damaged stock. Decide at registration, because nothing converts between the two modes and reversing the choice means re-registering, which in the pool-to-individual direction is a field exercise rather than a data task. And when a category is borderline, pilot twenty units individually for a quarter: whether anybody records the movements is the only evidence that settles it.
Track what you can actually maintain
Individual tracking with per-unit serials, history and condition, or quantity pools with balances per custodian, department, location, status and condition — with the same approvals, GPS and scan linkage on movements either way.
See plans & pricingFrequently asked questions
What is the difference between individual and pool tracking?
Individual tracking creates one asset record per physical unit, with its own code, barcode, serial number, condition and full movement history. Pool tracking creates one record carrying a quantity, and tracks balances per combination of custodian, department, warehouse, location, status and condition — so you know how many are where and in what state, but not which one is which.
How do I decide which to use?
Ask whether anybody would ever need to know which one. If the answer is yes — for a warranty claim, an insurance schedule, a police report, a maintenance history, or because a named person must return that specific object — track individually whatever the volume. If it is genuinely no, pool it. Be honest rather than aspirational, because the maintained answer is what determines whether the register is still true in a year.
Can I convert a pool into individual assets later?
No. Nothing converts between the two modes in either direction. Pool to individual is the painful one, because the units never existed — somebody has to physically identify each item and assign it a code, then reconcile against balances that have moved in the meantime. That is a field exercise, not a data migration, which is why the choice matters at registration.
How do I handle damaged items in a pool?
Use the condition dimension, which pool balances already split on — moving four chairs from good to damaged at the same location is a single movement with a quantity. Do not create a second asset record called "Chairs (broken)": you would be working around something that is natively supported, and the two records will drift apart.
Does a pool have one barcode or many?
One, because a barcode is unique per asset record. This changes what a scan means: scanning an individual asset identifies that specific unit with its custodian and location, while scanning a pool label identifies the kind of thing and you then supply a quantity. If your workflow assumed each scan is self-sufficient, check that before printing labels.
Will a pool warn me when it runs low?
No — there is no minimum-quantity alerting on pools, so one depleting through attrition shrinks silently. Compensate with a reconciliation rhythm: quarterly for high-turnover pools, annually for stable ones, and write the reason into the notes when you adjust. "Twelve written off after the December event" is what makes a falling count interpretable instead of merely worrying.
