The number of people is not enough to design the technology, so the brief should also include information about the layout of the space.

The most useful are:

• dimensions of the room,
• height,
• layout,
• position of the stage,
• layout of the audience,
• additional zones,
• distance of the farthest participants from the stage.

It matters whether the audience:

• is sitting theatrically,
• is sitting at tables,
• is standing,
• is located in several sections.

For audio, this changes the way the PA coverage is done.

For multimedia, it affects the size and number of screens.

For lighting – it affects the construction possibilities and the placement of fixtures.

If a room layout or site plan is available, it is worth including it in the brief. Even a simple plan with the stage and audience marked can be more useful than several paragraphs of description.

The brief should specify who will be appearing on stage and what they will need. It is not yet about a full stage plan, but about the general scope of stage users.

It is worth providing:

• the number of hosts,
• the number of speakers,
• panelists,
• artists,
• the DJ,
• the band,
• additional guests.

If the following are planned:

• stages,
• risers,
• a podium,
• chairs for the panel,
• backline,
• decorations,

it is also worth noting.

For the technical team, it is important whether the stage will change its function.

Example:

• in the morning a conference,
• in the evening a concert.

This may mean the need to rearrange:

• monitors,
• microphones,
• furniture,
• backline,
• elements of the scenery.

The earlier the company knows about such changes, the better it can plan the workflow.

In the audio section, it is best to describe the functions that the system should provide, rather than specifying particular devices.

You can specify:

• the number of speakers,
• panel,
• questions from the audience,
• concert,
• the DJ,
• playback,
• streaming,
• recording.

Example:

"Host + 5 panelists + 2 microphones for audience questions. After the conference part, a concert by the band."

Based on this, the company can determine:

• microphones,
• wireless system,
• PA,
• FOH,
• monitoring,
• routing.

If high speech intelligibility is important, it is worth stating it directly.

There is no need to independently choose the number of columns or the power of the system.

If the event involves several technical departments, comprehensive technical service of the event allows for designing audio together with lighting, video, and stage.

In the lighting section, it is good to describe what functions the light should perform.

It may involve:

• lighting for speakers,
• lighting for the stage,
• decorative lighting,
• color branding,
• dynamic concert lighting,
• work under cameras.

The requirements for a conference are different from those for a gala or concert.

Example of a brief:

“Conference part: even lighting for the hosts and panel. Gala: more dynamic scenes. Concert: full realization of stage lighting.”

Such a description gives the designer significantly more information than:

“We need 20 lights.”

If cameras will be used, this should also be noted in the lighting section, as exposure and color affect the image.

Multimedia should be described by the type of content and the way it will be used.

In the brief, it is worth indicating:

• presentations,
• videos,
• graphics,
• branding,
• video sources,
• LED wall,
• projection,
• confidence monitor,
• IMAG.

IMAG means the image from cameras displayed on screens for the audience present at the event.

For presentations, it is worth specifying:

• how many speakers there will be,
• whether presentations will be collected in advance,
• whether participants will bring their own laptops,
• whether stage previews are needed.

If materials are already available, it is good to send:

• resolutions,
• aspect ratios,
• sample files.

However, there is no need to independently resolve issues of switching, scaling, EDID, or HDCP. This should belong to the design of the system.

If the event is to be broadcast or recorded, the brief should specify the purpose and expected outcome.

It is worth indicating:

• whether live streaming is needed,
• the target platform,
• the number of cameras,
• graphics,
• PGM recording,
• ISO recording,
• subsequent post-production.

PGM is the final program, meaning the material produced as a finished image of the event.

ISO recording means independent recording of individual sources, e.g., cameras.

Audio is also important.

One should not assume that the FOH mix is automatically suitable for streaming. The online audience does not hear the acoustic sound of the stage, which is why a separate mix or additional routing is often needed.

If it is still unknown whether streaming will be implemented, it can be marked as an option for pricing.

If artists are performing at the event, their riders should be attached to the brief as early as possible. They can significantly change the requirements for the system.

A rider may include:

• PA,
• FOH,
• MON,
• input list,
• stage plan,
• RF,
• microphones,
• backline,
• risers,
• power.

If the document is not yet available, this should be noted.

Example:

"Band concert – the rider will be sent after final confirmation from the artist."

The company can then prepare a preliminary scope based on assumptions, but should leave room for later adjustments.

If the rider is already there, it is not worth rewriting individual points in the brief. It is best to attach the entire document and indicate that it is part of the specification.

The brief should include not only the hours of the event itself, but also access to the venue before and after it.

It is worth providing:

• from when the room is available,
• when load-in is possible,
• setup hours,
• rehearsals,
• soundcheck,
• opening doors,
• event start,
• end,
• load-out.

Example:

"Access to the room from 8:00, technical rehearsal 15:00, rehearsal with the host 16:00, guests from 18:00, end 23:00, dismantling immediately after the event."

For the technical company, this is very important, as limited time can affect:

• the number of technicians,
• the way of setup,
• logistics,
• cost.

If the schedule is still a draft, it is enough to mark the hours as approximate.

The more data about the venue, the more accurately the implementation can be designed before arriving on site.

The following are useful:

• technical documentation,
• room plan,
• height,
• rigging possibilities,
• power,
• internet,
• transport routes,
• elevators,
• ramps,
• noise restrictions,
• time restrictions.

If the venue provides part of the technology, it must be clearly stated.

Example:

"The venue provides a stage 8 × 4 m and basic power. Audio, lighting, and multimedia are the responsibility of the production company."

This prevents duplication of scopes.

If the venue has its own PA, it should also specify:

• model,
• configuration,
• available control,
• limitations.

The company will be able to assess whether the system can be used or if additional equipment needs to be brought.

Providing a budget can help the company prepare a solution that fits real financial capabilities, but it is not mandatory.

The budget is particularly useful when:

• there is a hard limit,
• the project has many variants,
• it is unclear what level of solution will be appropriate.

Example:

"Technical budget: up to about 40,000 PLN net, priority on audio and multimedia, lighting can be simplified."

Such information allows the designer to allocate resources according to priorities.

If you do not provide a budget, you can instead ask for:

• basic variant,
• extended variant,
• optional elements.

It is not advisable to artificially hide the budget if it is very limited. The company may then spend time preparing a project that does not fit within realistic parameters from the start.

At the briefing stage, the organizer does not need to know:

• how many columns are needed,
• what should the console be,
• how many moving heads to use,
• what pixel pitch LED to choose,
• how to manage routing.

They also do not need to know all the details:

• the patch,
• the network,
• DSP,
• rigging.

These are elements of the technical design.

In the brief, however, it is important to describe well:

• the problem,
• the function,
• the expected effect,
• limitations.

Example:

Instead of:

"We need 8 columns."

better:

"The entire audience must have uniformly understandable speech."

Instead of:

"LED 6 × 3 m."

better:

"Presentations must be readable from the last row, the room is 25 m long."

Such data allows the company to design a solution based on actual needs.

If the client is just starting the process, helpful will be material on how to order professional technical support for the event.

Before sending the brief, it is worth checking if it contains all the available information from the list below:

• Name / type of event
• Date
• Location
• Venue
• Number of participants
• Layout of the room / area
• Space plan
• Dimensions
• Stage
• Script
• Agenda
• Host
• Speakers
• Panelists
• Artists
• Technical rider
• Audio
• Microphones
• Concert / DJ
• Lighting
• Multimedia
• Presentations
• Films
• LED / projection
• Cameras
• IMAG
• Streaming
• Recording
• Access to the venue
• Load-in
• Rehearsals
• Soundcheck
• Start time
• Load-out
• Power
• Internet
• Rigging
• Venue restrictions
• Scope provided by venue
• Scope provided by organizer
• Budget or priorities
• Unconfirmed elements
• Contact person

At the end of the brief, it is good to add:

"Please indicate any missing information and elements, that require further agreement."

This allows the company to actively complete the document instead of making assumptions without confirmation.

If the brief is already ready, it can serve as a basis for starting collaboration with the technical company in organizing the event and preparing a specific concept and offer.

A good technical brief for an event should describe the event from the perspective of needs, not a list of equipment. The most important are the date, location, scenario, participants, space, stage, audio, lighting, multimedia, streaming, riders, and schedule.

The organizer does not have to design the system themselves. Instead, they should clearly describe the functions, priorities, and limitations and indicate data that is not yet final.

The brief is particularly valuable when several companies have to prepare an offer or the event involves many interdependent systems. The better the input data, the less guessing on the part of the contractor and the greater the chance that the technical design will meet the actual needs of the event from the start.