Business process software that stops after every step

If your business process software stops after each step, so that finishing a booking leaves you hunting for the billing menu and typing the client’s name again, the usual cause is that the system stores the connections between records but never shows them. The first thing to check is what the screen offers at the end of a step. If all it offers is Edit and Delete, the process has no way forward.

Here is how that looked in one booking-to-invoice system, and what fixing it took.

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.

How to check your own system

1. Open the three most common records (a booking, an invoice, a payment) and ask at each one what you do next, and whether the screen offers it.
2. Check that each record links to the one it came from and the one it produced, in both directions.
3. Click those links. A link to a page that was planned and never built looks normal and does nothing.
4. Open an item on any to-do or reminder list. It should take you straight to the record it is about, and the list should be built from real records rather than typed in.
5. Walk the whole workflow from first enquiry to payment, not one record type at a time.

The gap between what you do next and what the screen offers is usually where “it feels scattered” comes from, and it is cheap work to close: no new tables, no new endpoints, mostly one button and one link per screen. Reviewing entity by entity 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.

Where this ends up

Booking, invoice, payment is one chain rather than three lists in Sazinga AdBoard, so the record in front of you offers the next one instead of sending you back to a menu to type a client’s name again.