Ticket expiry is a monitored event, not a memory task

The individual tasks are tiny. Checking one ticket takes seconds. Filing one induction takes a minute. The half day comes from two things that are not admin at all. The first is expiry tracking done by memory. Nobody has a system that says this operative's ticket lapses in 21 days, so the check happens at the gate, under time pressure, one person at a time, every single morning. The second is retrieval. Documents exist. They are just not findable by whoever needs them. Someone on r/smallbusiness put it plainly: “I’m asking because I noticed I spend way more time finding documents than actually using them.” That is the tell. If finding takes longer than using, the problem is structure, not volume. Adding another folder, another shared drive or another naming convention does not fix it, because the next person will file the next document somewhere else. A site manager described the same shape on r/Construction: “I spend what feels like half my day just chasing paper. Getting RAMS from subbies that are clearly just copy-pasted from their last job, trying to make sure every single operative has the right, in-date ticket before they start, and then trying to find that one specific induction form from three weeks ago when head office asks for it.” Three separate jobs in one sentence: collecting, verifying currency, and retrieving on demand. Only one of them is really paperwork.

Right now the expiry date lives inside a scanned PDF. A human has to open the file to know it. That makes every check manual and every reminder dependent on someone remembering to look. Treating it as data means the moment a ticket arrives, three things get recorded as fields: who it belongs to, what it certifies, and the date it lapses. The scan stays attached, but the date is queryable. Once the date is a field, you can ask questions of it. Which tickets lapse in the next 30 days? Which subbie has nobody with a current high risk work licence? Who is booked on site next week with something expiring before then? None of those questions can be asked of a Dropbox folder. Compare three approaches. A folder of PDFs keeps the expiry inside the document, the site manager has to remember, and you find out at the gate or after. A spreadsheet of names keeps it in a cell someone updates by hand, whoever last touched the sheet has to remember, and you find out when someone rereads the sheet. Expiry stored as a data field lives in a dated record, nobody has to remember, and you find out 30, 14 and 7 days before. The difference is not tidiness. It is that the third option can trigger something on its own.

Chasing when you notice means chasing late, because you notice at the point of failure. The same site manager, a few lines later in that r/Construction post, described exactly what that costs: “This morning, we had a near-miss with a new guy from a plastering firm whose PASMA had expired. I only caught it by pure chance.” Pure chance is the current control. That is worth sitting with, because it is not a slur on anyone's diligence. It is a design outcome. If the only thing standing between an expired ticket and a live site is one person's attention on a busy morning, the system is doing the chasing at the worst possible moment. A scheduled chase inverts it. The date in the record fires a request to the subcontractor 30 days out, again at 14, again at 7. The request names the person and the specific ticket. The reply goes to one place and updates the record. By the time the crew arrives on site, the gate check is confirming something already known rather than discovering something new. This is also where the copy-pasted RAMS problem gets smaller. If you are requesting documents against a scheduled list rather than a scramble, you have time to actually read what comes back.

Retrieval-first means the answer is organised around the question people ask, not around the file that happens to hold it. People do not ask where the folder is. They ask whether this person is cleared for this task on this site today, and they ask you to send head office the induction for that bloke from three weeks ago. Structure around those. In practice that means one record per person or per company, with documents attached to it, versioned, with the current one obvious. Not a folder tree by month. Not email. A post on r/smallbusiness named the failure mode precisely: “The problem is not answering them. The problem is finding the answers again and again. One person saves the last version in email, another keeps it in Google Drive, and a month later we are digging through folders trying to remember what we sent.” Two people, two storage habits, one month, and the knowledge is gone. The fix is not discipline. Discipline decays under deadline. The fix is having one place where saving it correctly is the path of least resistance, and where the search is a filter rather than a memory exercise. Retrieval also has to work for whoever asks. If only the site manager can find things, the site manager becomes the bottleneck and the half day never leaves.

Often, yes, and that is a fair counter-argument. Plenty of construction and field service platforms hold worker tickets with expiry dates and send reminders. If you are already paying for one, the honest first move is to use the expiry fields properly before building anything. Where purpose-built software struggles is the edges. Subcontractors who will not log in to your portal. Documents that arrive as photos in a text message. A site induction form your client requires in their own format. The head office request that wants a specific document in a specific way. Those edges are where the half day hides, and they are usually specific enough to your operation that no vendor will build for them. So the realistic answer is layered. Use the system of record you have for the register. Build the thin connective pieces around it: the intake that turns a photo into a dated record, the scheduled chase to subbies who do not use your platform, the retrieval that answers a head office request without a manual dig. Those pieces are small. The difficulty is not the technology. It is knowing which of your edges is worth automating and how to fix it when it breaks at 6am on a Tuesday.

Someone inside the business. If an external agency builds the chase workflow, the business is dependent on that agency every time something shifts. A subcontractor changes their email format, a new licence type appears, the client changes the induction template, and the workflow can quietly stop firing. If nobody inside can see why, it gets abandoned, and the spreadsheet comes back. The person who should own this is usually the one already doing the chasing. They know which subbies reply and which need a phone call. They know which tickets matter for which tasks. What they lack is the ability to map their own process and to debug a broken step, and both are learnable. That is the premise of buildAutomation: train two or three of your own staff to build and maintain this, rather than renting it. The transferable skill is diagnosis and process mapping, not dragging nodes around a canvas. The line that same r/Construction post ends on is a capability problem, not a software problem: “We're meant to be building things, but I feel like a bloody filing clerk.” The person saying that is the right person to fix it.

Is chasing subcontractor tickets an admin problem or a systems problem? It is a systems problem wearing admin clothes. The individual checks are quick. The time goes to remembering when things expire and searching for documents that already exist. Fix the expiry tracking and the retrieval structure, and the admin shrinks to a fraction of what it was. What is the smallest useful first step? Build a register with one row per person, listing the ticket type and the expiry date as a real date field. Nothing else. Once the dates are queryable you can already answer what lapses this month, which is the question causing most of the last-minute scrambling. Why does a spreadsheet stop working for this? A spreadsheet stores the dates but cannot act on them. Someone must open it, read it and decide to chase. That means the chase depends on a person remembering, which is the exact failure being solved. A spreadsheet is a fine register and a poor monitor. How do you handle subbies who will not use your system? Do not require them to. Send the request out on your schedule by email or text, and let the reply arrive however they send it, including a photo. The work of turning that reply into a dated record happens on your side. Should we digitise every historical document? No. Digitise what gets requested. Historical documents that nobody has asked for in two years can stay in the box. Put the effort into current tickets, live inductions and anything a client or head office routinely asks for, because that is where retrieval time is actually spent. Does this need AI? Mostly not. Scheduled reminders, a structured register and a searchable record are ordinary software. AI helps at the messy edges, such as reading an expiry date off a photographed card or matching an inbound email to the right worker. Treat it as one component, not the point.

Quotes are reproduced verbatim from public Reddit threads and identified by subreddit and by the role the poster gave themselves, never by username. The three r/Construction quotes all come from one post by the same site manager. r/Construction, drowning in subcontractor paperwork thread: https://www.reddit.com/r/Construction/comments/1o6mt0j/drowning_in_subcontractor_paperwork_how_do_you/ . r/smallbusiness, on repeat client questions: https://www.reddit.com/r/smallbusiness/comments/1r0xnti/anyone_else_spending_way_too_much_time_on_client/ . r/smallbusiness, on paperwork slowing work down: https://www.reddit.com/r/smallbusiness/comments/1qye4s6/at_what_point_does_paperwork_start_slowing_your/ . These are complaints from public discussion, not survey data, and are not specific to Australia.