Ship Management handles the physical side of a hardware-replacement ticket: getting a device from inventory to the requester. It is a small, focused tool, and it exists because a real help desk's job on a broken-hardware ticket often does not end at "assign a replacement" — someone still has to get the replacement to the person who needs it and record that it happened. SysDesks treats that as a real, checkable step rather than an assumption.
Ship Management opens to a list of tickets that are genuinely eligible for a shipment — tickets whose scenario actually calls for fulfillment, filtered automatically from your open queue. This is intentional: not every hardware ticket needs shipping, some are resolved entirely on-site or through a swap at a local desk, and Ship Management surfaces only the ones where getting a physical device to someone is actually part of the job, so you're never guessing whether a given incident needs a shipment created for it at all.
Creating a shipment
- From a ticket that authorizes a hardware replacement, confirm you've assigned a replacement device in Asset Management first — a shipment needs a specific device to reference, and it can never be the damaged asset going back out.
- Open Ship Management and find the ticket in its eligible-tickets list, or create a shipment directly linked to the ticket.
- Enter the carrier and a tracking number for the shipment.
- Dispatch the shipment.
- Confirm the shipment now shows as dispatched against that ticket before you resolve it.
A ticket that requires a shipment checks for a real dispatched shipment record tied to that specific incident, not just a note saying one was sent. This means the shipment has to actually exist in Ship Management, linked to the correct ticket, with a carrier and tracking number attached, before that resolution condition is satisfied — the same standard of evidence the rest of the platform holds you to. A ticket resolved with notes claiming a shipment went out, but no actual shipment record behind it, will not pass, because the state judge checks the record rather than the note.
This also feeds directly into the efficiency and process parts of a ticket's score, described in How Scoring Works: shipping the wrong device, shipping to the wrong assignment, or skipping the record entirely all show up as real gaps between what the ticket needed and what actually happened, not just style points on your write-up.
Ship Management deliberately stays scoped to dispatch and tracking rather than trying to simulate a full logistics platform. Its job is to make the paperwork side of a replacement ticket real enough to require care — the correct device assigned to the correct person with a real record of it being sent — without turning every hardware ticket into a multi-step shipping simulation of its own.
A hardware-replacement ticket typically touches three tools in sequence: Asset Management to move the correct replacement device out of ready stock and onto the requester, Ship Management to actually get it there and record how, and then the ticket workspace itself to document the whole thing and resolve it. Skipping the middle step — assigning a device but never creating a shipment for it — is a common early mistake, since the assignment alone changes who owns the record but says nothing about whether the requester has physically received anything yet.
Because the eligible-tickets list only shows incidents whose scenario genuinely calls for fulfillment, you won't find yourself creating an unnecessary shipment for a ticket that was actually resolved by walking someone through a setting change — a good sanity check if you're ever unsure whether a given hardware ticket needs Ship Management involved at all.