The first step is issue report via a contact form; the fact of life example is anonymised and recorded in a text bubble as following: “X funded the development of Y website, led by Emeritus Professor Z at W institution. The website is broken now because it was built using [...]. I represent X and when I tried to contact Z, my message was returned as undeliverable. I've been unable to find out how to reach Z or who is now responsible for the website. X has two concerns. One is to get the site back up with some current technology. The other is to see if they can get a backup of the site for their digital repository, so that if something untoward happens to any systems at W or KDL, they wouldn't lose the valuable research that went into the site. Who is the person responsible for operating Y? what are their plans for bringing current technology to the website? Is someone else responsible for backing up the site and it's graphics and data?”. The second step is analysis with 4 associated text bubbles: (1) “Is he correct that the issues are due to old technology, i.e. not something we would be able to fix? We should direct them to the new contact. I can ask [...], if they happy to have their contact details passed on.”; (2) “I suggest we ask how close they are to having the migrated site up. It doesn't seem sensible for us to work on a fix at this point.”; (3) “We need Justification of costs of migration work done so far.”; (4) “Packaging and transferring applications files took longer than estimated because of [...].”. The analysis step leads to communication with other stakeholders step when applicable. Both analysis and communication are marked with a circular arrows to indicate they can be iterative. The next step leads to a check stage (“Under SLA and technically safe to fix?”) with a Y/N path. The Y path leads to repair action/s (marked as iterative) and the N path to communication with partners (also marked as iterative). In its turn the repair action step can also lead to communication with partners.