Keep every unit’s story straight.

Use a stable label such as Unit A, Unit B or Unit C. Keep the serial number and purchase record in the private register. Add location as a separate field so that a move between rooms does not change the unit’s identity.

When equipment is replaced, link the replacement to the retired unit and record the date. When only a component is replaced, retain the unit identity and record the changed component.

Unit	Incident	Ticket references	Coverage decision	Next required action	Responsible party	Next update
Stable label	One defined reported problem	Original and merged references	Pending, approved, denied or disputed	A specific step	Named team or provider	Date or unresolved

A merged ticket can be a useful administrative choice, but the unit and incident records should remain distinguishable. Ask the service team to confirm what each approval, part and work order covers.

Do not treat a ticket closure as proof that every linked unit is operating. Record operating status separately for each unit.

Keep separate dates for the first report, substantive response, diagnostic decision, coverage approval, parts release, shipment, delivery, visit and return to service. Note whether each date is actual, estimated or unknown.

This makes a delay easier to explain. If coverage is approved but the component has not shipped, the next question concerns parts release. If the part is delivered but no visit is scheduled, the next question concerns labor coordination.

For each package, record the intended unit and incident, component name, quantity, tracking reference and delivery date. Check the contents against the packing list without performing unauthorized disassembly. Report a missing or incorrect component promptly with a photo where useful.

Keep payment status separate. An owner may have a provider approval without proof that an invoice was paid, or a paid invoice without a confirmed shipment. Those are different stages and may involve different parties.

Use one short table with a row per open incident. Begin the message with the action you need, such as confirming the missing component or assigning the next visit. Link the underlying documents instead of repeating the entire history in every message.

Ask the recipient to correct the table if it is inaccurate. Preserve the reply and update the register with its source and date. A shared status picture is more useful than parallel threads with different unit labels.

For every date in an outage interval, identify which units were unavailable, which had limited operation and which were usable. Resolve gaps or disclose them. Count unit-days and days with all capacity unavailable separately.

Label and status conflicts are common in multi-unit service histories. Until they are resolved, no downtime total drawn from the record can be trusted.

Finish each incident with a dated outcome and the supporting observation. Keep resolved incidents visible, so the register reflects service successes as well as outstanding problems.

List each unit, its current condition, open incident, responsible party and next action. Link tickets and shipments to that row. Reconcile conflicting dates before calculating downtime, and retain closed incidents so the map reflects successful work too.