Most AEC firms submit proposals from a template nobody at the firm chose. It is a go-by file: an old submittal someone copied under deadline, then copied again. Every format decision inside it was made once, for one pursuit, by someone who may have left. Nobody wrote the reasons down, so nobody can tell which rules still matter.
A workshop description for SMPS's 2027 Northeast Regional Conference puts it better than I can. Julie Shaffer, FSMPS, CPSM, is running a two-hour session called From the Ground Up: Building Real InDesign Fluency, and it opens: "Many AEC marketers didn't learn InDesign. They inherited it. Someone else's go-by InDesign file, a deadline, and a lot of trial and error taught them to get proposals out the door."
Her session is about the software. The line stuck with me for a different reason. The marketer didn't only inherit the tool. They inherited the file, and the file is full of decisions.
A Go-By File Is a Set of Decisions Nobody Wrote Down
Open your firm's proposal template and count the choices in it. Page size. Fonts. How long a resume runs. Whether project sheets are one page or two. Which sections come first. Where the firm's boilerplate stops and the pursuit-specific content starts.
Some of those choices were required by a client. Some are your brand. Some were one person's preference on one Thursday in 2019. They all look identical in the file.
That is the actual problem. When a new solicitation comes in, nobody can say which rules are the agency's, which are the firm's, and which are an accident that stuck. So the safe move is to change nothing, and the template keeps carrying decisions made for a pursuit that ended years ago.
Why the Inherited Template Survives
It survives because it works. Shaffer's bio describes the standard her methods have to meet: "the kind that must survive a Tuesday at 4:00 pm when the deadline is 5." The go-by file meets that standard. It ships.
Nobody questions a file that ships. Questioning it takes an afternoon, and there is always a pursuit due. Her description calls the result "survival-mode production," and the phrase fits the whole operation, not only the software skills. The team gets very good at producing from the file and never gets the time to understand it.
What the Inherited Template Costs
The cost doesn't show up on any single submittal. It shows up over time.
- One person understands it. Usually the person who has used it longest, who is also the one who's out when the big pursuit drops.
- New hires learn by breaking it. Trial and error is the onboarding plan, and every error happens on a live proposal.
- Old requirements become permanent. A resume length one agency required becomes the firm's standard for every client.
- Fixes don't spread. When someone does correct something, they correct it in their copy. The next go-by is copied from a different one.
This is the same failure that hits a proposal library when the people who built it leave, applied to the container instead of the contents. The knowledge lives in a file and in one person's head, and neither explains itself.
A New Tool Won't Fix This Either
It is tempting to treat this as a software problem. Buy a new design tool, a template system or a proposal platform, and migrate.
Migration moves the file. It doesn't move the reasons. If nobody knows why resumes run two pages, the new system will run them at two pages too, now with more confidence. Every undocumented decision gets rebuilt faithfully in the new tool, and the migration makes it look deliberate.
What fixes it is boring: the format decisions have to live somewhere other than one person's file and one person's memory. Once they do, a tool can apply them consistently. Accessibility requirements are a good example. Fixing a template once only works if someone knows which rule the template is supposed to meet.
What to Do This Quarter
- List every decision in the template. Page size, fonts, section order, resume length, project sheet layout, boilerplate blocks.
- Tag each one. Required by a client (name the client), firm brand standard, or nobody knows.
- Resolve the "nobody knows" column. Confirm it and write down why, or drop it.
- Name an owner. One person decides format changes, and changes get made in the master, not in someone's copy.
The result is a one-page record of why your proposals look the way they do. It will outlast the file.
Frequently Asked Questions
What is a go-by file in proposal work?
A go-by file is a previous proposal or template that a team copies as the starting point for a new one. It is common in AEC marketing because it gets a submittal out fast. The risk is that it carries old format decisions and client-specific requirements forward without anyone knowing which still apply.
Should we rebuild our proposal template from scratch?
Usually not first. Rebuilding without knowing why the current template looks the way it does tends to recreate the same decisions in a new file. List and tag the existing decisions first, then rebuild only what the list shows is outdated or was never required.
Who should own a firm's proposal template?
One named person, usually the marketing or proposal lead, should own format decisions and keep the master file. Others can suggest changes, but edits go into the master with a written reason, so the next person to use it inherits the reasoning along with the file.