MTN Stock — Qhuba

IMEI	Status	Cond.	Batch	SIM	Merchant	Customer	Activated	Last recharge

SIM serial	MSISDN	Status	Paired router	Customer	Last recharge	Returned	Submitted	In MTN base

Scan stock in

Batch code

Pair SIM

Preloved

IMEI (scan, Enter advances)

SIM serial

this session: 0

Bulk paste

One device per line: IMEI or IMEI;SIM (comma or tab also work).

Scanned this session newest first — remember to generate the portal upload when done

	IMEI	SIM	Batch	Result

Router orders (last 21 days, from inFlow)

show completed

Order	Merchant	Placed	Allocated

Select an order to start allocating routers.

App portal upload

In-stock routers not yet listed on the app db. Activation is blocked until a router is listed, so run this right after intake.

– to list

Downloading marks these devices as listed.

SIM deactivation list

Returned SIMs not yet submitted to MTN for delisting. Choose which ones to send, and re-download any past submission to check MTN acted on it.

– to delist

Nothing is marked submitted until you download.

MTN FWA credit claim

Factory-fault routers awaiting return to MTN, pre-filled in their claim format (fault descriptions, dates). Review before sending; upload the final file back as an import to mark them submitted.

– awaiting credit

Download claim xlsx

Read-only — statuses change when the submitted file is imported.

Customer call list

Routers that have gone quiet, with the customer and the merchant to phone about each. Rows are marked Win back where the customer recharged and stopped, Retrieve where the router never recharged and is likely sitting unused, or Check in use where it was activated before our recharge history begins — no recharge on record there may only mean we were not looking yet.

– to call

Read-only — downloading changes nothing.

Awaiting submission to MTN

Downloading marks the selected SIMs as submitted and dates the submission, so the exact list stays reproducible on the right. Unselected SIMs stay in the queue.

	SIM serial	MSISDN	Last router	Returned	Last recharge

Past submissions

“Still in base” counts SIMs MTN kept reporting after we submitted them — those were not actioned. Re-queue puts one back in the list above.

Submitted	SIMs	Still in base

Devices needing a human decision

IMEI	Status	Batch	Merchant	Reason

Recharging while recorded as “with merchant”

A router sitting in a merchant's stock does not recharge, so a recent recharge is strong evidence it reached a customer and the activation was never captured. Applying one records an activated event dated to the SIM's first recharge, marked inferred with the recharge evidence attached. Dismiss instead if the merchant really does still hold it — the row will stop coming back.

IMEI	Merchant	Sold	Days held	SIM	30-day recharges	Proposed activation

SIM changes held for confirmation

An app report tried to pair a SIM we have no record of — most often a merchant mistyping the serial at activation. The pairing was not applied, so the device still points at its known SIM and recharge attribution stays correct. Accept if the SIM is genuinely new, reject if it was a typo. Logging a swap on the device beforehand registers the SIM, so a real swap never lands here.

IMEI	Merchant	Keeping (known SIM)	Proposed by app	Held

–

Recharges / 30 days

–

Routers measured

–

Merchants off-rate

–

Between-merchant SD

SRR is a merchant's recharges divided by the number expected if their customers recharged at the population rate for their age. 1.00 is on-rate; 0.80 means 20% fewer recharges than expected. The first 30 days after activation are excluded — routers ship with a bundle, so a quiet first month is not churn.

How to read this page

What SRR actually measures

You can't compare merchants on a plain recharge rate, because a router that has been out for 40 days recharges more often than one that has been out for 200. A merchant who sold recently would look good for no good reason. So each merchant gets their own target instead, built from the ages of their own customers. Here is that sum for –, the lowest-scoring merchant on the page right now:

Customer age	Their router-days	× normal rate	= expected	actual

Read a row as: their customers spent this many days at this age; routers that age normally recharge this often; so we expected this many recharges from that slice. Add the column up and –. A merchant selling only to brand-new customers gets a higher target, so they cannot win just by having sold recently.

The funnel plot

The horizontal axis is expected recharges — the target from the sum above. Treat it as how much evidence we have about that merchant. It is deliberately not a count of routers: two merchants with 40 routers each are not equally well measured if one sold theirs last month and the other a year ago. Expected recharges captures both how much they sold and how long it has been out there.

The band flares to the left because recharges are counted events, and counts are jumpy when there are few of them — the wobble is roughly 1 ÷ √(expected):

Expected recharges	95% band

A small merchant can land at 0.70 or 1.35 on luck alone. A large one cannot. A point outside the band is a merchant whose result is too far off to be chance — which is what stops you acting on a merchant who simply had a quiet quarter on 30 routers. The 95% CI in the table below is the same fact from the other side: when it does not reach 1.00, that merchant sits outside the band.

The two summary cards

Between-merchant SD — if every merchant were truly identical, their SRRs would still scatter around 1.00 by chance alone. This figure is what is left after subtracting that chance scatter, so it is the size of the genuine merchant-to-merchant variation.

Merchants off-rate — how many fall outside the band. With 95% confidence you would expect about – of them to do so by chance, so read this against that number, not against zero.

What it does not tell you

Only that a merchant's customers recharge less, never why. A low score is consistent with overselling to customers who cannot sustain the monthly bundle — and equally with working a poorer catchment. Customer suburb explained only about an eighth of the spread when it was tested, so it is not the whole story, but this is a prompt for a conversation rather than a verdict.

Funnel plot inside the band = indistinguishable from the population

Population rate by customer age

Merchants

Merchant	Routers	Recharges	Per 30d	SRR	95% CI

Correct a batch from a delivery receipt

The receipt is the real record of what arrived, so its IMEI list overrules whatever the tracker said. Paste or drop the list, name the batch, and every device on it moves there — IMEIs we have never seen are created as in stock. Nothing else about a device changes.

Batch code

Delivered on

Intake batches (canonical YYYY-Wnn codes)

Code	Original label	Arrival (approx.)	Devices	Note

Master tracker upload

Upload the Consolidated Tracker export (semicolon CSV). Creates the devices Qhuba has never seen, and fills blanks on the ones it already has — merchant and inFlow order number — without overwriting anything recorded here. Full preview and data-quality report before anything is written; committing the same file twice is refused.

Choose or drop the tracker CSV

Recurring uploads

Upload any recurring MTN file — the type is detected automatically: app product report (CSV), MTN weekly base & recharge report (xlsx), Returned Routers / Returned SIMs tabs, or an MTN FWA Returns xlsx. Re-uploading overlapping data only applies what's new.

Choose or drop a report / returns file

Past imports

#	Kind	File	Status	Applied	When

Batch

Rename

Merge into another batch

Resolve