It’s hard to say without seeing your current base, but typically ticketing systems use transaction records associated with the ticket to track intervals. (For instance, if you use dedicated in, repaired, and out datetime fields, what happens if the customer comes to pick up the watch and says, ‘Hey — this isn’t fixed.’ If you overwrite the original fields, you lose visibility to the time the watch has already been in your shop; if you open a new ticket, you loose easy access to documentation of what work has already been performed and you lose sensitivity to the watch already having passed through one unsuccessful repair cycle.) (Of course, maybe this isn’t a common issue regarding watch repair — but I cut my teeth on telephone lines and data circuits, and I can assure you it’s not uncommon there!) By using a discrete record to track each movement (or status change) for the watch, you can easily tally how much time it’s spent in each status.
I know I used a similar mechanism in my Wardrobe Manager base in Airtable Universe — but, frankly, it’s been so long since I was in that base, I’m not sure if it’s coded as cleanly as I would today. Still, you should be able to get an idea of how I’d architect the solution — and the base is well (or is that ‘overly’?)-documented. Examine the base on Airtable Universe: You’ll want to look at how the [Out] table is implemented. The base also contains a [Documentation] table, which includes a detailed users guide stored as a PDF attachment: Look for the section on handling referrals or ‘outs’.
