Every automation project has a moment where the happy path is done and the work looks finished. It is not finished. What remains is the long tail, and the long tail is where projects quietly stop being used.
The pattern is consistent. A workflow handles almost everything it sees. The remainder — the duplicate submission, the attachment that is a photo of a screen, the customer who replies to a three-month-old thread — falls out. If there is nowhere for those to go, they land back on the person the automation was supposed to help, in a pile, with no context.
So the exception path is not an afterthought to build later. It is part of the first version. Anything the workflow cannot handle goes to a named person, with the original input, what the workflow tried, and why it stopped. That is the whole design.
The second lesson is that the tail teaches you the business. The exceptions are not noise; they are the parts of the process that were never written down, surfacing for the first time because something finally tried to follow the written version. Reading a month of exceptions tells you more about how a company actually works than any process document.
The projects that last are the ones where somebody reads that queue every week and moves one case out of it into the automated path. That habit, more than any model, is what compounds.