How to Manage Exhibition Supplier Requests?

During trade fair preparation, requests for electrical connection, furniture, stand setup, cleaning, or technical service often begin with a simple email. Subsequently, attachments, phone notes, and new subject lines circulate among the exhibitor, organizer, and supplier. While one person says “approved,” another might be looking at an old offer; when delivery times change, it can become unclear which message is current. The issue isn't using email, but trying to manage an operational request in an email chain without status, responsible party, and financial information.

Why do email chains break as the trade fair grows?

In a small event, a few requests can be finalized with personal follow-up. When the variety of halls, exhibitors, and services at a trade fair increases, the same method creates an invisible work queue. The exhibitor might use a different catalog name, the supplier might write their own order number, and the organizer might proceed using the stand number. Without a common record, the same task is tracked under three separate names.

During intense preparation periods, the problem isn't just lost messages. New team members try to establish context by reading past communications; requests pending in an absent employee's inbox go unnoticed; verbal changes don't match records. Whether a technical service request has received organizer approval or what stage a product request is at is re-asked in meetings. This repetition slows down decision-making.

Typical consequences reflected in operations

• Multiple records or conflicting delivery information for the same request
• Pending tasks only becoming visible when the exhibitor calls again
• Reasons for approval and rejection remaining in personal inboxes
• Inability to evaluate supplier performance with concrete records at the end of the season
• Weakening of the link between financial transactions and product or service requests

Business impact: a cost greater than delay

Uncertainty in request management risks on-site delivery, but its impact is not limited to this. The operations team spends time on coordination instead of planning because they are constantly asking for status updates. The supplier interprets which task is a priority based on their own inbox. The exhibitor, on the other hand, assesses whether the organizer is in control of the process by looking at the speed and consistency of the responses they receive.

Data clutter also affects the finance team. When information about which product or service was requested, whether the request was approved, and where the related financial transaction is located is kept in separate sources, reconciliation takes longer. In the end-of-season evaluation, it's not reliably visible how many requests were received, at which stage bottlenecks occurred, or which category requires more support.

Practical method: link the request to a common lifecycle

A good transition doesn't start by telling the team "don't send emails." First, it's necessary to define the request types and the statuses each type will progress through. Although product and service orders and service requests for breakdowns or field support may seem similar, their approval and delivery steps can differ.

1. Simplify the catalog: Gather the services that participants might request in a single catalog with clear names, descriptions, and necessary information.
2. Standardize identity: Associate each request with an event, participant, booth, service, and supplier. Eliminate reliance on the subject line.
3. Define statuses: Formalize the meaning of the stages appropriate for your organization, such as New, In Review, Approved, Rejected, or Completed.
4. Separate approval gates: Separate services requiring organizer approval directly from orders; determine who will make decisions.
5. Establish responsibility and handover rules: Keep visible which team or supplier a pending request is with. Use role-based ownership instead of person-dependent mailboxes.
6. Define closing criteria: Define the difference between “answered” and “delivered”; record the outcome of the closed request.

Email can still be a notification or communication channel. However, the current status of the request, its associated service, and the decision should be kept in a central record. This way, teams look at the same operational screen instead of searching for messages.

How does QEMENT centralize this process?

QEMENT brings together organizers, exhibitors, and suppliers within the same trade fair operation. Portal access is defined through supplier registration and authorized personnel assignment. Options that exhibitors can request become visible through the product and service catalog; requests are tracked with a status workflow. In service requests, the organizer's approval or rejection process is carried out under record.

Product and service requests such as stand setup, furniture, and electricity, along with operational service requests from the exhibitor side, are handled within the same platform context. While the supplier responds to relevant requests in their own portal, the organizer can see pending tasks. Thus, questions like “who requested what, who responded, which request is pending?” are not dependent on personal correspondence.

Financial visibility is also part of this chain. Suppliers can view their financial transactions in the portal; the exhibitor lifecycle progresses without disconnecting from request and finance screens. QEMENT’s existing request management, catalog, and portal features are available for live operations. Capabilities such as AI-powered request prioritization or catalog enrichment are on the roadmap; they should not be considered an existing part of today's operations.

Which indicators should be monitored?

Measuring success solely by the total number of requests is misleading. An increase in volume may indicate that more work is being recorded, not that the system is performing worse. Choose indicators that collectively describe the process:

• Number of open requests by status and service category
• Time between initial registration and first action
• Age of service requests pending approval
• Distribution of reasons for rejected requests
• Ratio of completed to re-opened requests
• Request density by event, hall, stand, or supplier
• Trend of status inquiries received via email or phone regarding requests

Reading these indicators with consistent definitions in weekly preparation meetings reveals bottlenecks. The goal is not to pressure the team with numbers, but to understand whether delays are caused by catalog issues, approvals, capacity, or missing information.

Frequently asked questions

Should email be completely eliminated?

No. Email can be used for notifications and explanations. The critical point is that the request's final status and decision history must reside in the central system.

Should product requests and service requests be in the same workflow?

Not always. A product or service request selected from the catalog and a field service record requiring organizer approval may have different decision steps. Workflows should be separated while maintaining common identity and visibility.

Why should the supplier be included in the system?

Supplier responding via the portal reduces the re-entry of information by the organizer. With authorized assignment, access is also brought into a corporate framework.

Where to begin the transition?

Select two or three service categories that are the busiest and generate the most status inquiries. After clarifying the catalog, approval, and closing rules within this scope, expand to other categories.

Convert request traffic into an operational record

In trade fair supplier management, the goal is not to send more messages, but to make the ownership and outcome of each request visible. Review how QEMENT's supplier portal combines product and service catalog, status flow, service approval, and financial visibility within the same operation on the features page. To evaluate the request flow at your own trade fair, contact the QEMENT team.

Request types and approval steps should be structured according to the organization's service model.