Asset repair, replacement, and custody

Repair, replacement, and mid-life custody are what happen after an item is already assigned: the laptop is cracked, the phone is in a shop, a spare is issued, or the original comes back. Custody must still name a holder. It must not go blank because “IT has it.” How you first assign catalog to employee stays on how to assign a company asset. The packing list stays on the employee asset handover checklist. Product surface: Dayzen asset management (assignment history, repair logs, warranty details stored on the catalog). Dayzen is not an IT ticketing product, not MDM, and not remote diagnostics. Do not treat a repair log as a helpdesk.

This is operational guidance, not legal advice. Who pays for damage, and whether a settlement line is lawful, may depend on applicable law, contract, policy, or company practice. Verify with your HR, finance, and legal or SME team.

Custody never goes blank

At every hour, a catalogued item should answer: who holds this serial now? Valid answers include the employee, a named store or admin person, a named vendor location with a company contact who owns the relationship, or unassigned stock on a named shelf. Invalid answers include “in repair,” “with the vendor,” “floating spare,” and “the team.” Those are statuses, not holders. Pair every status with a person or a stock location you can walk to.

When an employee drops a laptop at a service centre, three facts must be written the same day:

1. The assignment history shows the item left employee custody (or remains theirs if your policy keeps them as holder while it is in shop — pick one rule and apply it).
2. A repair log row exists: date, symptom, where it went, who authorised it.
3. If you issued a spare, that spare is a second assignment (or a temporary assignment) to the same employee, with its own serial.

If you keep the employee as holder while the device is in shop, say so explicitly so recovery at exit still knows they owe that serial. If you move custody to “IT store” or a named technician, move it on the register. The failure mode is the shop has the device, the register still says the employee, the employee has a spare, and exit recovery demands two laptops that are actually one in a bag at a mall.

Repair logs are records, not tickets

A repair log is a dated note on the asset: what failed, when it was sent, when it returned, what changed (battery, screen, “no fault found”). Dayzen includes repair logs on people-linked assets. That is history for custody and warranty context. It is not a queue for technicians, not SLA clocks, not a requester portal, and not an ITSM product. Engineers may still use their own ticket tool. Do not duplicate that tool inside HR, and do not wait for an unpublished helpdesk lander. This article will not link one.

What to write in the log (short, factual):

• Date opened and who opened it (employee report, issuer inspection, return-desk finding).
• Symptom in one line. Not a novel, not a blame paragraph.
• Where the item is during repair (named shop, named internal bench, named courier intake).
• Warranty details as already stored on the catalog (expiry, vendor name you recorded). Dayzen stores those details; it does not call the vendor’s API or extend the warranty for you.
• Date closed, and whether the same serial returned or a replacement serial was issued.

Photos of damage belong with condition practice; a repair log can point to them. Do not turn the log into a second photo product.

If no fault is found, close the log with that outcome and restore custody clearly. Open-ended “still checking” for months is how serials fall off the world.

Replacement is a new assignment story

Replacement means the employee should hold a working item, and the broken serial needs a fate: repaired and returned to stock, repaired and returned to the same person, scrapped, or still in shop. Those are different register events. Do not overwrite the broken serial with the new one on the same row as if history never happened. Assignment tracking exists so you can see issued → repair → replaced.

Typical clean pattern:

1. Log the fault on the original serial.
2. Move original custody per your rule (employee vs store vs vendor contact).
3. Assign the spare or replacement serial to the employee with issue date, condition, acknowledgement — the same forward assignment workflow as a first issue.
4. When the original returns, either re-assign it (swap back, return the spare to stock) or keep the replacement and catalog the original as stock or scrap. Write which.

Swaps without dates produce two holders for one laptop in conversation and zero holders in the register. Acknowledge the new serial. Employees should see the live item on my-assets, not the ghost of the old one, once you have closed the swap.

Like-for-like is an operations choice (same model vs whatever is on the shelf). Record the serial you actually handed over. Do not record the model name only.

Spares, benches, and “IT has a pile”

A spare pool is catalogued unassigned stock, or stock assigned to a named store holder. A pile on a technician’s desk with no rows is not a pool. Before you lend from the pile, the serial should exist. After you lend, assignment should exist. When the spare comes back, return it. Hot-desking a “loaner” for six months is an assignment you refused to admit.

Internal repair benches: name the bench owner. If three technicians share a room, the holder is still one name or a store location, not “infra.”

Vendor shops: you may not control their counter. You still control your register: date out, vendor name, reference they gave you, named employee at your company who will chase. Warranty details stored on the catalog help the chaser; they do not file the claim automatically.

Exit and FNF: do not invent withholding here

If the person resigns while a device is in shop, recovery still needs a list of serials they owe or that are outstanding in their name. Chase that on the recovery article, against last working date. Pending returns may show as status on a full-and-final worksheet; that is a calculation and a flag, not a licence to withhold wages. This page does not advise illegal withholding. Repair in flight is an exception to log, not a reason to freeze salary as a tactic.

If a spare is still with them and the original is in shop, both serials must appear in the recovery conversation until each has a dated fate.

A custody board for mid-life events

Event	Register action	Done means
Fault reported	Repair log opened; holder still named	Date, symptom, current holder
Sent to shop	Custody updated per policy; log notes location	You can say who holds it today
Spare issued	New assignment on spare serial	Employee acknowledged the spare
Original returns	Log closed; swap or stock/scrap written	No duplicate live assignments by accident
Replacement kept	Original not left “assigned” forever	History shows both serials

What this is not

Not a ticket product: no queues, no technician SLAs, no “priority P1” framework on this page. Not device discovery or barcode invention. Not automatic depreciation. Not procurement. Not remote wipe if the device never comes back — Dayzen does not do that. If IT will wipe a returned disk, that is their fleet step after custody returns to store; record the return first so HR is not chasing a wiped laptop still listed as issued.

Not the assignment tutorial. First issue, condition photos, and join-day timing have their own pages. This page is the middle of the asset’s life.

Failure modes

Status “in repair” with no holder. Spare issued, original still assigned, employee leaves, you demand two machines. Repair discussed only in chat, no log, warranty expiry missed because nobody looked at stored details. Overwriting serials. Using the employee as the shop’s unpaid courier with no date out. Closing a log when the device is still at the mall. Treating Dayzen repair logs as proof that IT must respond in four hours. Opening a fake ticket culture inside HR. Forgetting accessories that went to the shop inside the laptop bag — they need a line too, or they become “missing at return.”

Another failure: finance capitalised the laptop, HR assigned it, IT repaired it, three spreadsheets, three truths. Prefer assignment history plus the repair log as the operations trail, even if finance keeps an asset code of their own. You can store their code on the catalog row as text; Dayzen is still not their depreciation engine.

Who meets, and when mid-life is clean

A fifteen-minute huddle when a device dies beats a week of rumours: employee, issuer or IT bench owner, and whoever controls spares. Agree holder, spare serial, and who calls the shop. Write it the same day.

Mid-life is clean when every serial has a named holder, open repair logs have a location, closed logs have a fate, and my-assets matches what is actually in the employee’s bag. Clean is not “the ticket was closed in some other system.” That other system is not this register.

When kit is in a shop or a spare is out, name the holder, log the repair, assign the spare as a real assignment. Dayzen stores repair logs and warranty details and keeps assignment history. It is not a helpdesk. Custody never goes blank.

Use the same discipline for phones and hotspots as for laptops. Stop when the register and the bag agree — not with an ITSM manual or a reprint of first-issue steps.