Module Packages for Community Management: What to Enable

What a module package is and why it matters

In community management, module packages decide which parts of the software are switched on for a given customer. In Site-Park the setting is made per customer: on the same platform, a small apartment building might see only dues and announcements, while a management company running several communities can use everything from accounting to patrol checks. The infrastructure is the same; what changes is how much of the interface you see.

This article is not a price list, and we are not promising what any package costs. What we offer is a decision framework: which modules to start with, which signals tell you it is time to switch on another, and how to make the change without disrupting the team. The most common mistake when adopting software is falling into one of two extremes: enabling everything on day one and drowning in screens nobody uses, or focusing on a single task and living alongside spreadsheets for years.

More modules does not mean more value

Site-Park carries more than 60 modules, and no single community needs all of them. In a thirty-unit building, guard patrol tracking, energy and SLA analytics or a multi-community portfolio report add little; to the caretaker, the manager and the residents they are simply extra menu items.

Too many modules carry three concrete costs:

• Learning load: Every new screen is a workflow someone has to learn. An unused screen is often a screen that gets filled in wrongly.
• Data quality: A half-completed module produces misleading reports. An empty meter list or maintenance log can look like "no problems" on a report page.
• Distraction: A resident who sees five menus they will never use finds it harder to do what they came for, such as paying dues or opening a request.

So it helps to treat the module package as a focusing tool rather than a restriction. A switched-off module does not deprive you of that function; it simply says that job is not on the agenda yet.

Where to start by community size

The starting points below are a general approach, not a rule. Your governing documents and your residents' habits may shift them.

A small apartment building or single-block community

Start with the money flow: dues assessment, collection tracking and expense records. Add announcements and maintenance requests for resident communication. The goal is to answer "who owes what, and which expenses are paid" on one screen. Until that core is settled, opening anything else makes little sense. For more depth on the dues side, see our piece on digital dues collection.

A mid-sized, multi-block community with staff

At this size caretakers, security and technical staff come into the picture. Visitor and parcel logging, amenity booking, maintenance schedules and an equipment registry become relevant. As the number of residents grows, requests passed on verbally or over WhatsApp start to go missing, and the request module begins to pay for itself.

A management company or multi-community portfolio

Here what matters is financial discipline and auditability: chart of accounts, trial balance, budget comparison, audit trail, approval workflows and the portfolio view. Each community's data stays separate while everything is managed from one account. We cover this setup in managing multiple communities from one account.

Signals that it is time to add modules

Rather than reading feature lists, it is healthier to watch for friction building up in daily work. These are good hints:

1. You are writing the same information in two places. If you keep expenses in the system but track maintenance history in a separate sheet, the matching module is due.
2. You answer the same question by hand again and again. "What is this unit's history?" or "when was this equipment last serviced?" repeated through the month is a screen waiting to be built into your routine.
3. An audit or general assembly is approaching. The document archive, resolutions register and audit pack help only if they collect data throughout the period, not just before it. Open them before year-end rush.
4. Your staffing changed. When a new security team or technical crew arrives, modules such as patrol checks and task tracking come onto the agenda.
5. The community grew or your portfolio gained a site. A lean setup that suited one community leaves a reporting gap at the fifth.

The opposite also holds: if three months after enabling a module nobody uses it, the problem may not be the software but an unclear process owner. Switching it off is a legitimate decision too.

Steps for switching on a module

The change itself can be technically simple; the real work is making sure the new module actually gets used. A practical order:

1. Name an owner. Give each new module one responsible person: security for parcels, the technical lead for maintenance, the manager for polls.
2. Set role permissions first. Enabling a module does not mean everyone sees it. Who can view and edit is a separate setting; our guide to the role permission matrix covers it.
3. Bring existing data in. An empty module convinces nobody. Load what you already know at the start: the meter list, equipment inventory or resident list.
4. Pilot on a small scale. Try one block or one equipment group first, so problems surface while they are small.
5. Review after four weeks. Look at the records the module produced: are they complete, current, and feeding reports? If not, fix the process or switch the module off.

Common mistakes

• Enabling everything at purchase on a "we might need it" basis. Turning a module on when the need actually arises is cheaper and less tiring.
• Opening a module and skipping training. If staff do not know the new screen they fall back to the old method, and gaps appear in the system.
• Not telling residents about changes. When a new menu appears in the resident app, people want to know what it is for; a short announcement is enough.
• Not asking what happens to a module's data when it is switched off. Before disabling a module, decide whether you will need its historical records. Talk to the support team at that point.

A short checklist before deciding

Before enabling a new module, answer these four questions:

• Which concrete problem will this module solve, and how is that problem handled today?
• Who will enter the records, and who will check them?
• What existing data will we start with?
• What will we look at in four weeks to say "it works"?

If you cannot answer all four clearly, it may be too early to open the module. That is perfectly normal; the package structure exists precisely to give you that flexibility.

Conclusion

A module package is the most practical way to fit software to your community: lean when you are small, comprehensive as you grow. The sound approach is to start with the core job, watch daily friction, open new modules as needs arise, and define the owner, permissions and success measure at every step. That way you steer the system rather than the system steering you.

If you would like to work out which combination of modules suits your community's size, you can browse the module range on the Site-Park product page and send us your needs through the contact form.