Aricie’s Support Model After You Buy a Module

Buying a software module is the start of an operational relationship, not the final step. For an Australian organisation selecting a DotNetNuke solution from Aricie, the important questions concern installation, configuration, user training, updates and the process for resolving issues.

Aricie combines IT services, custom software development and professional training. Its application portfolio includes tools such as Acoléa, Adylic, AricieGrid and Budg-Immos, so the support experience may vary according to the module, the hosting environment and the level of tailoring required.

Australian customers also need to consider practical matters such as time zones, privacy obligations, internal approval processes and integration with existing business systems. A support model that is clear about these areas helps teams in Sydney, Melbourne, Brisbane and regional locations plan with greater confidence.

The best post-purchase experience usually follows a defined path: establish the technical baseline, configure the application, transfer knowledge, manage incidents and review future improvements. Understanding that path makes it easier to distinguish routine assistance from paid custom development.

Support area	What it typically covers	Customer benefit
Installation and setup	Environment checks, deployment and initial configuration	A reliable starting point
Functional assistance	Guidance on module features and workflows	Faster user adoption
Troubleshooting	Investigation of errors, access problems and unexpected behaviour	Reduced disruption
Training	Sessions, documentation and administrator guidance	Greater internal independence
Maintenance	Updates, compatibility checks and technical recommendations	A safer long-term platform
Custom work	Enhancements, integrations and special business rules	A solution aligned with local needs

Establishing the Technical Baseline

After purchase, the first useful step is to confirm where the module will run and how it will connect to the wider portal. This may include the DNN version, database configuration, authentication method, hosting arrangement, browser requirements and access permissions.

For an Australian business, the hosting discussion may also cover data location, backup arrangements and the handling of personal information. Organisations governed by the Privacy Act 1988 and the Australian Privacy Principles should establish who can access customer records and where those records are stored.

A clear baseline prevents avoidable delays. It also gives Aricie and the customer a shared reference point when diagnosing a fault or assessing whether a requested change falls within standard support.

Configuration Before Customisation

Many modules can be adapted through settings, roles, fields, workflows and templates before code changes are considered. Support teams generally help administrators understand these options and apply them to the customer’s business process.

This distinction matters because configuration is usually quicker to maintain than bespoke development. A property group using Budg-Immos, for example, may first refine permissions, reporting views and approval steps before requesting a new feature.

If the required behaviour cannot be achieved through available settings, Aricie can assess the request as a custom software task. The customer should then expect a separate discussion about scope, testing, delivery time and ongoing maintenance.

Resolving Issues Efficiently

Effective troubleshooting begins with useful information. A support request should describe what happened, which users were affected, the steps that produced the issue, the browser and device involved, and whether the problem can be reproduced.

Screenshots, error messages and relevant timestamps are particularly valuable for teams working across Australian business hours. A Melbourne office operating on AEDT may have a different overlap with a French support team than a Brisbane office, which remains on AEST throughout the year.

Support may then classify the matter as a usage question, configuration issue, software defect, hosting problem or enhancement request. That classification helps set realistic expectations and directs the case to the right technical specialist.

Training Administrators and Users

A module delivers more value when the customer can manage routine tasks internally. Training can cover administration, permissions, reporting, content management and common recovery steps, with documentation available for staff who join later.

Australian teams often need training that suits distributed working patterns, including hybrid offices and regional staff. Short online sessions can be scheduled around local operating hours, while recorded demonstrations and administrator guides help reduce repeated support tickets.

Training should also include governance. Staff handling personal data need practical guidance on secure passwords, access reviews, retention practices and escalation procedures, rather than a simple tour of the interface.

Managing Integrations and External Content

A module may need to exchange information with a CRM, finance platform, identity provider or public website. Support can help determine whether an integration is available through existing settings, requires an API connection or should be treated as a separate development project.

External content deserves additional care. If a portal embeds third-party material, the parties should review security, performance, accessibility and legal suitability before release. For example, a request to display interactive slot examples would need a review of audience, consent, responsible-gambling requirements and Australian regulatory expectations rather than being treated as a simple visual component.

The same principle applies to analytics, marketing forms and social feeds. Integrations should be tested in a non-production environment and documented so future administrators understand what may break when a provider changes its service.

Planning Updates and Ongoing Care

Post-purchase support does not end when the first configuration is complete. DNN upgrades, browser changes, security patches and alterations to connected systems can affect module behaviour, so customers benefit from periodic health checks.

A sensible maintenance arrangement identifies who approves updates, who tests them and how a rollback would work. It should also clarify whether support includes standard product assistance, priority incident handling, training refreshers or additional development.

For Australian organisations, the review can include accessibility expectations, the Australian Consumer Law where relevant to service arrangements, and operational coverage during public holidays or peak periods. Businesses can contact Aricie to discuss their module, hosting environment and desired support level, then establish a practical service pathway that keeps users productive after deployment.