You finish the booking and the software just stops

You finish a booking. The screen shows the booking. There is no link to its invoice, because there is no invoice yet, and no button to make one. The next thing you have to do is obvious to you and the software has nothing to say about it. So you go up to a menu, find the billing area, start a new invoice and type the client’s name again.

Multiply that by every step in the chain and you have the biggest single driver of a product feeling like a filing system rather than a tool.

The chain was in the data and not in the interface

The database knew all of it. An invoice carried its booking. A payment carried its invoice. A booking committed sites. Rent and utilities hung off the site. Every relationship needed to walk the process forward existed as a foreign key.

None of them were rendered. The booking view did not link to its invoice or its payment. The invoice did not link back to its booking. A site’s financial figures were text, not links, and there was no way from a site to the bookings on it. Exactly one screen stitched anything together — the client view — which meant that unless you happened to start from a client, you hit a wall.

That is a strange asymmetry and it is common. The relationships get modelled because the schema demands it, and then the read screens get built one entity at a time by whoever was assigned that entity, and nobody’s task said “and link it to the next thing”.

Forward actions, not just links

The distinction that mattered was between a link and an action. Linking a booking to its invoice is useful only after the invoice exists. What the operator needs at the end of a booking is a button that creates the next record with what it already knows filled in.

So the booking view gained a generate-invoice action that carries the client through to the invoice form as a prefill. The invoice gained record-payment. The purchase order gained issue and generate-invoice. The site gained related quick actions — occupancy, bills, book this site. The health check gained schedule-maintenance. The bill gained mark-as-paid. Each of those is small. Together they are the difference between a system that tells you where you are and one that carries you.

The rule underneath: a screen at the end of a step should offer the first action of the next step, with everything it already knows filled in. If your view screens all end in Edit and Delete, the product has no forward gear.

Back-links are separate work and are needed for a different reason

Forward actions serve the person doing the work. Back-links serve the person investigating something later, which is a different job with a different pattern — they arrive at a record from a list or a search and need to know what it came from.

Those went in as a batch: invoice to client and to its source booking, payment to invoice, photo to site and task and employee, document to whatever record it belongs to, bill to owner. The audit here found a specific class of defect worth mentioning: several of those links pointed at paths that had never existed, because the link was written against a route that was planned and then built somewhere else. They rendered as ordinary links and did nothing. Nothing errors when an anchor points at a route with no match; the router shrugs and the user thinks they misclicked.

The to-do list is the same idea, generated

The third form of the same fix was to stop treating reminders as a module and start generating them from the records themselves. A routine scans for overdue receivables, bookings ending within a fortnight and documents expiring within the month, and creates one item per finding, each carrying the type and identifier of the record it came from plus a link straight to it.

Two properties made it useful rather than noise. It is deduplicated per record and type, so it can run on every load of the screen without piling up. And every item links to the source record, so the item is not a message about work — it is the entry point to the work. An alert you have to go and find the subject of is a second task, not a help.

That is also where the earlier version had been dishonest. The screen had existed for a while, showing a hardcoded list that looked like real reminders. It scanned nothing. It is worth saying plainly: a placeholder that renders convincing fake data is worse than an empty state, because nobody files a bug against it and everybody assumes the feature works.

What I would check first in any product

Open the three most common records in the system and ask, at each one, what the user does next and whether the screen offers it. Then check whether every relationship in the schema is reachable in both directions from the interface. The gap between those two lists is usually where “it feels scattered” comes from, and it is cheap work — no new tables, no new endpoints, mostly one button and one link per screen.

Walk the workflow, not the entity list, when you audit read screens. Entity-by-entity review always produces complete-looking screens that end in nothing, because completeness for one record has no opinion about the record after it.

The honest limit: forward actions only exist where somebody wrote them, and there is no test that notices a new screen shipping without one. It stayed correct here by review habit, which is not a mechanism.