Exhibitor portal management: a workflow guide for event organisers

Decide whether the event needs a managed portal

A small event with one exhibitor type and very few forms may be manageable through a controlled form and shared document process. A portal becomes more valuable when exhibitors have different packages, many compulsory actions, chargeable services, artwork reviews, staged approvals or multiple teams answering the same status questions.

Use operational complexity rather than exhibitor count alone as the test. If the organiser cannot quickly identify who has ordered power, submitted artwork, accepted the rules or missed a deadline, the process needs a clearer system of record.

• Several exhibitor, sponsor or pavilion packages with different entitlements
• Compulsory forms and documents owned by different internal teams
• Chargeable furniture, power, internet, AV or logistics orders
• Artwork, technical or safety reviews with correction cycles
• Frequent status chasing close to move-in

Map the workflow before selecting screens or features

Start with an action matrix. For every exhibitor action, record who must complete it, whether it is compulsory, what information or file is required, who reviews it, the deadline, the late rule and the status that counts as complete. This becomes the configuration brief and prevents the portal from reproducing an unclear email process.

Separate event-wide requirements from package-specific actions. A shell-scheme exhibitor, raw-space exhibitor, sponsor and pavilion coordinator may need different forms, services and approvals. The portal should reveal only the relevant path while preserving an organiser-wide reporting view.

• Action owner and eligible exhibitor type
• Required input, file format and validation rule
• Reviewer, approval state and correction path
• Opening date, deadline, late handling and escalation owner
• Dependency on another form, order, payment or approval

Define accounts, permissions and a reliable data model

Decide who represents each exhibiting company and whether that person can invite colleagues or appointed contractors. Roles should match the work: a finance user may handle invoices, a designer may upload artwork and a pavilion lead may need visibility across several stands without seeing unrelated exhibitors.

Agree the source of truth for company names, booth numbers, packages, contacts and entitlements before import. Define how duplicates, staff changes and transferred stands will be handled. Permissions, audit history and exports should be tested with realistic roles rather than one administrator account.

Structure service orders and payments around fulfilment

A service catalogue should show what is included, what costs extra, the unit, specification, deadline and what information is needed for fulfilment. Conditional choices matter: an electrical order may require equipment load and location, while an internet order may need the device plan or technical contact.

Map the full commercial path before launch, including quotation or fixed-price rules, taxes where applicable, payment status, refunds, cancellations, late surcharges, invoice ownership and order changes. The portal should not mark an item ready merely because a button was clicked; completion must reflect the agreed payment and fulfilment rules.

Build an artwork and technical approval workflow

Artwork collection needs a defined brief, template, dimensions, colour expectations, accepted file types and final production deadline. Record each submission separately so reviewers can distinguish received, under review, correction required, approved and released to production.

Technical submissions may require drawings, equipment information or contractor documents rather than one artwork upload. Keep reviewer comments, version history and approval authority visible. Approval should release the exact accepted file or package, not whichever attachment happens to be newest in an email thread.

• Downloadable templates and named-file guidance
• Automated checks for required fields, size and file type
• Named reviewer and target response time
• Correction reason, resubmission state and version history
• Explicit final approval and production-release owner

Design communications and support as one service

Every reminder should identify the action, deadline, current status and direct route to completion. Segment messages by exhibitor type and status so completed users are not repeatedly chased. Publish urgent changes in one authoritative place and record which users received them.

Give exhibitors a support route for access issues, order questions and approval queries. Define service hours, response targets, escalation owners and how support outcomes update the portal record. A dashboard is unreliable if important answers and exceptions remain only in private inboxes.

Measure readiness by exceptions, not logins

A login or submitted form does not prove that an exhibitor is ready. Define readiness as the completion of the event-specific actions that protect delivery: required documents accepted, critical services confirmed, artwork approved, payment cleared where required and unresolved exceptions assigned.

Organiser reporting should move from totals to action. Show overdue items by owner, high-risk exhibitors, orders awaiting fulfilment, approvals waiting on the organiser and deadlines approaching. Keep a clear difference between not started, in progress, submitted, rejected, approved and waived.

• Completion rate by compulsory action and exhibitor cohort
• Items due in the next operating window
• Submissions waiting for organiser or supplier review
• Rejected items without a replacement submission
• Critical exceptions with owner and next action

Plan accessibility, privacy and security from the start

Exhibitors should be able to navigate the portal by keyboard, understand labels and errors, distinguish status without colour alone and complete time-sensitive actions without avoidable barriers. Use W3C accessibility guidance as a design and testing baseline, then confirm any contractual or jurisdiction-specific requirements with the organiser's advisers.

Collect only information needed for the stated workflow, explain why it is required, restrict access by role and agree retention, export and deletion procedures. The organiser should identify the data owner and obtain appropriate privacy and security advice. This operational guide is not legal advice and does not replace a review of the Personal Data (Privacy) Ordinance or other applicable requirements.

Test, launch and close the event deliberately

Before release, test each exhibitor type from invitation to completion, including incorrect files, failed payments, changed contacts, missed deadlines and administrator overrides. Pilot with a small internal group or selected exhibitors, then reconcile every dashboard status against the underlying action.

After the event, close ordering and submission states, reconcile fulfilment and payments, export the agreed operational record and apply the retention plan. Review support questions, late actions and manual workarounds while the evidence is fresh; those findings should shape the next event configuration.

• Role and permission test for every user type
• Mobile, keyboard, error-state and notification test
• Order, payment, approval and reporting reconciliation
• Launch owner, fallback process and incident contact
• Post-event archive, retention and improvement review