It is thirty minutes before registration opens. Staff stand at the desk with lanyards in hand, and the attendee lookup screen will not load. The organizer expects an immediate fix: the contract promised 99.9% uptime. The vendor may restore it quickly. The agreement may also promise less than the organizer expects.
An event software SLA may sound reassuring, but organizers need to use it as a working document. One fictional outage runs through this article. It shows which clause controls what the event team may expect before anything fails.
An event software SLA should name the services it covers and explain how it measures uptime. It should also define exclusions, incident levels, response times, recovery promises and remedies for missed targets. Organizers should compare those terms with their busiest workflows and actual operating hours. An uptime percentage by itself does not show how the SLA applies on conference day.
An SLA is not the same as a support page
Vendors describe service in several documents. An SLA sets measurable promises and remedies. A support policy explains channels, hours and how the vendor handles cases. A status page reports current or past incidents. A security or continuity document describes controls and resilience. A sales proposal describes the offer, but only terms included in the signed agreement or its schedules may be binding.
Before reading a single percentage, answer five questions:
- Which document controls if two documents conflict?
- Which version and effective date apply?
- Does the promise apply to your plan, module or support tier?
- Can the vendor change the terms, and how much notice must it give?
- Does the wording promise a result, set a target or describe a best effort?
Current vendor documents show why this check matters. Eventtia’s service-level agreement separates service scope, priorities, support handling and exclusions. Ring Central Events’ SLA defines availability for live-event service, exclusions and remedies in its own way. These examples do not establish one standard. They show why procurement and legal teams need to read the documents that apply to the purchase.
Start with what the event software SLA calls the service
Our outage began with registration lookup. Is lookup covered? The answer depends on the service name in the SLA, not on how the sales demo described the platform.
List the workflows whose failure could disrupt the conference. Connect each one to the exact module, plan or service named in the contract. Then record any dependency or exclusion beside it. The agreement may not cover beta features, custom changes, APIs, third-party integrations, payment gateways, attendee devices or the venue network.
Use this coverage record before signing:
| Key workflow | Named service or module | Covered? | Dependency or exclusion to check | Clause or schedule |
|---|---|---|---|---|
| Attendee and badge lookup | Registration administration | Yes, no or unclear | Venue internet, printer or unsupported device | Record the exact reference |
| Paid registration | Checkout and payment connection | Yes, no or unclear | Payment gateway or third-party service | Record the exact reference |
| Abstract submission | Submission portal | Yes, no or unclear | File storage, deadline time zone or planned maintenance | Record the exact reference |
| Event website or attendee login | Website, mobile or virtual-event module | Yes, no or unclear | Attendee device, browser or external streaming service | Record the exact reference |
An unclear row deserves a written answer. A vendor may confirm coverage in an email or proposal. Ask the contract owner whether that statement must also appear in the agreement, order form or service schedule.
Recalculate the uptime promise before accepting it
A percentage is a conclusion. The calculation behind it sits in the definitions. Check the time period, covered service hours, data source and test interval. Then ask how long an outage must last before it counts and how much of the service it must affect.
Then examine what the calculation removes. Common exclusions include planned maintenance, customer-caused faults, unsupported configurations, third-party services, internet failures and events outside the provider’s reasonable control. An exclusion is not automatically unfair. Ask whether the contract defines it clearly, measures it consistently and assigns it to the party that can manage it.
Availability = (eligible service minutes - counted downtime) / eligible service minutes × 100
Consider an example. It is not a recommendation. A 30-day month contains 43,200 minutes. If an agreement measures every minute and promises 99.9% availability, about 43 minutes of counted downtime could still meet that percentage. Another contract may produce a different figure because it uses set service hours, removes excluded time or measures only named modules.
Those 43 minutes also carry different weight. An outage at 03:00 on a quiet Tuesday may cause little disruption. The same outage at 07:00 while 600 people queue for badges can stop arrivals. The percentage treats the minutes alike; the event does not. Read the uptime clause beside the support, incident-level and recovery clauses.
Match support coverage to the event clock
Our fictional outage happens at 07:00 on a Saturday. The SLA may use another time zone for support hours. It may also treat weekends as out of hours. Live-event or onsite support may require a separate order. Attendees may not have permission to contact the vendor directly, even when the event team has round-the-clock access.
Map the contract against the conference schedule rather than a generic business day:
- Setup and rehearsal: Confirm coverage while staff configure devices and test workflows.
- Registration opening: Confirm the channel and approved contact for a high-impact case.
- Submission or payment deadline: Check whether the vendor’s clock covers the stated deadline time zone.
- Evenings and weekends: Confirm whether response targets change outside normal hours.
- Post-event work: Check coverage while the team reconciles transactions, scans and exports.
If the event and support clocks do not match, decide what you need before signing. You may negotiate event-specific coverage, buy an additional service or plan an approved fallback. The event team still owns attendee updates and request routing, so plan participant support around high-traffic deadlines separately.
Severity must reflect business impact
The incident level decides which response clock starts. Some SLAs cover only a complete platform failure. Others also weigh the number of users, available workarounds and the effect on a live event.
Test the proposed definition with real conference cases:
- Attendees cannot complete paid registration during the final published deadline hour.
- Organizers can retrieve badge records, but each search takes 30 seconds and the queue keeps growing.
- A finance report arrives late, while registration and check-in continue normally.
Do not assign your own P1, P2 or P3 labels. Ask the vendor to classify each example under the proposed terms and explain why. The answer may show a gap between a system problem and its effect on the event. It also shows whether a workaround lowers the incident level even when staff cannot keep using it for a long queue.
Follow the incident clock from report to remedy
An acknowledgement confirms receipt. Mitigation reduces the impact. Restoration returns the workflow to use, while resolution closes the case under the SLA. These are different points in the incident. A quick reply does not mean a quick recovery.
| Incident point | What should happen | What the organizer records |
|---|---|---|
| Issue reported | An approved team member uses the contracted channel and supplies the required details. | Ticket number, report time, affected workflow and visible impact |
| Acknowledgement | The vendor confirms receipt, priority and ownership. | Acknowledgement time, severity and named incident owner |
| Mitigation | A workaround reduces the immediate impact. | Instructions, limits, approval and remaining risk |
| Restoration | The affected workflow becomes usable again. | Restoration time and a successful workflow test |
| Resolution and review | The vendor closes the issue under the SLA’s definition and supplies any promised review. | Cause or fix summary, open follow-up and data checks |
| Remedy | The customer follows the stated claim or repeated-failure process. | Eligible period, evidence, deadline and outcome |
At the registration desk, the vendor may acknowledge the case in five minutes. It may offer a manual lookup export after 20 minutes and restore live lookup after 45 minutes. Those times describe three separate promises. Ask which one the SLA measures. Also ask whether updates continue until staff confirm that the workflow works.
Read recovery and data clauses beside availability
Restoration is not the end of the incident. A login screen may load while recent registrations remain missing or payment updates still sit in a queue. The event team needs a usable workflow and complete records.
Ask which functions and data return first. Then check whether the agreement sets a target for restoring service and limits potential data loss. Trace the practical checks: Can staff retrieve a newly registered attendee? Did queued payments post once, not twice? Did badge scans and submissions keep their timestamps? Who confirms that reconciliation has finished?
Exporting key records before the event can support an approved fallback, but it does not replace the vendor’s duties under the SLA. Keep this section focused on recovery promises. Use the separate guide to review security controls and vendor evidence such as access, backup and institutional requirements.
The event team should also keep an incident record. Include the vendor ticket, timestamps, screenshots, affected workflows, workaround, restoration test and evidence owner. Do not create false load or run unapproved tests against a live platform.
Make evidence and escalation part of the promise
An SLA becomes hard to use when it names a response target but leaves the reporting and escalation route vague. The event team should know which channel starts the clock. The SLA should also name who may declare a high-impact incident, who receives an escalation and how often the vendor sends updates.
Before conference week, record:
- The approved support channel and the information required to open a case.
- The team contacts who may report and escalate an incident.
- The vendor’s first response point and the next escalation level.
- The data source used to calculate uptime.
- The update interval for each incident level.
- The process for resolving a disagreement about duration, impact or exclusions.
During the fictional registration outage, the event lead opens one case, records the growing queue and notes which searches fail. The vendor supplies the ticket time, incident level and case owner. When staff receive a workaround, they record what it can and cannot do. After restoration, both sides compare the vendor’s data with the event team’s workflow checks.
That shared timeline matters if the agreement sets a claim deadline or gives the customer rights after repeated failures. It also improves the post-incident discussion. Ask whether the provider promises a cause summary, corrective action or formal review. Do not assume every incident includes one.
A service credit is not event recovery
An SLA may offer service credits or corrective action. It may also give the customer rights after repeated failures or a way to end the contract. Read the claim deadline, required evidence, exclusions and cap. Some contracts make credits the customer’s only financial remedy for a missed uptime target. Others link repeated failures to further action. Only the governing agreement can answer that question.
A credit may reduce a future invoice. It cannot undo a delayed registration opening or return the staff hours lost to the incident. This does not make credits useless. It means the organizer should evaluate the service commitment and the financial remedy separately, with procurement and legal review.
Make the decision with one conference-day test
Return to the registration desk and trace one failed lookup through the proposed event software SLA:
- Does the agreement name the affected workflow or module?
- When does counted downtime begin?
- Which exclusion or dependency could apply?
- How would the provider classify the queue’s business impact?
- Which channel and authorized contact can report it at 07:00 local time?
- What does the contract promise for acknowledgement, updates, mitigation and restoration?
- Which workflow and data checks confirm recovery?
- Which remedy or repeated-failure process applies, and by what deadline?
The result should lead to one of three actions: accept the wording, negotiate a written change or send unresolved points to procurement and legal. Do not reject a vendor simply because its clause differs from another vendor’s wording. Compare the promise with the workflows and hours your event actually needs. If you are still building a shortlist, compare scientific conference platforms by workflow fit first.
Where Dryfta fits
Dryfta brings registration, abstract management, schedules and attendee records into one platform. Because these workflows may share data, ask exactly which services the agreement covers. Also confirm the support route, incident timing, recovery checks and terms that apply to your event.
Ask Dryfta the same written reliability and support questions you would ask any shortlisted vendor. Describe your event dates, time zone, key workflows, busiest periods, integrations and team contacts. This keeps the discussion tied to real needs. Confirm all promises in the documents that govern your service rather than relying on a sales demo.
Frequently asked questions
What does 99.9% uptime mean for an event platform?
The allowed downtime depends on the time period, covered services, service hours, data source and exclusions. A monthly percentage can allow a different amount of downtime from a quarterly or annual figure. It also does not show when an outage could occur. Work out the promise using the contract’s definitions. Then compare it with the timing and importance of your event workflows.
Is response time the same as resolution time?
No. A response or acknowledgement usually confirms receipt and ownership of a case. Mitigation reduces the immediate impact. Restoration returns the workflow to use, while resolution closes the issue under the SLA’s definition. Some SLAs count a workaround as resolution. Read each definition and target separately. A quick reply does not mean a quick recovery.
Should event-day support appear in the SLA?
The governing documents should state the coverage hours, time zone, reporting channel, approved contacts and incident levels. They should also name any event-specific service the team buys. Do not assume normal business-hours support includes weekends, overnight setup, onsite help or direct attendee support. Compare the support clock with setup, registration, live sessions and key deadlines. Resolve any gap before the event.
What should happen after an event software outage?
First confirm that the affected workflow works. Then reconcile any queued registrations, payments, scans or submissions. Keep the ticket, timestamps, impact record, workaround and restoration evidence. Request any incident summary or corrective-action review promised in the agreement. If the incident qualifies, file the remedy claim before its deadline. Update the fallback plan with what the team learned.
