Arts & entertainment.

Conflicting event details across channels

The problem

An event may have the correct details on the organiser's website and a different time on a partner listing, a social post or a downloadable programme. The programme workspace controls the underlying record, but channel distribution is a separate problem: someone must know where the information was sent and which destinations accepted the latest version. Otherwise a small correction creates a long chain of manual checks.

What we can build

We can build a distribution register for the event's public channels. Each destination can show the approved information version, update method, owner and last verified state. Supported integrations may publish the revised details automatically, while channels without an authorised connection generate a clear staff task. This gives the team a practical account of what is current instead of assuming that saving the website also updates every partner.

Cancellation and postponement communication

The problem

A cancellation creates several different questions at once: whether the whole series is affected, what happens to existing tickets and where attendees can ask for help. An ordinary date edit can leave the old event page, confirmation messages and venue instructions looking valid. Staff also need to know which audience records belong to the affected performance before contacting people.

What we can build

We can design a controlled event-change workflow with separate cancellation, postponement and rescheduling states. An authorised manager can approve the change, select the affected performances and prepare the public notice. Communications can identify the event, explain the current next step and link to the provider's approved purchase-support route. A change history allows staff to answer questions about the information an attendee previously received.

Rehearsal version changes

The problem

A rehearsal update may change the running order, a cue reference or a performer's call time. Different teams can use different versions because they downloaded the schedule earlier or received a partial correction in a message. Reissuing the entire document does not necessarily make the changed items obvious, and staff can spend rehearsal time comparing files rather than understanding the agreed sequence.

What we can build

We can create a rehearsal planning workspace that records schedule versions and makes approved changes visible. A current running order can link to the relevant scene, performer group or production note. Changes can identify who approved them and which roles need to acknowledge the update. The interface should support preparation and coordination while leaving live show-control systems and technical cue execution in their appropriate environment.

Refund request status

The problem

A customer can send a refund request and then contact several teams because they cannot tell whether it was received. Staff may use the word refunded when they mean approved, even though the payment provider has not confirmed the transaction. That ambiguity creates avoidable frustration and makes it difficult to identify a request that is waiting for a decision versus one that is waiting for processing.

What we can build

We can create a refund enquiry tracker that records the purchase reference, event, request reason and responsible team. Received, under review, approved, submitted to provider, confirmed and declined can be distinct states where they fit the provider's process. A customer view can explain the current stage and the next contact route without displaying internal dispute notes or promising a bank settlement date the organiser cannot control.

Waitlist and capacity management

The problem

A sold-out event may keep a waiting list in a form that is disconnected from actual ticket availability. When places become available, staff contact several people at once and create uncertainty about who has an offer. Group sizes, response deadlines and accessible seating requirements can complicate a seemingly simple queue. A registration acknowledgement is not enough to establish that a person has a reserved place.

What we can build

We can build a waitlist process that distinguishes joining the queue, receiving an offer, holding an allocation and confirming through the ticket provider. The business can define a transparent allocation rule and expiry period. A staff view can identify offers awaiting response and places released after a deadline. The public page should explain what joining means and avoid suggesting that a ticket is guaranteed.

Accessible audience information

The problem

A visitor planning an accessible visit may find a general statement about inclusivity but no practical information about entrances, seating arrangements or how to discuss individual requirements. Information can also be presented only inside a poster image or an inaccessible form. The visitor has to contact the organiser before deciding whether the event is suitable, while staff repeatedly answer questions that should have an approved public explanation.

What we can build

We can create an accessible information structure with venue-specific details, clearly dated updates and a respectful enquiry route. Your organisation supplies verified information about the facilities and arrangements it can offer. The website can make that material readable, searchable and usable with assistive technology. A request for an arrangement can enter a controlled staff process rather than being treated as automatically accepted by a form confirmation.

Entry scanning when connectivity fails

The problem

An entry queue can stop when the device cannot reach the ticketing service. Staff may have to choose between delaying attendees and admitting people without a reliable record. Multiple scanners introduce another uncertainty: an offline device may not know that a ticket has already been used at a different entrance. A smooth-looking scanning screen is insufficient if its confirmation does not reflect the system's actual knowledge.

What we can build

We can help design an entry workflow around the authorised ticketing provider's supported connectivity behaviour. Where offline validation is permitted, the interface can clearly show the age of its downloaded data and whether a scan is locally accepted or centrally confirmed. A supervisor view can identify unresolved synchronisation conflicts after connectivity returns. Where offline use is unsupported, the workflow needs an explicit fallback approved by the organiser.

Guest-list approvals

The problem

Guest allocations can come from artists, sponsors, staff and promoters through separate lists. The combined total may exceed the reserved allocation, and last-minute changes can leave entrance staff with conflicting versions. A name added by someone with access to a shared spreadsheet may be treated as approved even when that person is not authorised to allocate a place.

What we can build

We can build a guest-request process with allocation limits, approval roles and performance-specific confirmations. Requested, approved, declined, withdrawn and admitted can remain separate states. The current entry list can show only the information front-of-house staff need. Teams can see their remaining allocation without opening other partners' private guest records, and changes can preserve an audit trail.

Streaming access support

The problem

An online attendee can have a valid purchase and still struggle to reach the performance. The access link may be buried in an email, the viewing page may require a different account or the visitor may confuse the scheduled start with the replay window. During a live show, support staff need to identify whether the problem concerns entitlement, login, device compatibility or the stream itself.

What we can build

We can create an online-event information and support journey that clearly separates purchase confirmation, viewing access and technical help. The event page can provide approved joining instructions, supported device guidance and the correct provider route. A support form can preserve the event reference and useful technical context without asking for passwords. Provider-controlled entitlement remains authoritative rather than being inferred from a visitor's claim.

Research context: Eventbrite online event access guidance. provider documentation.

Venue handover checklists

The problem

A venue can change hands between a house team, touring production and outside supplier without a shared record of its condition or outstanding work. One team assumes equipment is ready, another believes a previous issue is still assigned to someone else. At the end of the event, questions about damage, missing items or incomplete cleanup can become difficult to resolve because the starting condition was never recorded clearly.

What we can build

We can create a handover workflow with venue-area checklists, condition evidence, exceptions and named acceptance. The checklist can distinguish information-only observations from tasks that must be resolved before the space is released. Incoming and outgoing teams can review the same record while permissions limit unrelated operational details. A handover remains a human agreement supported by records, not an automatic declaration that the site is safe or compliant.

Lost-property enquiries

The problem

After an event, audience members may contact the venue, promoter and ticketing team about a missing item. Staff can receive several descriptions of the same loss without a common reference, while found items are recorded elsewhere. Sharing photographs publicly can create another problem: the person claiming an item may simply repeat details visible in the post rather than demonstrate ownership.

What we can build

We can build a controlled lost-property register with separate found-item records and audience enquiries. Staff can link a possible match while keeping identifying details private. A status view can explain whether an enquiry was received, whether staff found a possible match and what collection arrangements have been approved. The organisation defines its retention, ownership checks and handling procedures; the software helps staff apply them consistently.

Content release embargoes

The problem

An announcement, trailer or programme detail may be approved internally but not yet permitted for public release. If approval and release time are represented by the same status, a publisher can expose material early. Timezones, scheduled social posts and access through direct asset links add uncertainty even when the public page itself is hidden.

What we can build

We can design a release workflow that separates content approval, embargo restrictions and publication readiness. An asset or announcement can carry a release timestamp with its timezone, authorised destinations and responsible publisher. Private previews need access controls rather than merely obscure URLs. A publication queue can show items that are approved but not yet releasable, preventing staff from interpreting one approval badge as permission to publish anywhere.

Artist approval of promotional material

The problem

The media library may confirm that an image is available, yet a specific poster or campaign edit can still require artist approval. Feedback can arrive as screenshots and messages that refer to different versions. A publisher may fix one requested change and overlook another, or assume that approval of the portrait image also approves the accompanying headline and programme description.

What we can build

We can create a review workflow for the assembled promotional item, separate from the asset's underlying permission record. Each preview can carry a version identifier, reviewer, requested changes and decision. Comments can refer to the relevant text or visual area. Approved output is linked to the exact reviewed version, while a later edit returns to the appropriate review state rather than inheriting approval automatically.

Post-event archive and retention

The problem

Once an event ends, its public page, production files and audience records often remain scattered and unmanaged. Removing everything can break useful links and erase operational history, while keeping everything indefinitely can expose private material and outdated booking actions. Teams need to decide what remains public, what supports future planning and what should be deleted through their approved process.

What we can build

We can design a post-event archive workflow with different rules for public programme information, internal production records and personal data. A past-event page can preserve an accurate description and approved media while clearly ending normal ticket actions. Internal records can be organised by event and retention category, with review tasks assigned to the responsible owner. The archive should make its status understandable rather than silently presenting old information as current.

Performer technical rider collection

The problem

A production team can receive a rider, stage plot and input list as separate attachments with similar names. The material may arrive after crew and equipment plans have been drafted. If the artist sends a revision to one contact, other staff can continue preparing from an older version. The problem is not simply storing documents; it is identifying which requirements are current and whether the venue has accepted them.

What we can build

We can build a performer advance workspace that collects the required document types, records revision dates and assigns a technical reviewer. Submission, reviewed, questions outstanding and accepted can be separate states. Structured questions can capture the most important planning information while preserving the original files. Staff can see which acts are missing material and which requirements need a discussion rather than treating every uploaded file as approved.

Volunteer check-in and induction

The problem

An event can have enough volunteer names registered but still lack prepared people at the required posts. A registration form may not confirm availability, induction completion or the correct arrival location. On the day, a supervisor may not know who has arrived, who is absent or whether a replacement understands the role. These gaps create extra work for staff at exactly the time audience activity is increasing.

What we can build

We can build a volunteer coordination journey with role descriptions, availability confirmation, induction records and day-of check-in. A volunteer can see their approved assignment and the contact for questions. Supervisors can review uncovered posts and people who have not checked in. The system can support an agreed induction process without turning an online checkbox into proof that a person is competent for a safety-critical task.

Press accreditation requests

The problem

Press requests can arrive through personal contacts with incomplete information about the publication, assignment or access requested. A photographer may be approved for one performance but appear on a general list used across the whole event. Staff at the entrance need an accurate permission record, while the communications team needs to distinguish a pending application from an issued accreditation.

What we can build

We can create an accreditation application and review workspace with the event, requested access, supporting details and decision owner. Approved access can be limited to specific dates or zones. A staff-facing verification view can show the relevant permission without revealing unnecessary applicant information. The system can prepare confirmation documents from an approved decision rather than treating a submitted form as authorisation to enter.

Tour travel and accommodation records

The problem

Tour arrangements can be distributed across booking confirmations, personal calendars and messages. A crew member may know the hotel but not the check-in instructions, while the transport lead has an earlier pickup time. Changes can affect several people and suppliers, yet each contact receives only part of the updated itinerary. A public-facing event calendar cannot safely double as the team's private travel plan.

What we can build

We can create a controlled tour itinerary with travel segments, accommodation references, arrival instructions and named coordination owners. Each person sees the arrangements relevant to their role. Proposed, confirmed, changed and cancelled bookings remain separate. The workspace can link to authorised supplier records without exposing payment details or personal identity documents to every participant.

Merchandise stock at venues

The problem

A tour can sell merchandise at several venues while staff record stock movements in separate sheets. The online shop may continue showing an item that was sent to the next show. Cash sales, returned goods and damaged items can make the apparent stock count diverge further. The sales team needs to distinguish physical stock, reserved stock and stock that is actually ready to sell.

What we can build

We can build a merchandise operations view connected to the authorised commerce and inventory systems. Products can have variants, venue allocations and transfer records. A staff view can show quantities dispatched, received, sold and returned, with discrepancies assigned for review. The aim is to make stock movements understandable, rather than creating a second unofficial count that competes with the existing point-of-sale system.

Audience consent and mailing preferences

The problem

An attendee may need a performance update but not want future promotional messages. If a business treats every ticket purchase as a general mailing-list subscription, staff cannot reliably distinguish operational communication from marketing preferences. Audience records can also appear in several providers, so changing a preference in one place may leave another list unchanged.

What we can build

We can design a preference workflow that records the purpose, source and current state of each communication choice. Event-related messages and promotional subscriptions can follow separate rules agreed by the organisation. A customer-facing page can make preferences understandable, while staff can review synchronisation exceptions. The business must establish its applicable requirements; the software should implement documented rules rather than assert compliance from the presence of a checkbox.