oil change maintenance prd

Oil Change Preventive Maintenance — PRD

1. Cover & document control

• Product: Rechaj Swap App · Field Support · Atlas issue management
• Unit: Swap · MocX Smart Technologies Ltd (Rechaj)
• Surface: Mobile 390×844 — swap manager, field support technician, field support lead
• Status: Draft for build
• Flows:
  • products/rechaj-swap-app/prototypes/swap-station-manager.html (the due banner)
  • products/argo/flows/field-support-technician/index.html (the work)
  • products/argo/flows/field-support-lead/index.html (the tracking)

2. Executive summary

We are replacing differentials faster than we should be. The failures are not random and they are not a manufacturing defect: a differential that runs on old, low or contaminated oil wears until it fails, and the oil is not being checked on any schedule. Each replacement is a part cost, a keke off the road, and a rider who does not earn that day.

This feature makes the oil check a scheduled, tracked obligation rather than something that happens when somebody remembers. Every keke that passes the mileage threshold is flagged as due, a case is opened for it automatically, and that case can only be closed by a field support technician who has done the work and photographed it. Nothing is marked done on trust.

The reason it is built as a case in the central issue management system rather than a checklist in its own app is coverage. A checklist tells you what was ticked. A case tells you what is outstanding, who owns it, how long it has been outstanding, and which station is behind — and it does so in the same system that already tracks every other field intervention, so oil changes are counted beside them rather than in a spreadsheet nobody reads.

3. Problem

Observed: a rising rate of differential replacement across the fleet.

Root cause: the transmission oil is not inspected or changed on a schedule. There is no trigger, no owner and no record. A rider only raises it once something is already audibly wrong, by which point the differential is usually beyond a fluid change.

Why the current system does not catch it:

	Today
Trigger	None. Nobody is told a keke is due
Owner	Unassigned. Whoever notices, if anybody does
Record	None. A completed oil change leaves no trace
Oversight	None. No one can say what fraction of the fleet is current

The consequence is that the first signal we get is a breakdown, which is the most expensive possible place to find out.

4. Goals, non-goals & success criteria

Goals

1. Every keke has a known oil-change status at all times: current or due.
2. A due keke automatically produces a case with an owner, not a notification.
3. A case can only be closed with photographic evidence of the work.
4. Completion is measurable per station, so the gap is visible while it is still a gap.

Non-goals

• This does not diagnose a differential that has already failed. That is an existing mechanical case and stays one.
• This does not gate or block a swap. A rider who is due still swaps and still earns; the swap surface informs, it does not enforce.
• This does not introduce a new app, a new role, or a new queue. It uses the case lifecycle field support already runs.

Success criteria

• Differential replacement rate falls quarter on quarter.
• The share of the fleet overdue at any moment trends down and stays down.
• Every closed oil-change case carries before and after photographs.

5. The due rule (binding)

An oil change is due at 3,000 km since the last recorded oil change.

kmSinceLastChange  =  currentOdometer  -  odometerAtLastOilChange
oilChangeDue       =  kmSinceLastChange  >=  3000

Where the odometer comes from. The swap app already captures the keke’s mileage at stage two of the battery unlock, on every swap. That is a reading a human types off the dashboard while standing at the keke, on a surface we already run, so it needs no new hardware and no new step. Mileage is therefore refreshed roughly daily for an active rider.

Consequences of that choice, stated plainly:

• A keke that is not swapping is not reporting mileage, so its counter goes stale. A rider off the road is not accruing wear either, so this is acceptable, but a keke whose mileage has not moved in 30 days should be treated as unknown rather than current.
• The reading is typed by a person and can be wrong. A reading that is lower than the last recorded one is rejected rather than stored, since an odometer does not run backwards.

Status values

Status	Rule	Meaning
Current	< 2,700 km	Nothing to do
Due soon	2,700 – 2,999 km	Within 300 km. Visible, no case yet
Due	≥ 3,000 km	Case opened automatically
Overdue	≥ 3,300 km	Due, and more than 300 km past it. Prioritised

6. Case lifecycle

An oil change is an ordinary field support case with a fixed shape. It enters the same queue, is assigned the same way, and closes against the same four documentation steps as any other case.

mileage crosses 3,000 km
        │
        ▼
  CASE CREATED automatically          category: Maintenance
  assigned to the technician          fault:    Oil change due
  at the rider's home station         status:   To accept
        │
        ▼
  technician accepts ─→ travels ─→ marks arrival
        │
        ▼
  four steps, three of them already answered
    1  Category of issue    Maintenance          prefilled
    2  Fault found          Oil change due       prefilled
    3  Resolution taken     Oil change completed prefilled
    4  Before and after photos                   THE TECHNICIAN'S JOB
        │
        ▼
  CLOSED as resolved  ─→  odometerAtLastOilChange = odometer at close
                          counter resets to 0 km

Why three steps are prefilled. The category, the fault and the resolution are all known before the technician arrives — that is the entire premise of a preventive case, as opposed to a breakdown where the fault is the thing being established. Asking a technician to re-select three values the system already knows costs time on every single case and invites a mis-tap that makes the record unqueryable. What is genuinely unknown, and therefore what he is asked for, is whether the work was actually done. That is the photograph.

What closes the case. Both photographs. A single image is a picture of a keke, not evidence of an oil change; the pair shows the state before and the state after. The case cannot be closed without both, exactly as with every other case type.

7. Surfaces

7.1 Swap manager — the due banner

On the swap payment screen, the moment a rider is authenticated by plate or QR, the app states the keke’s oil-change status before anything else on the screen. It is the first block in the scroll and it is unmissable by design: a due keke is not a footnote under a wallet balance.

• Due reads the mileage since the last change, how far past the threshold it is, and the case number already open with field support.
• Current reads the mileage since the last change and how far off the next one is.
• A small info control on the banner opens this document in the app.

The banner is informational. The case already exists — it was created by the system, not by the manager — so there is nothing here for the manager to raise, and no button that would imply otherwise. The swap proceeds normally.

7.2 Field support technician — the work

• A dedicated Oil change entry on the home screen carrying the count still due.
• A screen listing every due rider in his patch, overdue first, each row naming the rider, the plate, the station and the mileage over.
• Tapping a rider opens that rider’s oil-change case with steps 1 to 3 already answered, leaving the photo step as the only thing to do.

7.3 Field support lead — the tracking

• A home summary of oil changes done against still due for the selected period.
• A screen breaking that down station by station, so the lead can see which station is behind rather than only that the fleet is.
• Each station row carries done, due and the completion share.

8. Data model additions

Field	On	Type	Notes
odometer	keke	integer km	Refreshed at stage two of every swap unlock
odometerAtLastOilChange	keke	integer km	Set when an oil-change case closes
lastOilChangeAt	keke	timestamp	Set when an oil-change case closes
lastOilChangeCaseId	keke	case ref	The case that recorded it
kind	case	enum	oil distinguishes these from reactive cases

kmSinceLastChange and oilChangeDue are derived on read, never stored. A stored flag can disagree with the mileage that produced it; a derived one cannot.

9. Reporting

The central issue management system gains these, all off the case records that already exist:

• Oil changes completed, by period, by station, by technician.
• Kekes currently due and currently overdue, as a count and as a share of the fleet.
• Average kilometres past threshold at the point of completion — how late we actually are, as distinct from how many we did.
• Differential replacements over time, read against oil-change completion, which is the number this whole feature exists to move.

10. Open questions

1. Interval. 3,000 km is the working figure. It should be confirmed against the manufacturer’s schedule for both the TVS and the Bajaj keke, which may not be the same interval.
2. Stale odometers. How many days without a swap before a keke’s mileage is treated as unknown rather than current. 30 days is proposed, not settled.
3. Oil stock. An oil change consumes oil, which is not currently in the parts ledger the technician draws from. Whether oil is tracked as a part or handled outside inventory is unresolved.
4. Rider no-show. What happens to a case where the technician arrives and the keke is not there. The generic case flow parks it; whether a preventive case should instead be auto-rescheduled is undecided.