September 24, 2026

Takeoff Project Templates: The Same Structure on Every Job

Takeoff Project Templates: The Same Structure on Every Job

Setting up a job is a short run of decisions that feel unimportant while you are making them: what to call the project, which folders to create, where the tender drawings go as opposed to the revision that arrived on Friday. The decisions feel unimportant because the job has not started yet. They stop feeling unimportant six months later, when somebody needs the drawing a price was built on and finds four files with similar names.

A takeoff project template removes those decisions from the individual job. You settle the structure once, and every project created from it starts the same way.

What a project holds

A project in Planmetry contains the drawings you measure and the files that go with them — photos, notes, schedules — either directly in the project or sorted into folders inside it.

The hierarchy is deliberately shallow: a project contains folders, and folders contain drawings and files. A folder does not contain another folder. Worth knowing before you design a structure, because the nesting you might reach for on a large job is not there. On a job too big for one level of folders you are choosing between longer folder names that carry the missing level, and several projects — and several projects means the job is no longer one thing in the list, so make that choice deliberately rather than discovering it halfway through.

What a template actually carries

A template holds a name, a description, a colour, an ordered list of folder names, and a set of field definitions. Creating a project from it creates those folders and copies the fields across.

That is the whole of it, and the limits are worth stating: a template does not carry drawings, files, notes or any content. It reproduces an empty structure and a set of questions to fill in. The value is in not re-deciding, not in pre-loading.

Choosing the folder list

What belongs in the list depends on how your work divides, and there are three common answers:

  • By stage — tender drawings, revisions issued, as-built. Suits work where the same spaces are revisited and the question is always "which version".
  • By trade or package, where you price several packages on one building and each has its own drawings.
  • By floor or building, where the job is large enough that location is the first thing anyone navigates by.

The right one is whichever matches the question you ask most often when you go looking. Mixing two of them at the same level produces folders whose contents nobody can predict. If you genuinely need both, put them in the folder name in a fixed order — "L2 — Electrical", "L2 — Drywall" — so the list still sorts into something readable.

Keep the list short. A template that creates nine folders on a job that needs three leaves six empty ones, and empty folders teach people to stop reading folder names.

A word on the "by stage" version, because it is the one most likely to be over-read: keeping superseded sheets in a different folder from current ones is a filing convention, and a useful one — it makes measuring the wrong revision less likely. It is not revision control: nothing compares two versions of a sheet or tells you what changed, and nothing stops a superseded drawing being measured. Moving it when a new one arrives is a discipline, and it only works if it is one you actually keep.

Project fields: what the drawings do not carry

A drawing tells you about a building. It does not tell you whose job this is, what you called it internally, or when the price is due. That information usually lives in an email, which means it lives nowhere.

Project fields put it on the project. A field has a label and a type — text, number, date, or a list of options to choose from — so the things you record on every job get recorded the same way each time:

  • Customer and job number, so the project matches whatever your accounts system calls it.
  • Tender due date, as a date rather than a line in a note.
  • Status as a fixed list — priced, submitted, won, lost — so it reads consistently instead of one project saying "sent" and another "with client".
  • Estimator, where more than one person prices work.

Field values show on a strip at the top of the project on a desktop screen, which is where they are read; on a phone the space goes to the files instead. A field can carry a default value in the template, which becomes the project's value at creation. Worth using for anything usually the same and occasionally not: a default status of "pricing", a default estimator.

The discipline that makes fields useful is filling them in at creation, while you still have the email open. A field filled in later is usually a field never filled in, and a half-populated list of jobs is worse than none, because you cannot trust it enough to rely on it.

Fields are copied, not linked

One behaviour to understand before you build templates: a project takes its fields from the template at the moment it is created, as a copy. Editing the template afterwards changes what future projects get. It does not reach back into projects that already exist.

That is the right behaviour — a job priced last spring should keep the structure it was priced under rather than silently acquiring a field that did not exist at the time — but it has a consequence. Changing a template is not a way to fix jobs already running. A field you decide you need on live work has to be added on each of those projects, one at a time.

So it is worth ten minutes on the field list before you create twenty projects from a template, and not worth agonising over: the cost of a late addition is real but bounded, and it is paid per project rather than all at once.

Finding a job later

This is the part where a structure either works or does not, so it is worth being exact about what search does.

Search runs over the drawings and files inside a project: their names, a drawing's address, building and recognised type, the file type, and the opening text of notes. It does not search project names, folder names or the values in your project fields.

That changes what names are for. Project fields are what make information consistent and readable at a glance when you open the job — they are not a search index. The searchable handle on a job is the names of the things inside it, which is an argument for naming drawings properly as they arrive: a sheet named for its number and what it shows can be searched for; a sheet still carrying the name it was exported with cannot.

Drawing cards carry a preview of the sheet along with the recognised drawing type and the scale, which is usually enough to identify one without opening it. One document holds one drawing page, so a multi-page set is worked a page at a time and the names are what tell them apart.

Archive rather than delete

Finished jobs rarely need deleting. A project can be archived, which takes it out of the working list while keeping everything in it, and restored if the job turns out to be less finished than it looked. Deletion is available from the archive as a deliberate second step rather than something that happens by accident on a Friday afternoon.

The useful habit is archiving on a trigger rather than on impulse — when a job is invoiced, when a tender is lost — so the working list stays short enough to scan. A working list you can read at a glance is a tool. One where most entries finished two years ago is a filing cabinet.

Summary

  • Settle the structure once in a template so job setup stops being a series of small decisions.
  • A template carries folder names and field definitions — not drawings, files or content.
  • Projects hold folders; folders hold drawings and files. No level below that, so split into projects rather than nesting.
  • Pick one organising principle — stage, trade, or location — and keep the folder list short.
  • Separating superseded drawings is filing, not revision control. Nothing compares versions for you.
  • Fields carry what the drawings do not: customer, job number, due date, status. Fill them in at creation.
  • Fields are copied at creation, so template edits do not reach existing projects.
  • Search covers the drawings and files inside a project, not project names or field values — so name the drawings well.

Set one up

A useful way to find out whether a structure is right: look at the last job you finished, note which folders it actually used rather than which ones you created, and make that the template. Then run the next job through it and see what you end up creating by hand.

The files that go into those folders are the other half of the record — construction photo documentation covers what is worth keeping and why. For the measuring end of the process, the PDF quantity takeoff workflow covers how a package fits together.

Try Planmetry Free →