How do you keep a decision log during an event build?

The afternoon crew has started moving the registration desk back to the main entrance. Yesterday, you agreed to put it in the foyer. Someone remembers that the venue asked for the change, but nobody can find the message explaining why. Now you're paying people to undo work while another supplier waits for the same space.

An event decision log helps you avoid that conversation. It records the choices that change the build, who approved them, why they were made and what other people need to do as a result. When a choice changes again, you keep the earlier record and show which instruction replaces it.

The useful version is short enough to maintain during real work and clear enough for someone who missed the discussion. You don't need a transcript of every meeting. You need a reliable answer when a crew lead asks, "Are we still doing this, and who agreed it?"

Start with one shared record for significant decisions, give each entry an identifiable reference, and separate approval from implementation. Then connect each approved choice to the working documents and people it affects. The record only helps if the crew receives the resulting instruction before doing the work.

This guide includes an event decision log template and a fictional build example you can follow through approval, delivery and a later revision. The aim is to protect paid crew time, supplier commitments and the experience you've sold without making every ordinary task wait for paperwork.

Decide which choices need recording

A decision belongs in the log when someone outside the conversation could reasonably do the wrong thing without knowing about it. That might mean using an old layout, ordering an item you've rejected or telling attendees an arrangement that has changed. The consequence matters more than how long the discussion took.

A producer can approve an expensive change in a brief phone call. A whole team can spend an hour discussing a colour without changing anything important. Recording every conversation gives both the same attention and makes the consequential choices harder to find.

Look for decisions that affect the agreed cost, scope, timing, access arrangements or responsibilities. Include choices that reject a plausible alternative when that alternative is likely to come back. A rejected move can matter just as much as an approved one if a later crew would otherwise try it again.

For example, record the decision to retain a hired display because replacing it would miss the supplier's collection deadline. You probably don't need an entry for the crew putting the approved display in its marked position. That task already follows a current instruction, unless actual conditions require somebody to reconsider it.

The same distinction applies to sponsor requests. Moving a stand could be a significant decision even when nobody charges extra. It may affect a promised position, neighbouring exhibitors or an agreed route. "No additional cost" doesn't mean "no consequence."

Agree the recording rule with your department leads before load-in. Ask each lead which decisions another team needs to know about and which ones routinely get repeated. You'll get a more useful boundary than a blanket instruction to log everything above an arbitrary price.

For a small paid workshop, a short shared document may cover the few choices that change delivery. A multi-room conference with several suppliers may need a filtered list by location and department. Scale the record to the work and dependencies, rather than assuming every event needs a dedicated administrator.

Keep the underlying responsibilities clear. Great Britain's HSE says its event management guidance applies coordination and monitoring throughout site operations, including the build and breakdown. A decision log can support communication of those arrangements. It doesn't replace the event's risk assessments, competent supervision or required permissions.

Separate decisions from tasks, issues and current plans

You may already have a production schedule, action list, risk register and several group chats. Adding another record can feel unnecessary until you ask what each one actually tells the next person. Most of them describe work or problems. They may not explain why you chose the current solution.

An issue says something needs attention. "The hired display cannot arrive in the original loading window" is an issue. A task says someone must act. "Maya to obtain a revised delivery quote" is a task. Neither tells the crew which delivery arrangement the business finally accepted.

The decision states the choice and its conditions. "Accept the revised delivery on Friday, subject to the venue confirming the slot, with additional cost capped at the agreed quote" explains what has been chosen. The resulting tasks might include issuing the supplier instruction and updating the delivery schedule.

The current plan then tells people how to work. A driver needs the confirmed arrival time, gate and contact. They shouldn't have to read the whole argument about rejected options. Keep that reasoning available through the decision reference while updating the schedule they actually use.

Our production brief template covers the agreed requirements you give technical suppliers. Use the decision log to explain significant changes to those requirements, and issue the revised brief or instruction through the agreed supplier process. An entry in your private spreadsheet isn't automatically a contract variation.

Chat remains useful for raising a question or getting an urgent answer. The problem starts when the only record of a consequential choice is a reply halfway through an unrelated conversation. Copy the actual decision into the log, preserve the relevant source and link the resulting instruction back to it.

Avoid creating competing versions of the plan. The decision log should say which layout or schedule is current, rather than becoming a second place where people quietly maintain different arrival times. If a decision changes the schedule, update the schedule and record its new reference in the decision entry.

Name who decides, who records and who follows through

The person maintaining the log doesn't have to approve the choices inside it. On a busy build, a coordinator may capture the discussion while the production lead decides within their agreed authority. Write those names separately so nobody mistakes typing an entry for authorising an order.

Before the build, agree who can approve each kind of change and what requires further acceptance. A director's commercial approval may still depend on the venue accepting a proposed arrangement or a specialist confirming technical requirements. Record those conditions explicitly. Silence from a required reviewer isn't approval.

Someone also needs to own the follow-through. If Maya approves a delivery change but Jo is responsible for updating the schedule, name Jo on that action. "Operations to update" leaves everyone assuming a colleague has done it. Give the person a deadline linked to the actual supplier or crew dependency.

Allow an affected lead to raise a concern even after approval. They may know something the decision maker didn't, such as equipment already dispatched or an access requirement absent from the latest drawing. The record should make that information easier to raise, rather than becoming a reason to defend an outdated choice.

Decide who maintains the record during breaks and absences. The backup needs access, the current entries and a clear start to their responsibility. A colleague who can view the document may still be unable to correct a status or issue the approved instruction.

For each consequential decision, you should be able to identify the approver, recorder and implementation owner. A small team may combine those jobs. Still write down which person approved the choice and which evidence shows it happened. That's more useful than inventing extra roles to make the document look formal.

Use this event decision log template

Keep the main list readable, with a short title and current status for every decision. Put the detailed explanation in the same entry or a clearly linked record. Someone looking for today's loading arrangement shouldn't have to open several anonymous attachments to discover the subject.

Use the following fields as a starting template. You can copy the labels into a shared document or spreadsheet, then remove fields that your event genuinely doesn't need. The completed example later in the guide shows the level of detail to aim for.

• Reference and title: a unique reference followed by the specific choice, such as D014, revised display delivery.

• Event, location and phase: which event, area and part of the build the decision affects.

• Decision time and recorded time: when the choice was made, when it was entered and the time zone used.

• Question and deadline: what needs deciding and when a useful answer is required.

• Current choice: the action approved, rejected or deferred, including what remains outside its scope.

• Reason and alternatives: why this choice was made and why credible alternatives were set aside.

• Evidence and assumptions: the quote, drawing, observation or advice relied on, with its date or version.

• Decision maker and required acceptance: who approved the choice and which other confirmations are necessary.

• Cost and other effects: the full commitment, schedule changes and affected services or promises.

• Action owner and deadline: who issues instructions, updates documents and checks the result.

• Affected people and acknowledgement: who needs the revised instruction and whether they confirmed receipt and understanding.

• Status, review condition and history: what has happened, when to reconsider and which entry replaces an earlier choice.

You don't need a paragraph under every label. Some fields can say "No additional cost confirmed in quote Q18" or "No change to the advertised programme." The useful test is whether someone else can understand the boundary without asking you what "as discussed" meant.

Distinguish a fact from an assumption. A supplier's written acceptance of a booking is different from your coordinator expecting them to accept. Record the expectation as unresolved until the confirmation arrives. If the decision depends on that confirmation, the status must show that work isn't yet released.

The Charity Commission's decision-recording guidance asks charity trustees in England and Wales to keep accurate records with enough explanation to understand their decisions, using more detail for significant choices. This is a useful record-writing principle for commercial events too, without turning charity duties into a legal requirement for your business.

Write the reason while the conversation is fresh. "Venue preference" is weak if the actual reason was that the original delivery would conflict with another confirmed booking. The precise reason tells the next producer what would have to change before the rejected option became sensible again.

Make the status describe what has actually happened

The word "done" is usually too vague for a consequential build decision. It can mean someone has chosen an option, a supplier has received an instruction or the physical work has finished. Those are different points, and another team may depend on knowing which one you've reached.

A proposed entry records a question and possible response before approval. A deferred entry records an explicit choice to wait, with an owner and a useful review condition. A rejected entry preserves an option that should not proceed. None of those states authorises the crew to start the proposed work.

For an approved choice, show any outstanding conditions separately. "Approved commercially, awaiting venue acceptance" tells the reader more than a green approval label. Once the necessary acceptance has arrived, record when the instruction was issued and to whom.

Then distinguish issued from implemented. A supplier acknowledging your message doesn't prove that the equipment arrived, the crew used the new drawing or the public information changed. The implementation owner should check the relevant result and record what they actually observed or received.

An implemented decision can remain current for the rest of the build. Closing its actions doesn't erase the instruction or mean future crews can ignore it. If a later decision replaces it, mark the earlier entry superseded and link directly to the replacement. Keep the reason for the change.

The Association for Project Management's change-control guidance separates capturing and evaluating a request from approval, updating the plan and implementing the change. For an event team, the practical lesson is to check each of those steps rather than compress them into one approval tick.

You can keep decision status and action status in separate fields. That helps when the choice is approved but several departments still have work to complete. Use plain labels your team understands, and agree who can change them. A sophisticated status menu won't rescue an entry nobody maintains.

Handle a failed condition before somebody starts work

Conditional approval needs an answer when the condition fails, as well as when it succeeds. Suppose your venue declines the proposed delivery slot. The commercial approval doesn't become permission to send the vehicle anyway. Keep the decision unreleased, record the refusal and return the affected choice to the authorised person with the new information.

Explain the immediate effect to the people waiting. The supplier needs to know whether its offer is still under consideration, and the receiving team needs to know that the revised time isn't confirmed. An entry saying "awaiting update" can leave both teams preparing for an arrival nobody has booked.

Set a useful next action. The production lead might request another available slot while the director considers the cost and programme consequences. If the first offer expires during that work, record its expiry. Don't leave the old price displayed as an available option after the supplier has withdrawn it.

The same discipline applies after an instruction is issued. If the supplier replies that it cannot meet the accepted booking, record the failed commitment and get the responsible people to decide what happens next. Preserve the original acknowledgement. It may matter commercially, even though it no longer describes what you expect to happen.

An implementation check can also fail. Perhaps the crew receives the correct drawing but the installed item doesn't match it. Record the observed difference and refer it to the appropriate lead. Don't close the action because the drawing was sent, or assume the team can improvise an acceptable correction without the necessary review.

Avoid creating an automatic fallback unless the event has actually approved one. A rejected delivery slot doesn't make the more expensive alternative authorised. A missing acknowledgement doesn't make the old instruction current again. The person with authority needs to resolve the available choices and their consequences under today's conditions.

Where uncertainty remains at handover, make it easy to recognise. State what hasn't been confirmed, which work depends on it, who owns the next contact and when the team will review it. That allows the incoming lead to continue the work without accidentally converting an open question into an approved plan.

Follow one build decision through the record

Let's use a fictional paid exhibition called Northbank Makers Weekend, opening on Saturday 21 November 2026. The selected build work happens on Friday 20 November. Every example time uses UTC+0. All names, times, costs, supplier terms and arrangements below are invented to explain the record. They aren't customer results, market rates or recommended operating intervals.

Sam is the event director, Maya is the production lead, Jo maintains the build schedule, Omar records financial commitments and Amina leads receiving. Leila is the venue contact for the relevant booking arrangement. Their named approvals in this example don't replace other venue, technical or safety requirements for the actual work.

The exhibition has already ordered a display package with a confirmed $2,400 delivery-inclusive cost. These and all later money amounts are USD. The simplified example excludes taxes and any charges not expressly stated. Finance has confirmed that the additional-cost reserve available for these choices is $1,500.

At 09:10 on Friday, the supplier tells Maya the original delivery slot is no longer available. Its revised offer is delivery at 14:00 with an additional $360 charge. A different supplier quotes an additional $620 for an equivalent delivery service, subject to confirming availability and resolving the original delivery arrangement. Neither proposal has been ordered.

Jo creates D014 at 09:15. The question is whether to accept the original supplier's revised delivery or pursue the alternative. The existing supplier needs an answer by 10:00 to hold its offer. That is a fictional supplier deadline, not a general rule for how quickly an event decision should be made.

Maya checks the effect on the build sequence. The relevant teams confirm that the revised arrival can fit their agreed work, provided the venue accepts the booking slot. Omar confirms that the complete $360 additional commitment is affordable within the available reserve. The alternative supplier hasn't confirmed its booking.

What D014 says before approval

The draft entry identifies the exhibition, the display package and the Friday build. It links the original booking, the revised offer and the current build schedule. The entry says no revised delivery has been instructed, which protects Jo from accidentally publishing an unconfirmed time as a booking.

It describes the alternatives plainly. Accepting the existing supplier's offer preserves the ordered package and adds $360. Pursuing the $620 option needs availability confirmation and a separate instruction, while the effect on the original booking would need resolving. The comparison doesn't assume the original supplier would refund any charge.

The reason for Maya's recommendation is therefore more specific than "cheaper." The existing supplier has made a definite revised offer for the package already ordered, and the relevant build sequence can accommodate it if the venue accepts the slot. The alternative has a higher quoted delivery cost and unresolved availability.

NASA's decision-analysis guidance recommends documenting alternatives, assumptions and the final choice, with effort proportionate to the decision. You don't need an engineering report for this booking. You do need to preserve the assumptions that would make the recommendation wrong if they changed.

What approval and release look like

At 09:30, Sam approves the additional $360 commercially, conditional on Leila confirming the venue booking slot. D014 names that condition and stays unreleased. Jo doesn't tell the crew that the new delivery is confirmed simply because the director accepted the price.

Leila confirms the relevant venue slot at 09:40. Maya then issues the revised instruction at 09:45 and receives the supplier's booking acknowledgement at 09:50. Jo updates the build schedule to version 6 at 09:55 and tells affected leads which earlier delivery entry it replaces.

Omar records the $360 commitment once. The display package now has a planned total cost of $2,760, and the additional-cost reserve has $1,140 remaining. The log links to the commitment record rather than maintaining a separate competing budget total.

For a compact completed entry at that point, D014 would read as follows:

• Current choice: accept the original display supplier's Friday 14:00 delivery with the additional $360 charge. No other package change approved.

• Reason: a definite revised offer for the existing package fits the accepted build sequence; the alternative costs $620 and has unconfirmed availability.

• Approval: Sam, Friday 09:30, conditional on venue slot acceptance. Leila confirms that acceptance at 09:40.

• Instruction and plan: Maya instructs at 09:45; supplier acknowledges at 09:50; Jo issues build schedule version 6 at 09:55.

• Financial effect: additional commitment $360; package total $2,760; remaining additional-cost reserve $1,140.

• Outstanding work: Amina checks the actual arrival and agreed delivery requirements, then reports the result to Jo. Delivery action remains open.

The real record would link the actual booking confirmation and schedule and identify Amina as the receiving lead, with her working contact details. This extract demonstrates the wording; it isn't a complete instruction for a real installation.

The decision remains current after those messages. Its actions are still awaiting delivery and the relevant receiving checks. If somebody filters the log for uncompleted work at midday, D014 should appear with the owner of that check and the booked arrival.

At 14:05, Amina confirms receipt of the display package and completion of the agreed receiving check. Jo records that confirmation against D014 and closes its delivery action. The actual arrival time remains visible alongside the booked time. Nobody edits the original booking to pretend the delivery was always scheduled for 14:05.

Record a later change without rewriting the earlier decision

Now suppose the same exhibition needs a second decision about a freestanding information panel in the foyer. This is a separate item, not part of the display delivery. The distinction matters because changing its position shouldn't silently change the supplier commitment under D014.

At 11:00 on Friday, Sam approves D015, placing the panel at the agreed foyer position shown on drawing 4. The relevant venue and operational acceptance is recorded before the crew receives the instruction. Jo issues drawing 4 at 11:10 and records the affected lead's acknowledgement. No additional cost is attached to this position change.

At 12:20, the venue identifies a separate booking requirement that makes the agreed position unavailable. The responsible leads review another position under the event's established arrangements. The log records the new information and the instruction to pause the affected panel work while the alternative is checked. It doesn't say "move it somewhere suitable."

Sam approves the revised business choice as D016 at 12:45, after the required acceptances are confirmed. It specifies the alternative position on drawing 5 and an additional $180 handling charge under a confirmed quote. Maya issues that work instruction with drawing 5 at 12:50. Jo replaces the shared working drawing at 12:55 and obtains acknowledgement from the affected crew lead at 13:00.

D015 stays in the record with its original time and reason. Its current status says D016 supersedes it, and D016 links back to D015. Anyone finding the old decision can see immediately that it no longer controls the work. Drawing 4 is marked obsolete through the team's document process.

At 13:25, Maya confirms the panel work is complete under drawing 5 and the relevant checks are recorded. D016's action can close. Its instruction remains current, while the historical D015 entry remains available to explain why the earlier crew started a different arrangement.

The reserve now reflects both additional commitments. The $360 delivery change and $180 handling charge total $540, leaving $960 of the original $1,500. The superseded panel position had no charge, so replacing it creates no fictional refund. The display package still totals $2,760; the separate panel handling cost isn't added to that supplier's package.

Our guide to reviewing spending against the event budget explains the wider forecast. Here, the key is that replacing a decision doesn't automatically cancel an order or release money. Record the actual commercial consequence, including any cancellation agreement, before changing the financial commitment.

Put the reason in words another crew can use

A useful reason explains why the chosen option fits the circumstances. "Sam agreed" identifies authority, but doesn't explain the choice. "Keep the original package because its revised delivery is confirmed and fits the accepted build sequence" gives the incoming lead something they can check.

Include the decisive constraint rather than the entire discussion. If a replacement depends on an unanswered availability request, say so. If keeping the current option avoids reopening an agreed supplier scope, identify that scope. Someone can then judge whether new information genuinely changes the decision.

Record rejected alternatives fairly. Don't describe an option as impossible when it was merely more expensive or awaiting confirmation. A later producer may be able to use it under different conditions. The log should preserve the quality of your reasoning, including uncertainty, rather than make the final choice look inevitable.

Also record where you chose to wait. "Deferred until the venue answers" needs the person chasing the answer, the next review point and what work remains restricted. Otherwise a deferred decision becomes a quiet instruction for everyone to make their own assumptions.

If the reason was captured after the event, say when it was added and who provided it. Don't backdate a reconstruction to look like a contemporary note. A later explanation can still be useful, but the reader deserves to know whether it comes from the original record or someone's subsequent recollection.

You can correct a spelling error without treating it as a new operational decision. For a substantive correction, preserve the correction history your tool supports and explain the change. Moving a timestamp or expanding an approval's scope after the fact can mislead people about what was known and authorised at the time.

Tell affected people what changed

A log entry doesn't reach someone carrying equipment through the venue. Decide who must receive each resulting instruction and use the communication method appropriate to the work. Then record the acknowledgement where it matters, especially at the point one team's choice changes another team's task.

For D014, the supplier needs the revised booking instruction, Jo needs the accepted time and the receiving lead needs the current delivery details. Other departments only need the effects on their work. Sending everyone the full commercial discussion makes important instructions compete with information they can't act on.

For D016, the crew needs drawing 5 and the instruction that drawing 4 has been replaced. The financial owner needs the $180 commitment. A colleague elsewhere in the building doesn't need the supplier quote merely because they can view the event's general updates.

Ask for a specific acknowledgement. "Received drawing 5 and will use the revised panel position" is more useful than a reaction icon under a long thread. It identifies what the person understood. The responsible lead still checks implementation; repeating the instruction isn't evidence that the physical work is complete.

If a required person hasn't acknowledged, keep that gap visible and follow the agreed contact or escalation route. Don't assume an unopened message has reached a supplier because the rest of your team is ready. Resolve what work can proceed with the responsible people rather than letting the schedule conceal the missing confirmation.

A change can also affect what ticket holders need to know. Once the business has approved that change, our attendee email tools let your team prepare a campaign and send a test before the intended audience receives it. The operator still owns the approved facts, audience choice and any other communication channels needed for the event.

Record that public communication as an action under the relevant decision. Identify the approved wording, owner and sending result. Don't attach a full attendee list to a widely shared production record. A completed send also doesn't prove that every recipient has read or understood it.

Keep permissions appropriate to each job. With Loopyah ticketing, you can give door staff check-in access without sharing the organiser's login. A crew member receiving an operational change doesn't automatically need administrative access to the ticketing account. Your build decision record remains a separate responsibility under the process you've agreed.

Keep the log usable when the site is busy

Choose a tool your actual leads can open on the devices and connection available at the venue. A shared spreadsheet can work well if people understand who edits it and how to find the current entry. A system with more controls may help a larger team, but only if the people doing the work can use it.

Try the record before the build. Ask a lead to find a decision, identify the current instruction and explain what is still unresolved. Test the same task on a phone. If the answer requires sideways scrolling through long notes or opening a folder nobody can access, change the format before relying on it.

Keep a short title, current status and owner visible in the main view. Put detailed quotes and drawings behind descriptive links with version information. Avoid file names that only make sense to their author. "Panel position, drawing 5, issued Friday 12:55" is easier to verify than "final new layout."

Give the team a fallback when the connection fails. That may be a controlled printed extract or an offline copy with an issue time and a named person confirming subsequent changes. An offline copy needs a process for recognising that a newer instruction exists. Printing the log once doesn't keep it current through an afternoon of revisions.

At an urgent decision, use the communication and authority arrangements appropriate to the situation. Don't require someone to finish a spreadsheet before raising an alarm or taking an action required by the emergency plan. Capture the significant decision as soon as practical afterwards, with its actual decision time and later recording time.

When the normal connection returns, reconcile temporary notes with the shared record. Preserve who made the decision and which instruction people actually received. Resolve conflicting entries with the decision owner rather than letting the last person to type overwrite a different account of the choice.

Review current decisions at the build handover

The incoming lead needs the choices that still affect work, including ones whose actions have already closed. D014 matters after delivery because it explains the current commitment. D016 matters after installation because drawing 5 is still the accepted panel position.

The handover should identify unresolved conditions, outstanding acknowledgements and anything likely to need another decision. The incoming lead can then ask about the actual dependencies. Reading a list of references aloud without explaining their current effect won't establish that understanding.

HSE's shift-handover guidance recommends preparation, two-way communication and cross-checking by incoming personnel. It comes from a broader workplace and industrial context. Applied to your event record, the useful practice is for the incoming lead to check what the decisions require, rather than merely accepting a document link.

At the fictional 14:30 handover, Jo tells the next lead that D014's delivery action is complete, its $360 commitment remains recorded and D016 has replaced D015. The next lead checks drawing 5 and confirms that nobody should restart the original panel arrangement. The team doesn't make a new commercial commitment just because responsibility has changed hands.

For a complete producer change, use the wider event handover checklist alongside the record. The log explains significant choices. It won't tell a new producer every contact, contract or operating responsibility they need to take over.

Keep private details in the right place

A decision record needs enough detail to explain and carry out the choice. It doesn't need every piece of personal or commercial information behind it. Give affected teams the instruction and keep restricted evidence accessible only to people whose work requires it.

For an attendee-related decision, the shared entry might say that the access-support lead has confirmed the agreed arrangement. The person's health information belongs in the appropriate restricted process, rather than in a build log distributed to suppliers. Likewise, a supplier bank change belongs in the payment-verification process, not a general operational note.

The UK's Information Commissioner's Office describes data minimisation as keeping personal information sufficient for its purpose, relevant and limited to what is necessary. That guidance concerns UK data protection and is currently marked under review following legislative changes. Check the requirements that apply to your business and the information you're recording.

Keeping history doesn't mean making every old copy available to every crew member indefinitely. Agree access, retention and deletion with the people responsible for your records and obligations. Preserve material required for an active dispute, investigation or other applicable requirement through the appropriate process. Don't invent one retention period for every document the event produces.

Use the record to improve the next build

After handback, review the entries that caused repeated questions, revisions or unplanned costs. Ask what information was missing when the choice was made and whether the current process would catch it next time. A decision that changed wasn't necessarily a bad decision. Conditions may genuinely have changed after the original approval.

For Northbank Makers Weekend, D014 reveals a delivery booking problem worth discussing with the supplier. D016 reveals a venue booking conflict that should be checked earlier in planning. Those are different improvements. Telling the crew to "communicate better" would leave both underlying problems unresolved.

Use the event debrief template to turn the findings into assigned improvements. Link back to the relevant decisions so someone preparing the next event can see the original circumstances. Copying the old log as the new event's approved choices would carry yesterday's assumptions into a different build.

Before your next load-in, take one recent choice that people kept questioning and enter it using the template. Ask a lead who missed the original conversation to explain the current instruction, its reason and the next outstanding action. Correct whatever they can't find, then agree who will maintain that same standard while the crew is working.