4.05 Use Cases: The Tool to Better Choose and Deploy Your Software

Who will use the software and for which specific need?
This could be a box office manager to facilitate the management of discounted rates and attendance, a communications manager to automate the sending of personalized marketing campaigns, or the director of the venue wishing to access real-time attendance data.  

It is important to formalize the expected actions in the simplest, clearest, and most precise way by specifying the users, the objective pursued, the systems involved, describing the scenario, and defining evaluation criteria.

Example: Re-engaging occasional spectators to encourage their return

User: Marketing manager
Objective: Identify people who have attended only once in the last 6 months and send them a targeted follow-up.
Systems used: CRM, ticketing system, emailing tool

Use case scenario:

1. The user exports from the CRM the list of spectators who bought a ticket only once in the last 6 months.
2. They segment these spectators by age and type of show attended.
3. They create an automated email campaign with a special offer to encourage a return.
4. They track email open and conversion rates.

Evaluation criteria:

• Does the tool allow easy extraction of the desired data?
• Can personalized segments be created without technical knowledge?
• Is the email automation intuitive?

This test assesses the CRM tool's ability to interface with the emailing tool and whether the entire system effectively supports the planned action.  

Each use case should include performance indicators (KPIs) that will measure the effectiveness of the solution and help decide between different options.

For example, when choosing a CRM software, indicators might include:

• Time required to obtain and extract a targeted list of spectators.
• The software's ability to perform both "AND" and "OR" queries (i.e., to aggregate multiple different search criteria, either combining or adding results matching each criterion).

These metrics allow you to assess whether the solution truly fits the teams' needs.  

Once the use cases are defined, move to the concrete step of implementing each case to "stress test" the software and evaluate the solution.

This demonstration can be conducted by the software provider's team in your presence, or you can request temporary access so your teams can test it directly. In both cases, it's important to gather feedback from all participants after completing all use cases, to collectively assess the results and possibly compare the different solutions tested.

Pay special attention to:

• Ease of adoption by the teams
• Speed of performing essential tasks
• Functional fit with the use cases
• Quality of customer support and assistance

Of course, no software will cover 100% of your team's needs, especially not exactly as you initially envisioned technically.

This is exactly why use cases are valuable: they let you choose, among inevitably imperfect options, the one that best fits your priority professional needs, limitations included. It's also a reminder that the best software isn't the one with the most features, but the one that best serves your core workflows.

Once the software is selected, the use cases defined during testing will serve as the baseline for final acceptance and team training before deployment.