# Jira Service Management for Property Management | FluxCo Technologies > Jira Service Management is built for IT help desks, not properties. How we set it up for a residential and strata manager: spaces, assets, automation, SLAs and the traps to avoid. Source: https://fluxcotech.com/blog/jira-service-management-for-property-management/ --- Jira Service Management is built for IT help desks. Out of the box it knows about laptops and password resets, not properties, units, tenancies and owners. But underneath is something a property manager needs badly: one place where every request lives, linked to the records it's about, with a status anyone can check. Here is how we set it up for [Eagleson Properties](/work/#eagleson), a residential and strata manager, and what we'd tell anyone about to try it. ## One space per kind of work Don't put everything in one queue. Eagleson runs separate spaces for maintenance, strata, tenant matters and internal operations, because each has different people, different steps and different deadlines. Inside each space, organise request types by **who is asking**, not by what broke. In maintenance: - **From tenant**, **from owner**, **from another tenant** - **From contractor**, which opens waiting on a quote - **From the city or tribunal**, which opens at high priority with a compliance label - **From the team**, which sends the customer nothing - **Emailed request**, for anything that arrives by email - **Urgent request** Who is asking decides the priority, who gets told and what happens next. What broke is a field, not a request type. The strata space follows the same idea with its own types: bylaw questions and enforcement, maintenance and capital work, special levies, AGMs and council business, insurance renewals and owner communications. ## Put the portfolio in Assets This is the part that turns a help desk into a property system. Jira's Assets holds the portfolio as linked records: properties, units, owners, tenants, tenancies, strata plans and council members, contractors, parking, storage, insurance policies and management agreements. About 3,300 records across 15 types at Eagleson. Three decisions mattered most: - **Keep the tenant and the tenancy separate.** The tenant is a person. The tenancy is the lease, with start and end dates. People move units and leases end, so requests link to the current lease, not the person's history. - **Give every request the same set of fields:** property, unit, tenant, tenancy, owner and contractor. Then every report, queue and automation can rely on them being there. - **Only show active records in pickers.** Nobody should be able to file a request against a lease that ended last year. Long notes about a building, such as access, quirks and history, live in Confluence. Assets keeps the structured details and a link to the page. ## Let automation do the linking Nobody should have to fill six fields by hand on every request. - **From the sender's email**, the request links itself to the tenant, unit, current tenancy, property and owner. - **Picking one tenant fills the rest**, with a way to switch that off for the odd case where it's wrong. - **The request type is tagged from the sender**, so owners' and contractors' emails sort themselves. - **Contractors and owners get their own linked request** when they're looped in, and the tenant's request can't close while a contractor's is still open. - **Known noise closes itself.** Calendar replies and other machine mail that's never a request close on arrival. Anything else machine-sent gets a label for a person to review, rather than being thrown away. ## Keep the tenant's side simple Eagleson's tenants never use the portal. They email the address they always have, and that's fine. What tenants see is cut down to four statuses: open, in progress, action needed from you, and resolved. The team works with far more steps than that, but internal moves send the tenant nothing. Notifications are trimmed to the ones a tenant would want, mainly a public reply from the team. ## SLAs that match the work Three clocks, each answering a different question: - **Respond:** someone replies within one business day. - **Triage:** someone looks at it and decides what it is within one business day. - **Resolve:** set by priority, from 48 hours for urgent work to 120 days for the lowest. All three pause while a request is on hold or waiting on the tenant, so the clock measures the team, not the wait. Capital projects are left out of the resolve clock, because a roof replacement is not a late repair. ## Queues and dashboards people actually open Queues for all open work, my work, unassigned, stale requests, capital projects and requests missing their property links. The last one matters more than it sounds: it's how bad links get caught before they turn into wrong reports. Dashboards show requests in against requests closed each week, average age, the split by status, and lists of anything waiting on a reply, unassigned or urgent. ## What we'd tell you before you start These cost us time. They'll save you some. - **The "request received" email is all or nothing.** You can't easily send different wording to tenants, owners and contractors. Automation that adds a public reply is the workaround. - **Renaming a request type can quietly break automation** that refers to it by name. Check your rules after any rename. - **If an asset field stays empty, check the field's own filter first.** It is more often the cause than the automation itself. - **Asset fields can't be queue columns.** Plan queues around fields that can. - **One email address, two kinds of account, blocked customer.** If someone has a full Atlassian account and a customer account on the same email, their requests can be blocked. - **Reopening a request doesn't clear its resolution.** Keep the resolution field off the screens people edit, and let automation own it. - **Bulk edits reset "last updated".** If staleness rules depend on it, a cleanup run makes everything look fresh. - **Don't blanket-close no-reply mail.** Real notices come from those addresses too. Label it for review instead. - **Share dashboard filters with the team**, or everyone else sees empty gadgets. ## Start with one space You don't need all of this on day one. Start with maintenance: the email address, the assets it links to, and a handful of request types. Get it running live, then add strata, tenants and the rest. Once requests and records live in one place, everything else, [including AI](/blog/ai-for-property-management-back-office/), gets easier. For the email side in more detail, see [how to turn maintenance emails into tracked requests](/blog/maintenance-emails-into-tracked-requests/). If you're weighing Jira Service Management for a property or strata business, [reach out to discuss](https://fluxcotech.com/#contact). We'll tell you where to start, or tell you it isn't the right tool for you.