> For the complete documentation index, see [llms.txt](https://hub.equipme.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://hub.equipme.io/documentation/fulfillment/changes.md). # Changes Changes is the work list for exchanges: a device has failed, been damaged or been lost, and the customer needs a replacement. It sits alongside Open positions rather than inside it, because an exchange is not a new order. It is an intervention in a service that is already running, and it behaves differently for that reason. ## What is actually being exchanged The service is not replaced. The term is not restarted. The price does not change. What gets replaced is the hardware inside the service. Worth holding on to, because the action is called Replace service and can read as though the service itself changes. The customer keeps the same contract and carries on as before, with a different physical device. The old component is not deleted either. It stays on the service with a status such as Technical defect, so a year later it is still visible that this service has been through one device already. That history is the point: without it, a pattern of repeated failures on the same contract would be invisible. ## Nothing happens without a swap add-on A customer only sees the exchange option if you have defined a **swap add-on** for that service. It is not created automatically. So when a customer says they cannot find the option, the service has not been set up for exchanges. The add-on is also where you decide what an exchange costs and what the customer has to tell you. Options can carry a reason, which is how you learn whether it was a defect or damage, and they can be priced, which is how an express replacement carries a surcharge. ## Recording what actually happened The replace dialog asks two separate questions, and the first one is easy to skip. The customer told you they need a new device. **Your own assessment of the cause goes in the first stage**: accidental damage, a technical defect, something else. It is optional, and it is the only place the real reason is captured. Skip it and you lose the ability to tell, later, whether a customer's devices keep failing or keep getting dropped. The second stage is the decision. Replacing like for like is the normal case. A different product is possible, and that decision is deliberately left to you, because only you know whether your contract with that customer allows a model change. Where the article is a stock item, you can also create a **replacement order**, which triggers a purchase for the new device. A useful order of work: set the position to In progress first, then replace the component, because the new device and its serial number only emerge while you are handling it. Complete afterwards. The replacement takes effect immediately, with no confirmation step. ## Replacements are always a new purchase Worth knowing before you agree an exchange process with a customer. Many providers handle exchanges from a pool of refurbished returns. A replacement order in equipme triggers a **new purchase** rather than drawing from such a pool. If you work with a swap pool, the replacement device is handled outside the system or booked in as ordinary stock first. ## Working the list An exchange runs through the same machinery as an ordinary order, with its own Changes tab on the position. Purchase demand appears if a device has to be bought, Picking once one is available, and Service components shows the result: old device with its defect status, new device beside it. **Complete directly** finishes selected exchanges without going through the stages, for cases handled entirely outside the system. **Completed changes** switches to the archive. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://hub.equipme.io/documentation/fulfillment/changes.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.