How to stop project decisions made by email from getting lost.

The customer moves the FAT back by two weeks. Purchasing reports that the main drive will arrive late. The customer's project lead approves, in a two-line reply, an extra maintenance door in the safety enclosure. Three decisions, all binding, all by email.

And afterwards all three live in an inbox. Not in the project.

Why are so many plant engineering decisions made by email?

In project business with one-off and special-purpose machines, a large share of binding agreements is not made in meetings but in the inbox. That is not negligence. An email is quick to write, it carries a date and a sender, and many customers commit to things that way.

When a customer change request or a shifted delivery date is disputed later, that email is often the document both sides point to. So it matters. It just sits in the wrong place.

Why do agreements made in Outlook get lost in the project?

Three causes show up in almost every project.

Personal inboxes. The customer approval sits with the project manager, the date shift with sales, the answer about the bill of materials with the design engineer. Everyone holds a piece, nobody holds the whole.

CC chains. A discussion about a customer change runs through a dozen replies with a shifting distribution list. The actual decision is somewhere in the middle, in half a sentence. Anyone who reads only the first or last message can easily draw the wrong conclusion.

Holidays, sick leave, staff changes. If the person with the email is away, so is the decision. When a project is handed over, the mailbox does not move with it.

Anyone who has prepared an acceptance test knows the consequences. An item on the FAT checklist does not match the customer specification, and only after a long search does it turn out the customer changed it by email months ago. Or the reverse, the assembly team builds to the old state because the change never reached the project.

This is one part of a problem we hear about again and again from project managers. The project status is scattered across Excel, OneNote and email and has to be pieced together by hand. Why that piecing together takes so long is covered in Project status in Excel, OneNote and email.

Which workarounds exist and where do they fall short?

A shared project mailbox

Many companies set up a function address per project that gets copied in. That works as long as everyone remembers. In practice the customer replies straight to the project manager, and the important email lands in a personal inbox anyway. The shared mailbox also collects everything, from meeting requests to delivery notices, so the one decision is just as hard to find there.

The email saved as a PDF in the project folder

The email is saved as a PDF or MSG file in the project folder, perhaps under "Correspondence". For documentation, that is tidy. But the folder then holds a file with a date in its name, and nobody can tell whether it contains a date change or just a question without opening it. The schedule still shows the old date.

Copying it into the Excel list

The most thorough option is an open items list or a decision log in Excel. Someone reads the email and enters the decision with a date and a reference. It works as long as that person has time. Under deadline pressure this is exactly the step that gets skipped, and a few weeks later the list is out of date. And the Excel row summarises the email without carrying the evidence along.

All three approaches have one thing in common. Someone has to do two things, file the email and update the project status. The second is the first to go.

What should a good process for email decisions do?

Whatever the tool, it is worth agreeing a few rules within the team.

• Decisions get a fixed place in the project, not in the inbox.
• Every decision comes with its evidence, the email itself with attachments, not only a summary.
• Filing takes so little effort that it still happens in the week before commissioning.
• Whoever carries a decision into the project status confirms deliberately that it applies. "We are considering a delay" is not yet a date change.
• Clear subject lines help both sides. Writing "Approval" or "Date change" in the subject makes the email easier to find later.

These rules apply without AI too. But they show where software can take the most work off your hands, namely in updating the project status.

How do you file emails from your own mailbox in the project?

In KoAssist's Project Memory, this is the path that has been built. You select one or more emails from your own mailbox and file them in the project, together with their attachments. Nothing is stored until you release it.

From the filed email, KoAssist proposes what changes in the project. Each proposal is marked as Change, New or Done. A typical case looks like this. The customer writes that the FAT will take place two weeks later and that the safety enclosure gets a maintenance door. KoAssist proposes changing the FAT date in the schedule and adding the maintenance door as a new item. A question about the bill of materials that the same email answers can be proposed as done.

Only what someone on the team accepts becomes valid. The software does not make the decision, it prepares it. Whoever reviews the proposals decides whether the customer's wording really is a commitment.

The same applies to meeting minutes. KoAssist proposes changes from those as well, and the team accepts or rejects them.

The result shows up in the project overview where it belongs, in the schedule, the open items and the decisions. Anyone opening the project sees under "New since your last visit" what has happened. How that cuts the coordination effort is described in Project status without status meetings.

What happens to data protection?

A fair question, because a mailbox holds more than project emails.

Only your own mailbox. The search covers your own mailbox only. KoAssist does not search colleagues' mailboxes, and there is no blanket connection of all email.

Nothing without release. Only what you select and release is stored. Every other email stays where it is.

Permissions follow the folder. Anyone who cannot open the project folder in the source system cannot see its contents in KoAssist either. That applies to filed emails just as it does to drawings and specifications.

On top of that there is hosting in German data centres and no training on your data. The details for your IT team and your data protection officer are on the Security page.

How should your team get started?

Pick one running project with active customer contact, ideally one between design release and acceptance. That is where email traffic is densest. Agree within the team that every email with a new date, a customer change or an approval is filed in the project, and check after a few weeks whether the project status is closer to reality as a result.

How emails, minutes and the customer specification come together is shown on the Project Memory page. If you would like to see it on one of your own projects, book a demo.