Workflow: Tenant

1. Receive and accept the invitation

The tenant starts with an invitation tied to a specific organization and building.

During acceptance, the tenant:

• creates an account
• is linked to one residential unit
• gains access only to the relevant building scope

This is the step that gives the tenant their operational context in Sicket.

2. Enter the dashboard

Once signed in, the tenant primarily uses Sicket for:

• creating tickets
• following their own tickets
• viewing community tickets in the same building when allowed
• reading announcements
• using tenant-safe self-service support

The tenant does not manage buildings, analytics, or staff-only content.

3. Create a ticket

When creating a ticket, the tenant:

1. selects or confirms the correct building and unit context
2. enters a title and description
3. chooses whether the ticket is personal or community
4. can optionally choose anonymous mode

Before final submission, Sicket can surface:

• similar community tickets
• self-service support answers
• a suggested ticket priority

These are advisory steps. The tenant can still continue with the ticket.

4. Follow the ticket after submission

After the ticket is created, the tenant can:

• check the ticket status
• add comments where permitted
• review activity history
• read staff-visible updates that are part of the public ticket conversation

If the ticket was created as anonymous, the tenant identity is masked where the backend enforces anonymity.

5. Use community visibility where helpful

If a ticket is community-scoped, the tenant may also benefit from:

• seeing that the issue already exists
• following the existing ticket instead of creating another one
• learning from how similar issues were handled

This is one of the main ways Sicket reduces duplicate reporting.

What a tenant cannot do

Tenants cannot:

• create buildings
• manage other users
• access analytics
• create internal notes
• manage the knowledge base

Their experience is intentionally narrow and resident-focused.