Guest Help Desk in 2026: Requests and Escalation
Request a call!

Guest Help Desk in 2026: Requests and Escalation

Ideas and Trends · 36 min read
Guest Help Desk in 2026: Requests and Escalation

A practical help desk setup for a business event: location and opening hours, team roles, the request card, escalation and handover of open requests.

Guests come to the desk not only to ask "where is the hall". Their badge may not scan, their transfer route may change, they may have lost something, or they may have doubts about the ingredients in a dish. Sometimes there is a queue, the programme has already started, and the answer depends on several departments at once. Simply sending someone from one member of staff to another makes the problem more complicated and erodes trust in the team.

At Aventura, we see the help desk as a single point of contact for non-standard requests. The staff member takes the request, separates a routine enquiry from an exception, finds the person who owns the decision and gives the guest a confirmed status. The desk does not replace the specialist departments and does not promise the impossible. Its job is to make sure a question is not lost between registration, the venue, catering, transport, security and the control room.

Leave a request - let's discuss your task

We'll clarify the event format and suggest the next step.

Where does the guest help desk draw the line?

The guest help desk handles non-standard requests, clarifies the desired outcome, provides verified information or refers the matter to the authorised service. It does not become a second reception, a medical room, a security post or a centre for independent decisions. The working formula is simple: one entry point for the guest, several possible decision owners and one feedback coordinator.

Standard event attendee registration covers the usual check-in: it finds the record, issues the badge and directs the guest onward. The help desk steps in when registration instructions are not enough. For example, the access level does not match the invitation, the surname is not on the approved list, an answer from the programme owner is needed, or the issue spans several zones at once.

This division protects the entry flow. Fast operations stay where they belong, while a situation that requires a conversation and verification goes to a separate point. The help desk must not turn into a queue of questions that have already been resolved by signage, the on-screen programme or an ordinary administrator.

It is best to fix the boundaries before the venue opens. We divide actions into three groups:

  1. The staff member decides independently based on the approved knowledge base: shows the route, gives the current session time, explains how to collect materials.
  2. The staff member decides after confirmation: clarifies a badge replacement, hall access, a transport option, an agreed meal or the return of a found item.
  3. The staff member immediately refers the request: a health threat, aggression, signs of fire, a suspicious object, a lost child, or a blocked accessible or evacuation route.

The guest does not have to understand the team structure. They can stay at the desk or receive a clear communication channel. The coordinator finds the right role and reports what happens next. The phrase "that's not us" is acceptable only together with a specific action: to whom the issue was referred, who is responsible and when there will be an update.

The help desk also does not make promises on behalf of others. Staff do not change the programme, do not allow entry outside the rules, do not confirm compensation, do not make diagnoses and do not guarantee transport dispatch. They can confirm only what they have received from an agreed source. This boundary keeps the desk useful and avoids creating false expectations.

Location, opening hours and visibility of the help desk

The help desk is placed on the guest's natural path, but outside the main queue and free movement routes. The desk should be visible after entry control, accessible without stairs and easy to find from key routes. Opening hours are tied not only to the stage programme, but also to arrivals, registration, breaks, the end of the business part, cloakroom collection and guest departures.

A convenient spot is not always right by the entrance. If the desk sits inside the registration line, a complex conversation holds everyone up. If it is hidden behind the cloakroom, a person first walks around the foyer and asks the same question to several staff members. We check the location by walking the actual route: from drop-off or parking to the entrance, registration, halls and exit.

When choosing a location, we consider four conditions:

  1. The guest sees the desk before starting to look for a random staff member.
  2. The conversation does not block the queue, doors, passage or the work of the neighbouring area.
  3. A staff member can calmly take a complaint or a sensitive request without discussing details publicly.
  4. The desk has a quick working contact with registration, the venue, the command centre and the relevant owners.

For a distributed venue, one fixed point may not be enough. In that case the main help desk is supplemented by mobile coordinators or an additional post. They work from the same answer base and in the same log. Otherwise the guest gets different versions, and the team creates several unrelated tickets for one request.

The schedule is determined by the guest journey. The desk may be needed before the programme opens, when speakers and early participants arrive, and after the finale, when questions arise about the cloakroom, lost property and transport. There is no universal opening and closing time. It is set by the programme of the specific event, the venue rules and the actual logistics.

In public information it is better to state the exact location, hours and contact channel. The wording "look for staff at the venue" does not help a person in an unfamiliar building. If the desk's position changes, the update is received simultaneously by wayfinding, registration, the host of the information channel and digital materials.

It is useful to check the help desk location against the staff deployment plan. It shows when the post is being prepared, who takes over the shift, where the reserve is and how the break is covered without the single point of contact disappearing.

Who works at the desk and what do they decide?

The desk is staffed by a clear chain of first-line operators, a shift supervisor and functional owners. The operator receives and clarifies requests, the supervisor handles disputed cases and monitors workload, and the specialist role confirms the decision. The event manager steps in when an issue affects rules, costs, reputation, the official position or several services at once.

We use the following division of responsibilities:

Table. Who works at the desk and what do they decide?

The table summarises the key points of this section: Role, What they are responsible for, What they do not do on their own. Use it as a quick reference when preparing an event.

RoleWhat they are responsible forWhat they do not do on their own
first-line operatorreceives the request, checks the answer database, creates a ticket, reports the statusdoes not change access rules, the programme or contractor terms
help desk supervisorconfirms the category, redistributes requests, brings in deputies, monitors shift handoverdoes not make a specialist decision without authority
decision ownerprovides a substantive answer on registration, venue, catering, transport, accessibility or another functiondoes not give the guest conflicting information outside the ticket
feedback coordinatormaintains contact with the guest and reports updatesdoes not stand in for the decision owner
duty managerresolves issues that affect several functions, the budget or reputationdoes not take on every routine request

The decision owner and the liaison coordinator are often different people. The catering representative knows what is in a dish. The desk coordinator knows where the guest is, what answer they are waiting for and when the information will still be useful. Simply giving someone the phone number of a specialist employee means the single point of help stops working.

Before opening, every operator needs:

  • an up-to-date venue map and consistent zone names;
  • the programme with the latest changes marked;
  • contacts for owners and their deputies;
  • a database of approved answers;
  • rules for access, substitutions and returning lost property;
  • the limits of their own decision-making;
  • an urgent escalation channel;
  • procedures for handling complaints and personal data.

For a complex project, we link the desk roles to the overall event responsibility matrix. It shows who has the authority to approve a decision, who needs to be involved and who should be informed of the outcome. The help desk translates overall authority down to the level of a specific guest request and works within the team's single framework.

Nameless addressees are especially risky: "passed to the technicians", "checking with the venue", "transport is handling it". The ticket must show a specific role and a working contact. If that person is unavailable, a pre-appointed deputy takes on the issue. This approach is faster and more honest than expecting the first line to resolve everything on its own.

We also determine who has the right to communicate official information about a serious incident. The desk operator does not comment on causes, casualties or the actions of the services based on their own version. They use the approved wording and refer the request to the designated spokesperson.

What requests does the help desk handle?

The help desk handles questions that fall outside the standard scenario, require verification, or span several functions. The category immediately routes the request along the right path. A question about the programme, an access error, a complaint, an allergy symptom and a report of a missing child cannot go through the same queue and be closed with the same answer.

A working classification might look like this:

Table. What requests does the help desk handle?

The table summarises the key points of this section: Category, Examples, Decision owner. Use it as a quick reference when preparing an event.

CategoryExamplesDecision ownerHelp desk first response
informationprogramme, hall, cloakroom, materials, Wi-Fihelp desk or programme ownercheck that the information is current and provide the source
access and registrationname error, no record, re-entry, badge levelregistration or access servicekeep the guest out of the main queue and verify the basis
programme and business servicessession moved, meeting with a speaker, meeting room, materialsprogramme directorateclarify the desired outcome and pass it to the owner
venue and comforttemperature, cleaning, charging, quiet zone, restroomvenuerecord the location and impact, request action
accessibilitystep-free route, assistance, materials format, seating in the hallaccessibility coordinator and venuedo not require a public explanation of a diagnosis, find a workable option
cateringingredients, allergens, agreed diet, menu mismatchcatering managershow confirmed data or call the owner
transportshuttle, parking, boarding, route changetransport coordinatorstate the source and time of the update
lost and foundlost or found item, document, cardvenue or securitycreate a record and follow the storage rules
complaintservice quality, staff behaviour, discrimination, privacyshift supervisor or a separate processaccept without public argument, agree the response channel
safety and healthsigns of fire, aggression, injury, suspicious itemspecialist service and emergency servicespass on immediately per protocol, do not wait in the normal queue

The classification remains an internal tool for a specific event. It is not a mandatory standard or statistics. The team may merge or split categories if the routes differ. What matters is that each category leads to an owner, a clear action and a next status.

It helps to separate information from exceptions. If a hall is easy to find on the current floor plan, the question is closed straight away. If a passage is closed, a lift is out of order or a sign points to an inaccessible area, that is already an operational request. It requires checking the route, the venue owner and feedback.

In a multi-track programme, the help desk does not promise a seat in a full hall and does not change a session registration. It clarifies the rules with the hall owner, checks an alternative and returns a confirmed option. When organising conferences, we designate owners for halls, the programme, speakers and guest services in advance so that such requests do not get stuck between teams.

A category may change once details are clarified. The phrase "I feel unwell because of the food" first sounds like a catering question, but with symptoms it immediately moves to the medical route. The message "I can't get into the hall" may be a badge error, an accessible-route problem or a security restriction. That is why the operator briefly checks the facts and the desired outcome before choosing a category.

We publish practical materials on preparing the team and guest services in Aventura's Telegram channel.

A request record without unnecessary data

One request should live in one up-to-date record. It captures the context, owner, status and next step, but does not collect information "just in case". The record helps pass an issue on without distortion, keep track of what was promised to the guest and close the request based on the outcome. It does not replace a medical record, a security service document or an official complaint.

Minimum set of fields:

  1. Unique number and time received.
  2. Channel and location of the request.
  3. A brief wording in terms of action: what the person needs to receive or do.
  4. Category and impact on the guest's participation.
  5. The nearest point after which the answer will no longer make sense.
  6. What has already been checked and which source was used.
  7. Decision owner and their deputy.
  8. Feedback coordinator.
  9. Agreed channel and time of the next update.
  10. Current status, last action and next step.
  11. Outcome, closing time and confirmation that the answer was passed to the guest.
  12. A note on handover to the next shift if the request remains open.

The request wording must be specific. "The guest is unhappy" does not trigger an action. It is more useful to write: "need to check whether the seat in the hall can be changed because the aisle is inaccessible, and report the result before the next session starts". Here the task, the owner and the critical moment are all visible.

The guest's contact details are not always needed. If the person is waiting at the desk, a record number or a conditional identifier is enough. Name and phone number are recorded when the answer cannot be returned without them. Passport data, diagnosis, details of disability, bank card number and other sensitive information are not transferred to a shared log without a specific lawful purpose.

We separate the general working status from restricted materials. For example, the record can say: "the medical service has accepted the request, further information is held by the relevant service". Details of health status are not needed by help desk operators. The same applies to security service documents, personal details of a complaint and identity confirmations when handing over a valuable item.

Access to the log is set by role. The first line sees the information needed for contact and status. The shift supervisor receives extended access. Specialised applications remain with the relevant service. The retention period is tied to the purpose of processing and the operator's rules, not to the convenience of an eternal archive.

In the Russian context, records must be designed with the principles of Federal Law No. 152-FZ in mind: the purpose of processing must be specific, the data must correspond to that purpose and must not be excessive. So a field is added not because it "might come in handy", but because a clear action cannot be performed without it.

How should requests be triaged by risk?

Initial triage of requests is needed so that a dangerous situation does not have to wait alongside an ordinary question about the programme. The operator assesses the potential harm, urgency, scale and the limits of their authority. The guest's status and the loudness of the complaint do not determine priority. After assessment, the request is routed: immediate handover to the relevant service, an urgent operational decision, standard service handling, or a ready information response.

We triage requests by risk in the following order:

  1. First we check for signs of a threat to life, health and safety.
  2. Then we establish whether the issue involves a child, a vulnerable adult, personal data or an accessible route.
  3. We assess whether the problem concerns one person or could affect a group of guests.
  4. We determine the nearest point at which the answer will stop being useful.
  5. We check the first line's authority and whether an approved answer exists.
  6. We assign the decision owner and the time of the next status update.
  7. We tell the guest what will be done and how they will receive an update.

Immediate handover is required for medical symptoms, signs of fire, aggression, a suspicious item, a lost child, a threat to an evacuation route and other situations covered by the venue's plan. The operator does not conduct their own investigation and does not keep the person at the desk in order to fill in every field. The relevant assistance is launched first, then the record is completed.

An urgent operational decision is required when there is no direct threat, but delay would noticeably worsen the situation. This includes a mass access error, a closed route, the absence of pre-agreed accessibility provision, incorrect information about a dish's ingredients, a shuttle failure before departure, or a programme change that has not yet reached guests.

A standard service request follows the standard route. But "standard" does not mean "sometime". The coordinator still names the next checkpoint. If there is no ready solution, the guest receives an interim status: who is checking the issue, what has already been confirmed and when the next message will come.

Escalation is needed if:

  • the request is beyond the operator's authority;
  • there is a risk to people, property, access or the running of the programme;
  • the decision affects several functions;
  • an exception to an approved rule is required;
  • costs, compensation or an official position are possible;
  • the owner does not respond by the agreed checkpoint;
  • the guest disputes the first line's decision;
  • the problem recurs and could affect other participants.

Issues that affect several functions are passed to the event command centre briefly and without losing the essence: card number, location, facts, impact, the decision needed and the deadline by which it is required. The phrase "sort out the guest at the desk" does not give the command centre the material to make a decision.

Not every request becomes an incident. A request is moved to the dedicated event incident log when it affects safety, access, property, the stable running of the event, or requires a separate chronology of decisions. An information question, a one-off badge replacement and an ordinary comfort request remain in the help desk log.

When organising business events, we test this chain before guests arrive. The team runs through several types of requests, makes sure the contacts work, the owners understand their authority, and the first line can communicate an interim status without unconfirmed promises.

Lost property and the child search protocol

Lost property and a report of a missing child require different procedures. For an item, the help desk creates a record, stores it in a secure place and checks identifying features before handing it over. For a child or a vulnerable adult, a separate safeguarding protocol involving the safety officers is triggered immediately. Such a case must not be handled as ordinary lost property.

For a found item, the working procedure is as follows:

  1. Record the time, the place of discovery and a neutral description.
  2. Move the item to a pre-designated secure location.
  3. Do not publish all the distinguishing features.
  4. If the owner comes forward, ask them to describe the item and the circumstances of the loss themselves.
  5. Check additional features in line with the venue's rules.
  6. Record to whom, when and on what basis the item was handed over.
  7. Apply a separate route for documents, bank cards, medicines and dangerous items.
  8. Hand over unclaimed items according to a pre-established procedure.

No universal storage period should be invented. It is determined by the venue's rules, the nature of the item and the agreed process. The guest is told the actual contact channel after the event and the conditions for further verification. If the item is not found immediately, the record stays open, and a specific member of staff is responsible for further contact.

Valuable items must not be left on a visible shelf behind the desk. A full description should not be posted in a general chat or a public notice either. Otherwise anyone could repeat the features and demand the item be handed over. The working channel only needs the record number, the general category and the contact of the person responsible.

With a lost child, the procedure changes completely. Front-line staff immediately notify the designated service and the shift supervisor. The child is moved to a pre-defined safe and recognisable area. The team acts in line with the venue's agreed protocol, does not disclose unnecessary personal data and does not leave the child with a single member of staff if the project's rules require two trained adults to be present.

A public address announcement must not disclose information that could create an additional risk. The wording and the decision to make an announcement are determined by the responsible service. The person who comes to collect the child is checked according to the project's procedure. The desk operator does not hand the child over simply because an adult confidently states a name.

For events involving employees' families, this protocol is linked to the overall organisation of the family day. The entrance and exit of the children's area, the rules for handing a child over, the contacts of those responsible, the safe waiting area and interaction with the venue are defined in advance. Having a help desk does not replace this preparation.

International safeguarding recommendations are useful as an organisational reference point, but they are not automatically a Russian norm. Specific actions must be agreed with the security service, the venue, those responsible for children's areas and the applicable requirements of the specific event.

How can we help with accessibility and catering?

The help desk helps guests get an accessible route and accurate catering information, but it does not collect diagnoses or give medical guarantees. Staff know where the accessible entrance, lift, restroom, seating area and responsible role are located. For the menu, they only show confirmed ingredients or connect the guest with a catering representative.

Accessibility begins before a guest approaches staff. The desk must be on an accessible route, have readable signage and space for a conversation with a person in a wheelchair. Information cannot exist only in small print or only in a voice announcement. If digital materials are used for the programme and routes, their accessibility is also checked in advance.

We train front-line staff to neutrally clarify the required action. Instead of asking “What is wrong with you?”, staff ask: “What route or format of assistance do you need right now?” A person does not need to publicly explain a diagnosis in order to find the way to the lift, request assistance or receive materials in an agreed format.

If an agreed adaptation is not available, the operator does not promise that “everything will be fixed right now.” They immediately involve the venue owner and accessibility coordinator, look for a safe temporary solution and inform the guest of the next status. Assistance should not be presented as a full replacement for an accessible route.

Russian Federal Law No. 181-FZ establishes conditions for access to facilities and services, independent movement, assistance and necessary help in prescribed cases. For a specific event, the applicability of requirements is assessed based on the venue, service and roles of the parties. The help desk remains part of the service, not proof that the entire event is accessible.

On catering matters, the front line works only with current data from the responsible operator. When organising catering, it is determined in advance where the approved ingredients are stored, who confirms allergen information, how agreed meals are marked and what to do if there is a discrepancy between the card and the actual dish.

The operator can:

  1. Show approved information about ingredients and allergens.
  2. Clarify the status of a pre-agreed meal.
  3. Connect the guest with the responsible catering representative.
  4. Record a discrepancy and stop the transmission of an unconfirmed answer.
  5. In case of symptoms, immediately call medical assistance according to the venue protocol.

The operator cannot promise that a dish is definitely safe if the supplier has not confirmed the ingredients and possible cross-contact. They do not give a diagnosis, treatment advice or predict a reaction. If information conflicts, the correct answer is honest: “We cannot confirm the ingredients, so we have passed the question to the responsible person and do not currently recommend relying on the unconfirmed card.”

UK recommendations on unpackaged food emphasise the accuracy, currency and accessibility of allergen information, as well as the need for a prepared conversation with the guest. For a Russian event, this is international practice. Applicable obligations are determined by Russian regulation and the specific catering model.

Transport requests and route changes

For transport, the help desk reports only confirmed data, indicating the source and time of verification. The desk helps guests find the boarding point, parking, shuttle or a new route around the venue, but does not promise the arrival of a plane, train, taxi or bus. It immediately passes any mass delay to the transport coordinator, the programme team and the duty manager.

A transport request often loses its value quickly. If a bus departs after the final block, an answer an hour later is already useless. That is why the card records a specific checkpoint event: boarding time, entrance closing, the start of the relevant session or a guest's departure.

The first line must know:

  • the current drop-off and pick-up points;
  • the available route from transport to the entrance;
  • the contacts of the carrier and the transport coordinator;
  • the procedure for changing the passenger list;
  • the backup channel if communications are unavailable;
  • the source of information about a delay;
  • who is authorised to change the route and departure time.

If the carrier confirms a change, the guest receives a wording with the update time: "According to the transport coordinator as of 18:20, boarding has been moved to the north entrance." If there is no confirmation, the pause must not be filled with a guess. It is better to say that the request has been accepted, name the owner and give the time of the next check.

In the event of a mass delay, the desk does not answer each person with different words. The command centre approves a single status, and wayfinding, the host of the information channel and mobile coordinators disseminate it synchronously. Individual request cards are still needed if a guest has a special route, accessibility needs or a transfer.

It is convenient to prepare the overall transport framework together with logistics and transfers. We link the schedule to the programme, boarding points, contacts along the route and the procedure for updating data. The help desk becomes a channel of assistance, but does not replace the carrier's dispatch function.

Complaints, privacy and calm feedback

A complaint is accepted without argument at the desk, the facts and the desired outcome are clarified, and then the process owner and the response channel are named. The employee does not promise punishment, compensation or dismissal. They also do not discuss personal details in front of a queue. If the request contains a security threat or discrimination, it is immediately routed to a separate protected channel.

The first response shapes the rest of the conversation. The phrase "those are the rules" shuts down communication but does not explain what will happen. It is more useful to acknowledge the request and name an action: "I have logged the issue and will now confirm who owns the decision. Let's agree on how you would prefer to receive the answer."

How to handle a complaint:

  1. Let the person explain the substance calmly, without a public argument.
  2. Clarify the observable facts, the consequences and the desired outcome.
  3. Separate the complaint from an emergency threat and from a routine service request.
  4. Explain who is reviewing the matter and what steps are possible.
  5. Agree on the channel and the next checkpoint.
  6. Record the key wording without judgmental diagnoses or labels.
  7. Share the materials only with the roles that need them to resolve the issue.
  8. Provide a confirmed answer or explain the further process after the event.

Not every complaint is closed on site. Sometimes records need to be checked, several employees spoken to, or the position of the service owner obtained. In that case the help desk records who will continue the work after the event, which contact may be used and when the person will receive the next update. A universal timeframe cannot be promised unless it has been approved for a specific process.

Privacy is especially important when health, accessibility, another person's behaviour or personal data are involved. An open desk is not suitable for a detailed investigation. The employee offers a calmer place or a protected channel, but does not take the guest away without explaining who will continue the conversation.

The complaint record keeps only the information needed for review. Assessments such as "aggressive guest" are replaced with observable facts: what words or actions occurred, who was present, what the person requested and what action the team took. This reduces the risk of distortion and helps the owner make a decision based on verifiable information.

The British Parliamentary Ombudsman recommends acknowledging receipt of a complaint, clarifying its subject, impact and desired outcome, explaining the process and naming the person responsible for the final response. We use this model as an organisational reference. For a private event, the procedure is determined by the contractual framework, applicable Russian law and the project rules.

How should you hand over a shift and close requests?

A request is closed once the guest has received the result or a clear next step. The message to the owner alone only marks the start of work. If the shift ends earlier, the open card passes to a specific coordinator with a promise, a deadline, an owner and a blocker. After the event, the team continues only the agreed communication with the guest and reviews recurring causes without copying unnecessary personal data into the general report.

For statuses, it is best to use precise wording:

Table. How should you hand over a shift and close requests?

The table summarises the key points of this section: Status, What it means, What should happen next. Use it as a quick reference when preparing an event.

StatusWhat it meansWhat should happen next
answer givenconfirmed information has been passed to the guestcheck whether a next step is needed
passed to ownerthe relevant role has accepted the requestset a time for the update
awaiting confirmationa decision has been proposed but not yet approveddo not present it as fact
guest follow-up requiredthe issue was not closed on sitekeep the contact, the owner and the checkpoint
closed with explanationthe desired solution is not possiblestate the reason and the available next channel
passed to a separate processthe request is handled by security, medical, the claims process or lost propertyleave only a working status note at the help desk

Shift handover is based on open cards, not on a general account of the day. The incoming employee should see:

  1. What exactly the guest asked for.
  2. What they have already been told and what was promised.
  3. Who owns the decision and who is their deputy.
  4. Which facts are confirmed.
  5. What is blocking the next step.
  6. When the status needs updating.
  7. Which channel to use to contact the guest.
  8. Where the related materials are, with the appropriate access level.

It is useful to hold a short in-person or voice handover for critical records. A single mark in the table is not enough if the new coordinator has not understood the context. A shift is considered accepted when the person sees the upcoming checkpoints and explicitly takes on the feedback role.

Closing also requires verification. A message from the relevant service saying "done" does not yet prove the result. The coordinator checks whether the guest has received the information they needed, whether they managed to follow the new route, whether they collected the item, or whether they understood the follow-up procedure. If the action remains with the guest, they are given specific instructions and the card number so that the story does not have to be repeated from scratch.

After the venue closes, the senior help desk collects unfinished requests and assigns owners. Guests receive only the updates that were promised. The general report is built by category and cause: where there was no owner, what information was out of date, which questions recurred, where the handover was lost, and which non-standard request could be turned into a standard service route.

The review should not turn into a search for someone to blame. If ten people asked for directions to the same hall, first check the signage and the visibility of the signs. If several guests received different answers about the transfer, check the source of the update and the channel used to distribute it. The log helps identify systemic gaps based on facts.

Before the next event, we update the answer base, contacts, escalation map and training scenarios. An outdated document is more dangerous than no document: it creates confidence but leads to the wrong owner or the wrong route. That is why every working file should have a version date and a responsible role.

Leave a request and we'll discuss your brief

We'll clarify the event format and suggest the next step.

For this article, we selected nine accessible HTTPS sources: official materials from international organisations, government agencies and an educational institution, as well as current Russian legal texts. International documents are used as organisational practice, not as a mandatory standard for a private event in Russia. Specific requirements should always be checked against the venue, the event format and applicable law.

Frequently asked questions

Sources

Was this article helpful?

Request an estimate

Leave a request, and we will call you back soon

We will organize a unique event for you; all that's left is to clarify the details.

We will calculate the cost of your event