How to train your event team when you change software

You've chosen the new software, the account is ready, and your team has watched the introduction. Then the first awkward booking arrives. Someone opens the old spreadsheet because they know where everything is. Someone else updates the new system. By the afternoon, you have two different answers about the same buyer.

This is the part of changing event software that needs its own plan. Your staff have to learn how their work changes, who makes each decision, and where to check the current answer. Knowing how to find a button won't help much if nobody has agreed whether they should press it.

The best approach is to train people around the jobs they'll actually do, then watch them complete realistic cases with their own access. Start with a controlled part of the operation, fix the problems it reveals, and expand only when the team can deliver the agreed result. Keep support available through the first live event and check what happens afterwards.

That's event software change management in practical terms. You're helping an existing team replace familiar habits without losing control of sales, attendee service or the records behind them. Here's how to organise it without turning a straightforward software change into months of meetings.

Decide what should work better before you book training

Start with the reason you changed software. Perhaps the ticket lead keeps rebuilding an attendee list, staff can't tell which booking change is current, or finance spends too long explaining the sales report. Write the problem in terms your team recognises. "Improve adoption" doesn't tell anyone which part of their day should get easier.

Then describe the result you want. Your customer-service team might need to find the current booking without consulting another person's spreadsheet. Your door supervisor might need to prepare staff access without sharing an administrator's login. Finance might need to trace a refund to the original order without asking the event lead to reconstruct it.

Choose an ordinary recent event as the starting point. Look at support cases, staff notes and the time spent checking disputed records. If you don't have reliable figures, describe what you know and mark the gaps. You can start recording the relevant work now. Don't turn someone's exhausted recollection of event week into a precise baseline.

You also need to know whether training can solve the problem. The US Centers for Disease Control and Prevention's guidance on assessing training needs distinguishes missing knowledge or skills from problems requiring changes to policy, technology or working arrangements. That distinction is useful here. An employee cannot learn their way around a permission the account doesn't have.

Ask a staff member to show you where the current process becomes difficult. If they understand the task but the screen doesn't contain the needed information, investigate the setup. If the information is present but nobody knows who can authorise the next action, settle the responsibility. If the steps are clear and available but unfamiliar, practise them.

For example, suppose buyers keep receiving conflicting answers about changing a workshop booking. Before arranging another software tutorial, agree the change policy and who can approve an exception. Then confirm that the configured system supports the approved process. Only after that does it make sense to train customer service on the steps.

I would keep the first training goal narrow enough to observe. "Our support team can handle the agreed booking enquiries using the current record" is useful. "Everyone understands the new platform" is too broad to test, and it encourages a long demonstration of functions most people won't use.

Map the changed jobs with the people doing them

Sit with the person who handles each affected job and compare the old process with the proposed one. Follow actual work: creating an event, updating a booking, checking admission, contacting buyers and closing the accounts. Include the handovers. A job that looks complete to customer service may still leave finance with a question.

For each job, record what starts it, where the current information comes from, who acts and what a correct finish looks like. Add what the person should do when the normal steps cannot be completed. This can fit in a shared working document. You don't need a diagram of every application in the business before teaching someone to find a ticket.

The Chartered Institute of Personnel and Development's learning needs analysis guidance starts with the capabilities an organisation needs and compares them with existing knowledge and skills. Apply that to the changed assignment. An experienced box-office lead may need a short explanation of the new records, while a new assistant needs practice with the commercial rules too.

Here's an original outline you can adapt for each affected job:

• Job and reason for doing it: [the buyer request or operational task].

• Previous method: [where staff looked and what they changed].

• New method: [the approved record and supported action].

• Person responsible: [named role], with [backup] during absence.

• Permission needed: [the access required for this assignment].

• Correct finish: [what must be true for the buyer and the business].

• Stop and refer when: [specific uncertainty or limit], to [contact].

• Practice case: [a fictional example that tests the changed steps].

• Working instruction: [current version and where to find it].

Fill this out together rather than sending it as homework with no discussion. The person doing the job may remember a group-booking exception that the purchasing team never encountered. They may also know that the supposed manual process already stopped months ago. Both findings change what you need to teach.

Pay particular attention to work the software now handles. If a verified feature produces the current information, teach staff how to use it and stop requiring them to rebuild the same answer elsewhere. You don't want to buy a simpler system and preserve every old task as an unofficial extra check.

For example, Loopyah's ticketing and door tools let you add admins and door staff without sharing your login, and give door staff check-in access to scan QR tickets from their phones. Train that actual assignment with the right account. Creating a parallel attendance spreadsheet doesn't teach someone to use the permission and check-in process you've provided.

The organiser still decides who works at the door, what admission each ticket permits, and who resolves exceptions. A product capability doesn't settle those event decisions. Keep the training specific enough that staff can tell which part the system handles and which part needs a human decision.

Give the change an owner and protect time for the team

Name one person who can coordinate the change across departments. They keep the working instructions current, collect problems, arrange supplier answers and bring unresolved business decisions to the right lead. They don't have to perform every job or be the most technical person in the room.

The event lead should approve changes to what you've sold. Finance should confirm the meaning of reports and financial corrections. The people handling attendees should help design the service process. Your software supplier should explain supported behaviour and resolve faults it controls. Make these responsibilities visible so the coordinator doesn't become an unofficial decision-maker for everything.

Choose a backup for the jobs that must continue during absence. A team member who knows the system well can help colleagues practise, but that needs time in their workload. If they're also answering every buyer email and preparing the next event, their availability will fail precisely when everyone starts asking questions.

Tell staff why the change matters in terms of their work. "You'll stop checking two lists before answering a booking enquiry" gives them a useful expectation to test. "Management wants everyone on the new platform" gives them a rule without explaining what it should improve. Be equally honest about temporary inconvenience and functions that still require another tool.

Invite disagreement about the proposed process early. If someone says the new route takes longer, ask them to show you the task. They may need practice, or they may have found a real problem. Experienced staff shouldn't have to pretend an awkward setup works well to show that they support the change.

Protect paid working time for preparation and practice, with arrangements appropriate to your staff and contracts. Don't schedule training on top of a full event-day shift and assume the team will absorb it. Ask agency staff and contractors what time and access they need, and agree who trains replacements before confirming the plan.

Consider an invented paid-workshop business, North Quay Workshops. Its customer-service lead, Maya, coordinates the change. She reserves the earlier part of preparation for confirming the job instructions and arranging access. The team then practises while there is still time for the supplier to fix a configuration problem. A later rehearsal checks the corrections before the event lead decides whether the new process can handle live work. The first event has named support, followed by a review before another date moves across.

Those are stages of work, not a recommended number of weeks. Ask your supplier how long access changes and fault investigation can take, then work backwards from the proposed launch. If the available time cannot accommodate a correction and another check, change the launch scope or date. Compressing the slides won't create time to fix the delivered system.

Write the planned decisions in the calendar as well as the training sessions. Who confirms the instructions? Who accepts a corrected setup? Who decides that live use can begin? A diary full of meetings can still omit the moment when someone has to review the evidence and take responsibility for proceeding.

Teach roles in the order the work happens

A general introduction helps everyone understand the event and the reason for changing. After that, divide practice by assignment. Door staff need to use admission information and recognise when to refer a case. They don't need to watch the finance lead learn every report before touching a scanner.

Start with the people who configure the event and approve its rules. If the ticket setup changes after the front-line session, you may have trained staff on information that no longer applies. Confirm the event, ticket descriptions, access arrangements and relevant customer-service policy before recording instructions or asking people to practise.

Next, train the people who handle ordinary work, then bring the connected roles together. Have customer service explain a changed booking to the door supervisor, and have finance inspect the relevant record. This reveals the gaps between departments. Each person may complete their own task while the next person still lacks the information they need.

Use the supplier's introduction for product mechanics, then add your event's decisions. A trainer can show where to find a refund function. Your business must decide who can use it and what review is required for a particular request. Keep the supplier's explanation and the organiser's policy distinguishable in the instructions.

Ask for training on the configuration and plan you've actually bought. If a demonstration uses an administrator account or an optional service, stop and clarify whether staff will have that access. Our vendor demonstration checklist covers the buying stage. At this point, the requirement is that your own team can repeat the agreed work in the delivered setup.

Provide different ways to learn the same task. Some staff will use a short written instruction during practice; others benefit from a demonstration they can pause and replay. Make recordings readable, provide captions where needed, and ask about access requirements before the session. A video sent to someone who can't use it isn't a completed training arrangement.

Avoid treating confidence as the same thing as competence. A quiet employee who checks the instructions and completes the job correctly may be more ready than a confident colleague who skips the final check. Assess the action and result, including appropriate use of help. You're preparing people to do the work, not rewarding a presentation style.

Rehearse complete cases with safe practice records

Before anyone starts clicking, confirm where practice is allowed. Use the supplier's supported training or test setup and fictional personal details. Route any permitted messages to inboxes your team controls. Check that practice actions cannot unexpectedly charge a card, email an attendee, change live capacity or create an entitlement someone could use.

Don't assume that a copied event is safely isolated. Ask the supplier which connections remain active, whether automated messages can run and what must be disabled or replaced. If an important action cannot be simulated, document the limit and arrange a separate approved verification. Improvising test payments in production isn't a substitute for a supported method.

Build cases around what the person must decide. An ordinary booking should be straightforward. Then include the request that tends to cause trouble, such as an attendee looking at an old confirmation, a group buyer asking about one ticket, or a staff member finding two similar names. The exercise needs a defined correct result before it starts.

Have the employee perform the whole assignment. They should find the record, explain its status, take the permitted action and check the result. If another role must act next, include that handover. A trainer saying "and then finance sorts that out" leaves an essential part of the process untested.

Include a deliberate reason to pause. The right answer might be to stop a transaction, protect the current record and contact the lead. Staff need to practise that response without feeling they failed because they didn't finish independently. An employee who asks for the right help is following the process.

For tasks affecting safety, fit practice into the event's established safety arrangements. Great Britain's Health and Safety Executive explains in its training and competence guidance that training alone is insufficient and that practice and foreseeable operating conditions matter. That is safety guidance, rather than a universal rule for software administration. Don't let a successful ticketing exercise replace the separate competence checks a safety responsibility requires.

Write down what actually happened during practice. "Needed help finding the current booking" is useful. "Not good with technology" isn't. A precise observation lets you distinguish an unclear label, missing permission, forgotten step or misunderstood policy and choose the appropriate correction.

Follow one fictional team through its first rehearsal

Now follow North Quay Workshops into rehearsal. The fictional business is moving its next event's booking enquiries and admission work into a new system. The software has already been selected and configured. Data transfer is being checked separately. This example concerns staff learning and the decision to start live work. It doesn't describe a particular platform's features.

Maya owns the change and leads customer service. Leon approves the event's commercial rules. Jo supervises admission, and Suri handles financial checks. Their supplier has confirmed a supported practice environment with fictional bookings and controlled inboxes. The example assumes the relevant approved actions are available in that environment.

They choose one routine case and a changed booking that has caused confusion in the past. A fictional buyer originally books two places for the morning workshop. An authorised change moves one attendee to the afternoon workshop and leaves the other in the morning. The exercise starts after that change is complete, with an older confirmation still available for comparison.

The expected result is explicit. Customer service identifies the current session for each attendee. Admission uses the agreed current record rather than the old confirmation alone. Finance can trace the approved change without inventing a new sale. If the records disagree, the employee pauses the affected action and refers the case to Maya.

In the first attempt, a customer-service assistant finds the correct booking but tells Jo only that "the booking changed." Jo knows something happened, yet doesn't know which attendee belongs in which session. The software record is correct. The handover is incomplete.

Maya changes the instruction so the handover identifies the booking reference, affected attendee, current session, relevant status and next action. The team uses the approved private channel and limits personal information to what the recipient needs. They repeat the case with different fictional names to check that the assistant can apply the instruction rather than recite the previous answer.

During the second attempt, Jo's ordinary staff account cannot see the information needed for the agreed check. The trainer's account could, which concealed the problem. Maya records a configuration issue and asks the supplier and responsible administrator to resolve it within the intended access limits. She doesn't tell staff to share the trainer's login.

After the correction, Jo completes the permitted admission check and demonstrates what to do when a similar name appears. Suri follows the same changed booking through the financial record. The team records the result and retains the unresolved questions separately. Nobody marks the whole rollout ready simply because the original case eventually worked.

Turn the case into a reusable exercise

You can adapt the following exercise record. Keep it short enough that a supervisor can use it while watching the work.

• Assignment: [the job this staff member will perform].

• Starting position: [fictional booking, current status and relevant earlier information].

• Request: [what the buyer or colleague asks].

• Expected action: [permitted steps, including any referral].

• Expected result: [what must be correct in the record and explanation].

• Access and equipment: [the person's intended account and working device].

• Observation: [what they actually did, including help used].

• Correction needed: [instruction, practice, policy, configuration or supplier action].

• Repeat check: [who checks the corrected process and when].

• Remaining restriction: [what the person must not yet handle alone].

Use a fresh variation after correcting a problem. If the first exercise involved a changed session, try another approved session change with different booking details. Keep the core requirement the same, so the result remains comparable. A completely different task would tell you less about whether the original problem was resolved.

Make the working instructions usable during a shift

Give each role a short instruction for its frequent tasks, plus the route for unfamiliar cases. Start with what the person is trying to achieve and show the current steps in the actual setup. Explain what confirms success and what to do if the expected result doesn't appear.

Screenshots help when a control is difficult to locate, but don't let them replace the decision. "Select the current booking" needs an explanation of how staff distinguish it from an earlier confirmation or another event. Remove unnecessary personal details from examples and update screenshots when a changed screen would mislead someone.

Put the instruction where staff can reach it while working. Check that a temporary worker can open it using the account and device they'll have on the day. A document inside an office-only shared folder won't help someone at a remote entrance with no access to that folder.

Use a visible version and name the person responsible for updates. When an instruction changes, tell everyone affected what changed and whether they need to repeat a task. Replace old printed copies and check returning staff before they resume work. Editing a shared document doesn't establish that someone already on shift has read it.

Decide which old records remain available and what they are for. You may need historical information for existing bookings, settlement or a separate retention requirement. Label it clearly and restrict editing where appropriate. Staff should know which system controls current work and which older records provide reference information only.

Don't demand instant deletion of every spreadsheet. Ask what each one does. A spreadsheet may still serve a legitimate purpose the new system doesn't cover. Agree its owner, inputs and update method. The problem is two editable records claiming to be the current answer to the same question, with no rule for resolving a difference.

Keep any temporary workaround equally clear. State who may use it, what it covers, how resulting changes are recorded and when it will be reviewed. Otherwise a short-term repair becomes another process that new employees inherit without explanation. Where the workaround cannot support accurate sales or admission, keep that part of the operation paused until the responsible lead agrees a workable alternative.

Send a change note people can act on

Suppose North Quay corrects the admission instruction after rehearsal. Maya's update should say which task changed, which version replaces it and what staff need to do before their next shift. "Training materials updated" doesn't tell Jo whether the change affects admission or a report she'll never open.

An example note could read: "The session check in the admission instruction has changed. Version 2 now explains where to confirm the attendee's current workshop after an approved change. Use version 2 for your next practice attempt. Jo will watch that check before confirming your assignment. The earlier printed instruction is withdrawn. Ask Maya if your account cannot show the required information."

That is a fictional internal message, not a software notification or a promise that a particular screen exists. Adapt it to the supported process you have verified. When the change affects several departments, name their different actions in the same update so they don't assume someone else's acknowledgement covers their work.

Set readiness criteria before the first live use

Agree what each person must demonstrate for their assignment. For an admission worker, that might include selecting the correct event, using the permitted admission process, recognising a disputed record and reaching the supervisor. For finance, it may mean explaining the agreed transactions and identifying a mismatch for investigation.

Use the same critical requirements for people doing the same job, while providing appropriate learning support. Allow the working instructions where staff will use them in practice. You're assessing whether they can complete the assignment accurately under the planned conditions, not whether they have memorised a screen.

Watch a fresh attempt after teaching. Record which task was checked, the instruction version, the outcome and any restriction. Someone who needs more practice can work under suitable supervision or take another assignment until ready. Make that arrangement explicit rather than leaving a supervisor to discover it during opening.

For the rollout itself, I would require the following before accepting ordinary live work:

• The intended staff accounts and working devices can complete their assigned tasks.

• The agreed ordinary and exception cases produce the expected results.

• Staff know which record governs each job and where older information fits.

• Required handovers reach a named person who can act.

• Essential unresolved faults are corrected and the affected checks repeated.

• Support coverage and the approved alternative are available for the planned operating period.

These are proposed operating criteria, not an industry certification. Adjust them to the event, the consequences of an error and the services involved. Don't average a serious failure into a reassuring overall score. A team that finds most bookings correctly still needs a fix if it cannot distinguish the sessions it is admitting people to.

Separate restrictions on a person from restrictions on the system. If one employee needs more practice, arrange that support. If nobody with the intended account can do the job, the release decision concerns the setup. Repeating training while leaving the fault in place wastes the team's time and makes a system problem look like a staff problem.

Start with controlled use and support the first live event

Choose the first live use because it represents the work and leaves you room to supervise it. A smaller date may suit a recurring series if it includes the relevant booking types and staff. The quietest possible event isn't a meaningful trial when the real operation includes group changes, several sessions or temporary workers absent from the trial.

Keep the new system's scope clear. You might introduce it for a future event while existing dates remain on the previous system. Or you might change one separately managed process first. Confirm that the boundary is technically and operationally workable. Staff and buyers shouldn't have to guess which system handles a particular event.

Avoid leaving two public sales routes open against the same capacity unless the arrangement has been explicitly designed and verified. Keeping the old system available for reference or an approved recovery is different from letting staff sell the same inventory independently in both. That decision needs more than a training announcement.

Name the people covering the first on-sale period and event opening. Include break cover and the route when the coordinator is unavailable. Your supplier's normal support hours may not match your evening event, so confirm the arrangement in advance. Our software support agreement guide explains which service commitments to settle with a supplier.

Give staff a simple way to report problems without posting personal information into a public chat. Record the affected task, event or reference, observed result, immediate action and next owner. Separate an urgent operational problem from a useful improvement request. Both deserve attention, but they don't need the same response during the arrival rush.

New Zealand's National Cyber Security Centre recommends ongoing security awareness and easy reporting routes, including positive responses to people reporting mistakes. Include that in the change. Staff should know how to report a suspicious sign-in request or a message sent to the wrong place, and they shouldn't conceal an error because they fear being blamed.

For ordinary operating questions, keep the experienced helper available without making them take over every task. Let the employee explain what they see and carry out the approved next step when appropriate. If the helper completes everything themselves, the queue may move while the rest of the team remains dependent on them.

Agree the alternative before you need it. It might involve pausing the affected process, using a verified service route or delaying further rollout. Returning to old software requires a current, reconciled account of changes made since the switch. Don't promise a simple return unless the people responsible have checked that it can preserve accurate bookings, money and admission rights.

Prepare for someone joining after the main training

A replacement worker shouldn't inherit an account and a promise that a colleague will explain it when things get quiet. Give the supervisor a short induction route using the current instructions and the same essential checks for that assignment. Confirm the person's access before they arrive and allow time to practise on the intended device.

If they have used the software elsewhere, concentrate on your event's differences. They may already know how to find a booking, but need to understand the session names, admission rules and person handling disputed records. Let them demonstrate what they know. Don't make experience an excuse to skip the parts that are specific to your event.

When there isn't enough time for the necessary preparation, narrow the assignment or provide suitable supervision. Record the limit and tell the supervisor who takes over the remaining work. Giving the replacement unrestricted responsibility because the original employee is absent doesn't resolve the gap. The event lead must arrange work the available team can actually perform.

Measure completed work, errors and the support still needed

Training attendance tells you who was present. Sign-ins tell you who opened the software. Neither tells you whether staff can do their job. Look at the work you've agreed should improve, including whether it stays correct after a change and whether another role can use the result.

The CDC's guidance on measuring training effectiveness distinguishes learning from applying it at work. It also explains that a test only after training can show proficiency without establishing improvement. For your event team, observe comparable tasks before and after preparation where practical, then check how those tasks go during live work.

Track a small set of measures connected to the original problem. You might record booking cases completed correctly without unplanned help, cases requiring correction, time to a correct answer and the reason for referral. Include work left unfinished. A faster answer that sends the buyer to the wrong session isn't an improvement.

Compare similar work and keep the limits visible. A quiet workshop with experienced staff won't establish how a new process performs at your busiest conference. If you change staffing, product names and software together, the outcome reflects all of those changes. You can still make a useful decision without claiming the software alone caused the difference.

Here's an illustrative measurement exercise, using invented figures rather than a benchmark. Within its supported practice environment, North Quay observes staff attempting 40 booking enquiries in the new system before training. Staff complete 28 correctly without unplanned help, seven need help and finish correctly, and five require a correction after an incorrect first answer. The categories are mutually exclusive and account for all 40 cases.

After training, another 40 comparable practice enquiries produce 34 correct independent completions, four correct completions with help and two answers needing correction. The independent completion share rises from 70% to 85%. The correction share falls from 12.5% to 5%. These small fictional samples illustrate what to record; they don't prove what will happen live or establish an acceptable error rate.

The two corrections still need investigation. If both involve the afternoon-session instruction, Maya should fix that issue and repeat the relevant checks. She shouldn't describe the team as ready merely because the average improved. Any essential readiness condition remains a condition even when the overall direction looks encouraging.

At the first live review, check a comparable set of cases and discuss the differences. Staff may ask more questions because they now report uncertainties they previously hid. Ask whether those referrals were appropriate and whether they reached an answer. A falling question count can mean growing confidence, but it can also mean people have gone back to an unofficial spreadsheet.

Budget for learning and decide what happens next

Count the preparation your own team must do as well as any supplier training charge. Include writing the instructions, creating safe practice records, attending the sessions, observing attempts, correcting problems and supporting first use. If you budget only for the introduction call, the rest of the work still happens, usually by interrupting someone else's job.

Here's a fictional USD example for planning the resources. Eight front-line employees each spend two hours in practice, creating 16 staff hours. Maya separately spends eight hours preparing and observing, and four hours supporting first use, adding 12 hours. At an illustrative staff-time rate of $30 per hour, those 28 hours represent $840 of staff time. A supplier session costs $600, making the total planned resource cost $1,440. Attendance at that session is included in the practice hours already counted.

Assume the supplier charge includes applicable purchase taxes, the labour rate includes employment costs, and no overtime, travel or backfill is needed. The $600 is additional supplier spending. The $840 represents allocated existing staff time under these assumptions, rather than an extra payroll bill. Add actual replacement cover or overtime if you need it, and don't count the same hours again inside another project allowance.

This isn't a prediction that training will save $1,440 or produce extra ticket sales. It tells the event lead what the business must provide to make the change work. Compare the actual time and spending with the plan afterwards. Keep subscription charges, data migration and unrelated implementation work separate so you can see what the training itself required.

After the first live event, review the original goals with the people doing the work. Which jobs can they now finish? Which need repeated help? Which old records are still being updated, and why? Ask for examples. A request for another spreadsheet may reveal a missing report, an unclear instruction or a habit that no longer serves a purpose.

Choose the next action from those findings. Continue the rollout when the agreed work is reliable and the remaining limitations are manageable. Arrange focused practice when a task is understood but still unfamiliar. Correct the configuration or policy when several capable people hit the same obstacle. Delay expansion when an essential requirement remains unresolved.

Close temporary access and review continuing permissions through your normal process. Our event staff access review guide covers the checks after an assignment ends. Keep the current instructions, training observations and unresolved issues with the person who will maintain the process for the next date.

Before you move the next event over, ask a staff member who wasn't leading the project to handle a fresh example using their own account. Watch the booking enquiry, the explanation and the handover. If they need to guess which record is current or who can decide, resolve that part before giving the new process a larger audience.