What a sold board should open, and the repoint routine that keeps it honest
| Stage | What the board opens | Why |
|---|---|---|
| Live | The full listing page | Photos, particulars, tour, booking a viewing: the standard destination |
| Sold subject to contract / under offer | The listing, with current status shown | Interest does not stop at offer; some viewers become backup buyers or want the same street |
| Completed | A short local page: recent nearby listings and a valuation call to action | The house is gone; the passer-by is still a potential vendor one door away |
| Board down | Whatever the last stage left | Which is why the last stage must be set before the board is removed, not after |
The completed stage is the one agencies skip, and it is the one that earns its keep. Everyone driving past a sold board in a desirable street is locally interested. A page that says “sold in 11 days, see what's new near you” with a valuation link converts the exact attention the board is already generating, at zero print cost, for as long as the board stands. That page is also the honest answer to the stale-listing problem: the scan stops lying because the destination stopped pretending the sale is live.
A routine that lives in nobody's job description does not happen. The workable version is small: the code's destination is part of the same checklist item as updating the portal status, done by whoever does the portal update, because it is the same trigger and the same moment. Completion day is the deadline, not the day someone notices the board. The edit itself is one destination change on the code's record, from the dashboard, in seconds, and the board stays exactly where it is. What makes it stick is putting the code edit on the same line of the checklist as the portal change, so there is no second system to remember.
Repointing in seconds depends on finding the right code in seconds, and that is decided at generation time. Label every code with the property, in the format the branch already uses for its file, and keep the register (the CSV that generated the batch) as the map between addresses and codes. Multi-branch agencies should prefix with the branch: NW3-12OakAve rather than 12 Oak Avenue, because two branches will eventually generate the same street. Folders can group by branch or by status, but the label is what a flustered negotiator searches for on a Friday afternoon with a vendor on the phone.
Set the completed destination before the board goes up
It sounds backwards, but the cheapest moment to decide what a sold board opens is when the listing is created. Decide the completed-page template once per branch, and the completion-day routine becomes: update portal, update code destination, done. Agencies that leave the decision until completion choose the lazy default, which is the stale listing page.
Repointing is not a licence for permanent boards. Most agreements with vendors, and in some places the planning rules for express consent advertisements, expect boards to be removed within a set period after completion, and a board that stays up for months can sour the relationship with the person who just paid the fee. The honest pattern is both: repoint on completion so the board is never wrong, and still take the board down on the usual timetable. A code on a board that has been collected keeps whatever destination it had, which is harmless, and the register row can be archived with the file.
A to-let board has the same shape with faster cycles: live listing, then let-agreed (where the board usually comes down quickly), then back to live for the next tenancy. The repoint routine earns more here, not less, because a rental board may represent three tenancies in two years, and the agency's cost is reprinting plus board logistics each time. The same register, the same completion-style trigger on tenancy signing, and the board's code becomes a standing asset rather than a per-letting print job.