You keep track of outstanding issues from one site visit to the next with one habit: end each report with a summary table of issues the engineer validates. That table becomes the input to the next report. The habit works in any tool, including a Word document; what software changes is who drafts the table. Either way, what carries forward is a record a person has already agreed to.
This is the request we hear more often than almost any other, and never twice in the same words. Stripped down it is always the same: I went to the same site last month and produced a report. I am going back today. My second report needs a grand total of every issue with its current status, resolved, outstanding, or new. How do I do that without rebuilding the list by hand every time?
Issue status is the engineer's call, not the software's
Having software read the previous report would put it in the position of deciding what counts as an issue and what counts as resolved, and those are the engineer's calls. A model is perfectly capable of reading a forty-page report and extracting a list; the difficulty is not capability. Once the model is scanning prior reports and making those determinations, the report is being written by the software rather than by the engineer, and on a report sequence that may end up in front of an insurer, a client, or a tribunal, that is not a trade worth making to save minutes. Tenera Reports, our AI report-drafting tool, goes around it by design: it does not read your previous report and decide anything about it. The alternative is a validation habit, and it is cheap.
Validate the summary once, at the end of each report
The report gets drafted and the engineer reviews it as usual. Then every issue mentioned in the report gets summarised into a table at the top of the document. In Tenera, an AI button drafts that table from what the report already says; in a manual workflow, whoever wrote the report builds it. The engineer reads the table, checks it against the body, and corrects anything wrong.
One action, two results. The report now opens with a summary the client can read in thirty seconds, which is worth having on its own. And the firm now holds a list of issues that a named engineer has looked at and confirmed.
Carrying the validated list to the next visit
The validated list travels to the next visit as an input alongside today's evidence. You copy the validated summary across and submit it with the new photographs, voice memos, and video. The summary step then produces the grand total: every issue from the earlier report, every issue found today, each with its status. The engineer does exactly what they did last time, reads the table and corrects what is wrong.
The validation step is the reason the whole chain holds. Every table in the sequence has been read and agreed by an engineer before it became an input to the next one, so there is no point in the chain where a determination was made by software and never checked. What is deliberately manual today is the copy across; the current method is literally copy and paste, and the article claims nothing more.
Finding last year's reports on the same site
The carry-forward habit assumes you can find the earlier reports at all, and on a shared drive that is its own job: three visits across two years, filed by different authors under whatever the site was called that month. In Tenera Reports the connection is a tag. A tag relates reports to the same project, and it can mark that a set of reports is a sequence of the same process rather than merely work on the same site. Tags are deliberately loose: use them as folders, as a discipline view, or as a significant process within a project. On screen they order and filter, so pulling the three prior visits to one site is a filter rather than a search through a drive. To see the whole loop on your own reports, the summary table and the tags together, book a demo and bring one site you visit repeatedly. The tags also answer the handover case: an engineer picking up a sequence they did not start filters to the prior reports in seconds instead of asking around for where they live.
Keep the running list inside the signed report
The common failure is a running issue list in a spreadsheet beside the reports. It starts as a convenience and becomes the thing everyone trusts, until the day the spreadsheet and the reports disagree and nobody can say which is right or who signed which. The list that carries forward should be the one in the report the engineer sealed; a list that lives anywhere else is a second record with no sign-off, and second records drift. The determination of what is an issue and whether it is resolved stays with the engineer in writing at every step, which is the whole design rather than a disclaimer.
Test it on your own site
Pull the last three reports on a site you visit repeatedly and build the grand total by hand. Time it, and note how many items you had to settle by re-reading body text. That number is what you currently pay, per visit, per site. Then look at where your running issue list actually lives today: if it is a spreadsheet nobody signs, the first improvement costs nothing, moving that list into the report that gets sealed.
Start your free trial
Tenera Reports keeps every site visit's reports organized and findable in one place, and cuts the time repetitive reports take by drafting each one in your firm's own template. The first 15 reports are free, with no time limit. Start your free trial and run the next two reports on one site.