Most plan review teams we talk to already have some version of a standard comments document. If you're reading this, chances are you do, too.
Why do standard comment libraries exist in the first place? Well, reviewers see many of the same issues again and again. Over time, the department figures out how it wants to explain a common correction, which requirement to cite, and what information an applicant needs to fix it.
So somebody puts those comments in a Word document, spreadsheet, or PDF, and shares it with the rest of the team.
That solves one problem. Reviewers no longer have to write every correction or comment from scratch. But in solving that problem, the typical standard comment document also creates another: The swivel chair problem.
It looks like this. The plan is open on one screen. The standard comments are open on another. The reviewer finds an issue, switches over to the comments document, searches for the language they remember using before, makes sure it is still current, copies it by hand, switches back to the plan, pastes it in, and changes whatever needs to change for the situation in front of them.
Then they do it again. And again. And again.
The hard part of plan review should be deciding what needs to change.
It should not be finding the sentence your department has already written.
As time goes on, the problem can start to get worse. A file that started as a clean set of comments can accumulate years of edits. Different reviewers add language. Codes change. Old comments remain next to new ones. Before long, the reviewer isn't just searching for a comment. They are asking: Is this the right one? Is this the current one? Is this what we still use?
That adds friction to a part of the job that already requires concentration.
It also creates a unique kind of inconsistency. Two reviewers may be looking at the same issue and have access to the same standard comments, but one finds the current language immediately while another rewrites the correction from memory or pulls language from an old review.
Applicants can see the difference too. One may get a clear correction that cites the right requirement and explains exactly what needs to change. Another may get something technically correct, but harder to interpret and act on.
We have written before about how a resubmittal problem can really be a communication problem.
Good standard comments can help. But only if reviewers can access, reference, and use them with minimal friction.
Digitizing plan review is about more than getting rid of paper. A process can be completely electronic and still force reviewers to bounce between applications, copy information from one place to another, and keep track of which version of a document they should be using.
The key question here is: What does the reviewer need in front of them to do the work?
If the department has already developed useful standard comments, the reviewer should be able to find and apply them without leaving the plan they are reviewing.
Instead of switching to another document, searching through it, copying the language, and returning to the review, the reviewer can search or filter the department's standard comments while the plan is still in front of them, select the appropriate one, and make whatever changes the specific situation requires.
What does this actually look like in practice? See how a reviewer can find, apply, and edit standard comments without leaving the plan review workflow in the short product demo below:
An important note: a standard comment is a starting point, not a substitute for reviewer judgment.
No two plans are exactly alike. A reviewer may need to add context, change the language, or decide that the standard comment does not apply at all. The goal isn't to make every reviewer respond exactly the same way. It is to stop making reviewers repeat routine steps around language the department has already written.
Small steps like these matter because reviewers perform them all day, every day. It is the same kind of waste we see when someone completes a review and then manually transfers all of that feedback into another document, which is the double-entry problem in plan review.
And once standard comments are part of the review workflow, it creates another opportunity for productivity gains: Highlighting the areas where a reviewer should focus in their code review automatically, with a little help from AI.
Making standard comments easier to apply solves one problem. But in many cases, it's still the reviewer's responsibility to recognize the potential code issues and know which comment needs to be applied.
This is where AI can be useful. Not for replacing the reviewer's judgment, but for surfacing the potentially-obvious code violations automatically.
If the plan, applicable requirements, and the department's standard comments are available in the same workflow, AI can use that context to identify areas that may deserve a closer look and suggest comments that may apply.
An important note: e-PlanSoft has engineered this AI functionality as a suggestive feature. This means the reviewer can look at the plan, understand why the comment was recommended, and decide whether it actually applies. They can use it, edit it, or ignore it. And while the AI can recommend and even include a measure of conviction (like a confidence score), the reviewer ultimately decides what gets applied to the plan and what feedback makes its way back to the applicant.
This is the goal, and how we think about the escalating benefits of building and then using a standard comment library:
First, take the standard comments your department already uses and make them easier to apply during the review.
Then use AI to help reviewers recognize when one of those comments may be relevant.
There is one more problem with thinking about standard comments as a document: documents have a tendency to become static.
Standard comments shouldn't be.
Codes change. Reviewers find clearer ways to explain recurring corrections. The team notices a comment it keeps writing and decides it should become a standard. Something that made sense several years ago may need to be updated or removed.
A good standard comments library should reflect those changes.
That means making comments easier to use is only half of the job. They also need to be easy to maintain, organize, and improve over time.
Otherwise, today's clean standard comments document eventually becomes tomorrow's giant file full of old code cycles, overlapping language, and comments nobody is quite sure whether they should still use.
This is another place where moving the work into the plan review system matters. The same comments reviewers use every day can be updated as the department learns instead of episodically rebuilding a static document from scratch.
And that makes the comments more useful for AI too. There is a big difference between giving AI a code book and asking, “What is wrong with this plan?” and giving it the plan, the applicable requirements, and standard comments that reflect how the department actually handles common issues.
That broader context is part of the approach e-PlanSoft is taking to AI-assisted review.
It also fits with how we think about product development at e-PlanSoft. The job is not to maintain a comments document or add AI for its own sake. The job is to help reviewers identify issues with their plan sets, explain them clearly, and move reviews forward.
If your department has already done the work of writing a good comment, the next reviewer should not have to leave the review to find it or wonder whether it is still the right one.
Want to learn more about how we integrate standard comments into a truly modern plan review workflow? Get in touch - we'd love to show you what this could look like for your team.
And if you want to see more of what we're building with AI, check out the recording of our latest AI webinar (including a live walkthrough of our AI Comments Assistant).