Skip to content

Choosing software for social institutions: A practical guide

A staff member working at a bright table with a laptop and tablet.

New software often accompanies a social institution for many years. It shapes how professionals document their work, how teams share information and how managers maintain an overview. Choosing it therefore carries considerable responsibility – and understandably, some uncertainty.

The good news is that you do not need to understand every technical detail from the outset. A sound decision is primarily based on clear goals, everyday work and responsibilities. This guide takes you step by step through the key considerations when choosing software for a social institution.

1. Start with the goal, not a feature list

Many selection processes begin with a long list of possible functions. This may feel thorough, but it quickly turns into a comparison of details before the actual problem has been understood. Start by defining what should improve for employees, clients and the organisation.

Possible goals include:

  • less duplicate entry and manual transfer;
  • reliable, consistent case documentation;
  • faster access to relevant information;
  • clearly defined roles and access rights;
  • less dependence on spreadsheets, paper and knowledge held by individuals;
  • better foundations for reports, planning and evaluations.

A good goal is specific enough to be reviewed later. Instead of “We want to become more digital”, try: “A progress report should be created without gathering the same information again from several sources.”

2. Involve the right people early

Software is not used by organisational charts, but by people with different responsibilities. A small, well-balanced project group prevents blind spots and builds acceptance. Alongside management, include professionals from day-to-day practice, administration, IT and, where appropriate, quality management or data protection.

This does not mean adding every request to the specifications. The group should make typical workflows visible, clarify priorities and communicate decisions transparently to the teams.

3. Describe real work situations

Abstract requirements such as “modern”, “flexible” or “user-friendly” are difficult to compare. Concrete scenarios from daily work are much more revealing. They show whether a solution genuinely supports a process or merely looks convincing on paper.

Useful test scenarios might include:

  • A new client is admitted and responsibilities are assigned.
  • A professional records a relevant observation while away from their desk.
  • A substitute needs the most important information about a case quickly.
  • Management creates an evaluation for a particular period or service.
  • An employee changes team and their permissions must be updated.

Ask providers to demonstrate these exact situations. You will quickly see how many steps are required, how intuitive the interface feels and where manual workarounds remain.

4. Prioritise requirements as must, should and could

No software meets every conceivable wish equally well. Clear priorities prevent rarely used specialist features from becoming more important than everyday work.

  • Must: Without this requirement, the institution cannot reliably fulfil its professional, operational or legal responsibilities.
  • Should: This function provides clear value but is not essential for launch.
  • Could: This capability would be useful but should not dominate the decision.

Keep the must-have list deliberately short. The longer it becomes, the more likely it is to exclude sensible solutions or lead to costly custom development.

5. Review the criteria that matter in the long term

Alongside professional functionality, several fundamental qualities determine whether software will work in practice.

Ease of use

Frequent tasks should be clear and require only a few steps. Pay particular attention to occasional users, new employees and mobile working situations. Training can explain processes, but it should not have to compensate for complicated operation.

Data protection and permissions

Social institutions process sensitive information. Clarify where data is stored, how access is controlled, whether changes are traceable and how joiners and leavers are handled. Our page on governance and security explains these foundations in more detail.

Adaptability without the custom-development trap

The software should reflect your institution's terminology, services, roles and relevant fields while retaining a stable shared foundation. Find out what can be configured, where custom development would be required and how future updates remain possible. Our page on customisation shows what this balance can look like.

Interfaces and data migration

Clarify early which systems must be connected and which data should be transferred from the existing solution. Do not ask only whether an interface is theoretically possible. Specify which information moves in which direction, how often and under whose responsibility.

Implementation, support and development

A good solution includes more than software. Ask how project management, configuration, migration, training and support are organised. It also matters how the provider handles feedback, how transparently the product is developed and who helps with professional questions after launch.

6. Compare total costs, not only licence fees

A low licence price can become expensive if implementation, interfaces, adjustments or internal effort are underestimated. Compare proposals over a realistic period and include:

  • one-off project, configuration and migration costs;
  • ongoing licence, hosting, maintenance and support costs;
  • interfaces and future adjustments;
  • internal time for the project team, data cleansing and training;
  • work that remains because of media breaks and parallel systems.

The expected benefits also belong in the decision: time saved, better information quality, fewer errors and more reliable processes.

7. Make the decision transparent

Use a simple evaluation matrix with a small number of weighted criteria for the shortlist. Combine scores with observations from the demonstrations and feedback from future users. A number cannot replace discussion, but it makes priorities and trade-offs visible.

The best software is not the one with the most functions. It is the solution that reliably supports your most important workflows and that people are happy to use every day.

Quick check before choosing software

  • Are goals and success criteria clearly defined?
  • Have professionals from everyday practice been involved?
  • Were real workflows demonstrated rather than individual features?
  • Have data protection, permissions and data location been clarified?
  • Are migration, interfaces and responsibilities described concretely?
  • Have all one-off and ongoing costs been considered?
  • Is there a realistic plan for implementation, training and continued development?

A good selection starts with good questions

Choosing software does not have to be a technical obstacle course. If you start with everyday work, make priorities explicit and involve the people affected, you create a sound basis for the decision. The new solution then becomes more than something that is simply installed: it becomes a tool that supports your institution over the long term.

For an initial market review, our overview of case management software in Switzerland presents ten different solutions and their focus areas.

Would you like to assess your requirements or see Lua using your own workflows? We would be happy to take the time for a personal conversation.

Consent

This site uses third party services that need your consent.