What should an event software support agreement promise?

Your ticket page stops accepting orders while a paid campaign is running. You report the problem, receive a case number, and wait. The supplier has met its promise to acknowledge your message, but you still don't know whether to pause the campaign or tell buyers to try again later.

That's the gap an event software support agreement should address. It should explain who takes responsibility, when someone capable will respond, how work continues, and what happens if the service cannot recover before your next event deadline. A fast reply matters. So does knowing what that reply actually commits the supplier to do.

Start with your fixed deadlines. An on-sale launch, doors opening, a scheduled attendee update, and a finance deadline need different kinds of help. Then agree coverage, incident definitions, escalation, recovery arrangements, and charges around those moments. Don't choose a response time because it looks reassuring in a proposal.

This event software SLA checklist walks through those decisions. SLA means service level agreement, the agreed description of service standards and how performance is measured. You might receive it as a separate document or inside your wider contract. Either way, your event team needs an arrangement it can use while tickets are selling and attendees are waiting.

Start with the deadlines support needs to protect

Before discussing minutes and hours, describe your event programme. When do tickets go on sale? When can the last attendee arrive? Who needs help outside the normal working week? Include the timezone, dates, and parts of the service your team depends on during each period.

Imagine a fictional operator running a paid evening event. Online sales continue until doors open, and walk-up sales continue afterward. The operator needs support through the admission period, including the preparation immediately before it. A weekday support package could leave the most exposed part of that event without the promised response, even if the supplier performs perfectly against its published working hours.

Your programme may need a different arrangement. A daytime conference could depend on help with a morning admission rush. A touring business may need coverage across several timezones. An event with reserved seating may need urgent assistance when the availability shown to buyers appears wrong. Explain the task that must continue and what stops if it doesn't.

Use your event contingency plan to identify the situations where supplier assistance changes the decision. You still own the wider event response, including venue coordination and attendee welfare. The support agreement should make the supplier's part specific enough that your team can plan everything around it.

Ask the supplier to confirm which named events and service periods the offer covers. If event coverage requires advance booking, record the notice required and how the booking is accepted. A date in your calendar doesn't reserve a support team. You need confirmation from the people providing the service.

Separate a reply from a working service

A support promise can describe several different moments. Acknowledgement means the request arrived. An initial human response means someone has reviewed it and contacted you. Investigation means work has started. Restoration means the affected operation works again, perhaps through an agreed temporary method. A permanent fix addresses the underlying fault.

Those distinctions matter when you decide what to do during an interruption. An automated acknowledgement cannot help you determine whether buyers should retry a payment. A human response may collect details without offering a workaround. A temporary workaround may reopen sales while leaving reporting incomplete. Ask the supplier to define each milestone it promises and what evidence establishes that milestone.

Don't read a response target as a restoration commitment. If the agreement promises only an initial response, ask what it says about continued investigation, progress updates, and the decisions available when recovery remains uncertain. A supplier may be unable to promise when every unknown fault will be fixed. It can still explain who owns the incident and how it keeps you informed.

Be equally careful with the word resolution. Does it mean your original task works again, a workaround exists, or the supplier has closed the case? Suppose a refund can be processed manually, but your finance lead cannot reconcile it afterward. That may be an acceptable temporary arrangement. It isn't automatically the outcome your business needed.

Agree who confirms restoration for your account. Your staff should test the affected task using an appropriate record before returning to normal operation. The supplier may confirm that its systems are healthy while your configured checkout still has a problem. Keep that distinction visible in the incident record rather than arguing about it after the case closes.

Check what happens when a case closes too early. Your event lead should know how to reopen it, preserve the original history, and explain that the agreed test still fails. Ask whether reopening changes the incident reference or measured times. Otherwise, a problem that briefly disappears could become several unrelated cases, making it harder to understand the interruption and judge whether the supplier delivered the service you agreed to.

Write down when each support clock runs

Every promised time needs a beginning, an ending, and a calendar. Ask whether the response clock starts when you submit a request through the approved channel, when the supplier assigns a priority, or when it decides the request contains enough information. These are different commitments, especially when staff are busy at the venue.

Ask what pauses the clock. The supplier may need access, approval, or an answer from your team. A pause should identify the missing information, who must provide it, and when the supplier requested it. Otherwise, an unanswered question in a long message could stop the measured response while you believe investigation continues.

Coverage hours need the same care. Write the timezone and explain how public holidays and seasonal clock changes affect the service. If the agreement uses business hours, request an example spanning the end of a working day. Have the supplier show when the next response would be due under the proposed wording.

Then test a case received just before coverage ends. Does work continue on an urgent incident already accepted, or stop when the support shift finishes? Does a response promised within a covered period mean someone remains available afterward? A brief answer before closing time is little help if the next useful action comes after your event.

Decide whether your team can remain reachable too. If the supplier needs your authorisation to change a configuration, someone with that authority must answer. Name a backup and an approved way to transfer responsibility. Support delays caused by unavailable organisers are still delays your attendees experience, even when the supplier meets its side of the agreement.

Consider a supplier offering a response within one working hour. In a fictional example, your event begins on Saturday evening while ordinary coverage ends on Friday afternoon. The phrase says nothing about Saturday unless the support calendar includes it. If you buy separate weekend coverage, check whether the same response promise applies throughout that booking and whether engineering help is available when the initial support person needs it.

Ask for the answer against your actual dates before accepting the offer. A general description of round-the-clock monitoring might mean automated systems watch the platform while customer requests still wait for the next shift. Monitoring, customer contact, and access to someone who can change the service are separate questions. Have the supplier explain which people and actions your proposed package includes.

Define severity using the effect on your event

Severity is the priority assigned to a problem. Agree the meaning before you need it. Labels such as critical and urgent tell you little without examples of the affected task, available alternatives, and time remaining before the event suffers a material interruption.

Your highest priority might cover a live, widespread inability to purchase tickets or admit valid ticket holders, with no workable alternative. A lower priority could cover a reporting fault while sales and admission continue. These are suggested distinctions for discussion, not an industry standard or a claim about any supplier's categories.

Don't decide priority only by the number of users affected. A problem blocking your authorised finance user could prevent a time-sensitive refund run even though most staff can sign in. Equally, one attendee struggling to find a confirmation doesn't necessarily mean the platform has failed. Ask how the supplier weighs business impact, timing, scope, and available workarounds.

Include partial failures. Some buyers may complete checkout while others cannot use the payment method your campaign promotes. One device may fail at admission while another works. You need a way to report the observed impact without first proving which technical component caused it. Diagnosis should follow the report, not become a condition for receiving useful help.

Agree who can change severity and how disagreements escalate. Your team should be able to explain that a previously manageable fault has become urgent as doors approach. The supplier should explain a downgrade and the practical alternative it believes is available. Keep the reasoning in the case record so everyone understands which commitment now applies.

Make escalation possible while you are busy

Escalation means involving someone with more expertise or authority when the current response is insufficient. Ask for the route your duty manager actually uses, including what triggers it, who receives it, and what happens when the usual contact is unavailable.

A named account manager can help, but their personal availability shouldn't be the whole emergency arrangement. Ask for a role, team, or monitored channel that remains usable during the coverage you've bought. Staff change roles and take leave. Your event cannot depend on remembering who answered a message last season.

Set expectations for updates during an open incident. Useful updates explain what is affected, what the supplier knows, the action underway, what your team should do, and when to expect the next update. If the supplier cannot estimate recovery, it should say so. An invented completion time can lead you to postpone a necessary fallback.

Decide who communicates with attendees. The supplier might publish a general status notice while your team explains your particular event arrangements. Those messages need compatible facts. Ask how your lead receives verified information, including when the supplier discovers that an earlier explanation was wrong. Don't promise buyers a restoration time your supplier hasn't confirmed.

Keep one incident reference for the affected operation, with related reports attached where possible. Several staff opening separate cases can split the history and produce conflicting instructions. Tell temporary staff how to report observations to your event lead, who then maintains the agreed contact with support. They can keep working while someone else coordinates the investigation.

Clarify the services and dependencies covered

The agreement needs to name the service you've bought. Checkout, ticket delivery, admission, attendee communications, exports, and third-party connections can have different support boundaries. A promise covering the main platform doesn't automatically cover everything connected to it.

Ask who investigates when the cause is unknown. Your ticket supplier may control its software while your venue controls connectivity and another company processes payments. You don't need one supplier to promise control over everyone else. You do need an agreed first contact and a practical way to establish which party must act.

For each important connection, record the responsibility for monitoring failures, gathering evidence, contacting the other provider, and confirming recovery. If the supplier passes the case elsewhere, ask what assistance it continues to provide. Being told that a fault belongs to another company doesn't tell your team how to reopen sales.

The NCSC's operational security guidance for cloud services recommends predefined incident processes, a reporting route, and agreed notification arrangements for security incidents affecting customer data. Use those principles to ask how the proposed service operates. They don't establish a universal event support response time.

Include your own responsibilities in the same discussion. Supported devices, current software versions, account permissions, venue internet, and correctly configured connections can all affect investigation. Ask the supplier to identify prerequisites before the event. A prerequisite discovered during an outage may be impossible to meet at the venue, even when it sounds reasonable in isolation.

Prepare a useful incident report in advance. Your duty lead should know how to identify the affected event, describe the action that failed, state when it last worked, and record whether another supported device or connection behaves differently. Include the next relevant event deadline and the fallback already attempted. That saves time without asking your admission team to diagnose the software.

Also agree how to share evidence safely. A screenshot may contain attendee information, and an exported record may include details unrelated to the fault. Ask which secure channel the supplier accepts and what information it actually needs. Never put passwords or full payment card details into a support message. Staff should be able to report urgency without circulating your customer database through personal messaging accounts.

Read uptime promises against the task buyers perform

Availability describes whether a service is usable under a stated measurement. The percentage alone cannot tell you whether your ticket operation is protected. Ask which functions the supplier measures, where it measures them, and whether a failure affecting your account counts toward the promise.

A public event page might load while checkout fails. Staff might sign in while ticket records cannot update. Ask how the definition handles those situations, along with degraded performance that makes a time-sensitive task impractical. You want to understand the actual boundary of the commitment before comparing percentages across offers.

Also read the measurement period and exclusions. A monthly availability measure summarises performance across the month. Your busiest on-sale period occupies only part of that time. A supplier could miss the moment that matters most to your event while still meeting a wider measurement. Discuss that exposure directly rather than assuming a headline percentage removes it.

Maintenance deserves its own agreement. Ask how much notice you receive, which services may stop, whether your critical dates can be considered, and how emergency changes are communicated. You may not be able to veto necessary security work. You can still agree how the supplier informs your team and helps you adjust event operations.

Ask where your evidence comes from when the service fails. A public status page may describe a broad incident without confirming your exact experience. Save the case reference, observed error, affected task, and timestamps. Agree a way to challenge a measurement when your records show a failure the supplier's general monitoring didn't capture.

Connect recovery to the records your team needs

A service can return before all its records have caught up. Ask what happens to orders, scans, refunds, and queued communications during recovery. Your team needs to understand which actions completed, which failed, and which require checking before anyone repeats them.

Two terms may appear in the supplier's recovery documents. Recovery time objective describes how long a service can remain unavailable before the impact becomes unacceptable. Recovery point objective concerns the point in the past to which data can be restored. Ask the supplier to explain both against your transaction records, including their scope and whether they are contractual commitments or planning objectives.

NIST's contingency planning guide provides a framework for assessing recovery priorities and planning how information systems return after disruption. It was written for federal information systems, not event ticketing. Its useful lesson here is to determine what your operation needs to recover before accepting a general backup assurance.

Suppose an admission device reconnects after staff used an approved fallback. Who checks whether those admissions reached the central record? How do staff identify duplicates? What happens to a valid attendee whose ticket appears unused elsewhere? Ask the supplier to demonstrate the supported reconciliation process for your arrangement. Don't invent an offline process based on assumptions about the product.

Put the organiser's remaining work into your plan. Someone may need to review exceptions or contact affected buyers after the event. Ask which records support that review, how long they remain accessible, and whether assistance costs extra. Recovery is incomplete for your business if the team cannot explain what happened to money or admission records.

Keep security notification separate from ordinary support

A suspected data exposure needs a route beyond the normal queue for configuration questions. Ask how staff report it, who receives it, and how the supplier contacts your responsible person if it discovers the problem first. Include a backup contact who can act when your usual lead is working at the event.

The contractual arrangements depend on the service, the parties' roles, and applicable law. Under the UK GDPR, the ICO's guidance on processor responsibilities says a processor must notify the relevant controller of a personal data breach without undue delay. That is a specific legal context, not a support deadline you can apply to every supplier everywhere.

Have the person responsible for privacy check the proposed notification terms alongside your data processing agreement. The ICO flags that its guidance is under review following changes in UK legislation. Confirm the requirements that apply to your arrangement rather than relying on a copied contract from an earlier purchase.

Operationally, agree what the first notice should contain and how later information follows. Your team needs an incident contact, the known affected services or information, immediate precautions, and the next communication. Waiting for a complete investigation could prevent you from taking useful early action. Avoid requiring certainty the supplier cannot yet have before it reports a relevant concern.

Understand charges and remedies before an incident

Find out what ordinary support includes and what the supplier sells separately. Training, configuration changes, migration help, reserved event coverage, replacement equipment, and work involving another system may have different charges. Ask for the price and approval process for the services your programme is likely to need.

Emergency spending needs an owner. Your duty manager may need permission to buy additional assistance while the budget holder is unavailable. Agree an internal spending limit appropriate to your business and ask how the supplier obtains authorisation. A conversation about technical urgency shouldn't silently become approval for an open-ended bill.

Put those commitments into your event budget. Compare the cost of planned coverage with the exposure it addresses and the fallback your own staff can operate. Paying for the fastest available package everywhere may waste money. Choosing office-hours support for an event that runs outside those hours may leave an expensive gap.

Then read the remedy for a missed commitment. A service credit usually concerns charges under the contract, with conditions set by that agreement. Ask what triggers it, how it is calculated, whether you must claim it, what evidence is required, and when the claim expires. Check whether it applies to future fees or another form of compensation.

The UK government's Model Services Contract schedules are an example of formal procurement documents that set out performance and service credit arrangements. They concern a different purchasing context and aren't a ready-made contract for your event business. The relevant point is to read performance promises together with their measurement and remedy provisions.

Have your contract reviewer check how credits interact with liability limits, repeated failure, termination rights, and other remedies. A credit may be much smaller than the consequences of an interrupted sale. Don't assume it reimburses lost revenue, and don't treat a supplier's willingness to offer credits as evidence that disruption cannot occur.

Repeated failures deserve a commercial discussion even when individual cases qualify for only a small credit. Ask what review follows a recurring fault, how corrective work is tracked, and what your options are if the service keeps missing an essential requirement. Your legal reviewer can assess the available contractual rights. Your operational lead should assess whether the next event can proceed under the current arrangement.

Keep a copy of the accepted support terms and identify their version date. If the supplier can change a linked policy, ask how it gives notice and what those changes mean for events already contracted. Renewal is a good point to revisit the arrangement, particularly when your programme adds later opening hours, another venue, or a different admission process. Your original support purchase may no longer fit the business you're running.

Use a checklist your supplier can answer

Once you've discussed the operating details, ask the supplier to return a written response against this event software SLA checklist. Keep unresolved answers visible. An assumption made by your team isn't a promise made by the supplier.

• Identify the contracted plan, services, event dates, support hours, timezone, holiday treatment, and any coverage that requires separate booking or payment.

• Define acknowledgement, human response, investigation, restoration, permanent correction, and case closure, including which milestones have agreed targets.

• Explain each clock's start, permitted pauses, end, measurement method, and treatment of incidents still open when ordinary coverage finishes.

• Describe severity categories through affected tasks, business impact, event timing, available workarounds, and the process for challenging or changing priority.

• Confirm approved reporting channels, authorised organiser contacts, escalation routes, incident ownership, update arrangements, and how staff obtain help if the usual channel fails.

• Identify supplier responsibilities, customer prerequisites, third-party dependencies, maintenance arrangements, recovery procedures, and checks for missing or duplicated records.

• State security reporting contacts, applicable notification arrangements, assistance obligations, extra charges, service credit conditions, and the documents that govern any disagreement.

Ask the supplier to identify where each accepted answer appears in the contract documents. A completed questionnaire helps your review, but it may not override standard terms. Resolve conflicts between the proposal, order form, support schedule, and linked online policies before you rely on them.

Rehearse the agreement before the first live event

Bring your event lead and the supplier's relevant contact into a discussion using a plausible interruption. You don't need to disrupt a live system. Describe the failure, use fictional records, and ask everyone to explain the next action under the proposed agreement.

CISA's tabletop exercise fact sheet describes customisable exercises using objectives, scenarios, and discussion questions to assess preparedness. Your event discussion can use that approach without treating it as certification or proof that the software will recover within a particular time.

Start with a buyer reporting failed checkout shortly before an advertised ticket release. Ask who reports it, how the supplier assigns severity, and what information the organiser needs before pausing promotion. Continue until the group reaches either verified restoration or an agreed fallback. Notice where someone needs approval, a contact, or information nobody has prepared.

Then change one condition. The usual organiser contact is unavailable, the support portal cannot be reached, or the fault appears to involve the payment provider. Ask what happens next under the agreement you've actually been offered. If the answer depends on a favour from someone outside the arrangement, put that dependency into the clarification list.

Finally, test how you return to normal. Who confirms sales work, checks affected orders, and tells the team to stop the fallback? Who reviews the incident afterward and agrees any corrective action? A useful review records the timeline, remaining consequences, responsible people, and completion dates. It should improve the next event's preparation without turning into a search for someone to blame.

Record the rehearsal's unresolved questions in the purchase discussion rather than leaving them in meeting notes. Perhaps staff can reach support, but nobody knows who approves a temporary configuration change. Perhaps the fallback requires a report that only an absent administrator can export. Assign the action to someone who can correct it, then repeat the relevant part before your first live use. A short second discussion is more useful than assuming the revised document has fixed the operating problem.

Approve an arrangement your event team can use

Review support alongside the tasks you need the event software to perform. Buying more capabilities adds little if the people responsible for your event cannot get appropriate help when one of those tasks fails. Equally, a detailed support schedule cannot compensate for a product your team hasn't tested for its intended use.

Before you sign, send the agreed contacts and operating instructions to the people who will be on duty. Ask them to find the reporting route, identify the right severity, and explain when they would escalate. Correct anything they interpret differently from the supplier. Keep the final version accessible during the event, including when your usual system is unavailable.

Approve the purchase when you can describe the response to your most consequential interruption without guessing. Your team knows who acts, what the supplier promises, which deadlines remain exposed, and when it must use the fallback. Any unresolved gap should have an owner and an accepted plan before the first buyer depends on the service.