The Resident Has No Login
A tenant with a leaking tap is not going to be given a user account, a password policy and a role. Two ways of taking work from someone who is not a user already exist here — and neither of them is pointed at your residents.
A tenant's tap is leaking. They have three ways of telling you: a phone call to whoever answers, a message to whichever staff member they happen to have the number of, or a knock on the office door. All three arrive outside any system, and all three depend on the person who received it doing something about it.
The obvious fix is to let the tenant log it themselves. The obvious obstacle is that logging it themselves means having an account, and giving four hundred residents accounts in a business system is not a proposal anyone will accept — not the agency, which now administers four hundred logins, and not the tenants, who will not remember a password for something they use twice a year.
This is a well-understood problem with a well-understood shape of answer, and it is worth knowing which parts of that answer exist here and which do not.
The three ways to take work from a non-user
Every system that lets outsiders submit something picks from these, and they trade convenience against accountability in different places.
| Pattern | How it identifies them | Trade-off |
|---|---|---|
| An open form | It does not | Anyone can submit; you get spam and no accountability |
| A signed link | The link itself is the credential | Easy to use; anyone the link is forwarded to becomes them |
| A link plus a PIN | Something they have and something they know | Genuine accountability; a PIN to remember and to reset |
The third is the right answer for anything where it matters who submitted it, which for a maintenance request it does — a repair authorised by an anonymous form is a repair anybody in the building could have ordered against somebody else's tenancy.
A repair request from an anonymous form is a repair anybody in the building could have ordered against somebody else's tenancy.
What already exists, and who it is for
Both of the serious patterns are built here. Neither is pointed at a customer.
Employees without a login get a tokenized portal protected by a PIN. It covers requesting leave, clocking in and out with corrections, viewing payslips, and — most relevantly — raising and tracking helpdesk tickets. The PIN is stored hashed rather than in plain text, failed attempts are counted, and the portal locks after too many, requiring somebody in HR to reset it. Every write route is rate-limited.
Suppliers get a public application form and then a signed link for submitting further documents against their application, so a vendor can be brought through prequalification without ever holding an account.
So the machinery is real and it is proven in two directions. What does not exist is the third: a tenant, a customer or a resident raising and tracking anything without being made a user.
What that means for a managing agent
Maintenance requests have to reach the system through a member of your staff. That is not fatal — most agencies operate exactly that way — but it should be a deliberate design rather than a discovered limitation, because it decides where the record starts. A repair reported by phone exists from the moment somebody logs it, not from the moment it was reported, and the gap between those two is where your response-time figures quietly go wrong.
Designing the intake you can actually have
Given the constraint, the goal is to make the staff-mediated route fast enough that it always gets used, and to close the gap between when a tenant reports and when the record starts.
-
Give the reporting route one destination
One number, one email address, one desk. Reports that arrive on four staff members' personal phones cannot be logged consistently by anybody, and the tenant is not the person who should be routing them.
-
Log it while the tenant is still on the phone
Not afterwards, not at the end of the day. The response clock is anchored on when the ticket is created, so a report logged three hours later has silently consumed three hours of its target.
-
Read the reference back to them
It converts a call into a transaction with a receipt. It also cuts the chasing calls substantially, because the most common reason a tenant calls twice is not knowing whether the first call landed anywhere.
-
Capture the unit reference in a consistent field
Since there is no unit entity, this is a convention you impose — the customer, a project, or a custom field. Choose one and use it every time, or the portfolio cannot be reported on at all.
-
Decide who logs it out of hours
Reports do not stop at five. If the answer is that the caretaker sends a message and somebody logs it at nine the next morning, that is a workable answer as long as it is the written one and the clock consequence is understood.
The second step is the one with the measurable consequence. A portfolio that logs reports promptly and one that batches them at the end of the day will show materially different response performance for identical actual behaviour, and only one of those figures is telling you something true.
What AWRA OpsHub does today
- A tokenized, PIN-protected portal for employees without a login, covering leave, time, payslips and raising and tracking support tickets.
- PINs are stored hashed, failed attempts are counted, and the portal locks after too many — reset by a person rather than automatically.
- Public routes are rate-limited, so the forms cannot be hammered.
- A public supplier application with a signed follow-up link, so a vendor completes prequalification without an account.
What it does not do
- No tenant or customer portal. A resident cannot raise or track a maintenance request without being given a user account, so requests reach the system through your staff.
- No public maintenance form scoped to your organization. The supplier application proves the pattern works; there is no equivalent pointed at residents.
- No status visibility for the person who reported it. Even where a request is logged promptly, the tenant has no way to see it progress and will call to ask.
Not ours, by choice
- We will not put an unauthenticated form in front of your maintenance queue. An open form takes work from anybody who finds the URL, and a queue that anyone can write to stops being a queue within a fortnight.
- We will not give residents accounts in the business system by default. A tenant does not need — and should not have — a login to a platform holding your suppliers, your staff and your finances.
A tenant portal on the same token-and-PIN pattern — raise a request, see its status, view a statement — is scope rather than a ceiling. The tokenized portal, the hashed PIN with lockout, the rate limiting and the ticket intake all exist and work for employees; pointing the same machinery at customers is a written specification and a price.
Worth weighing honestly as an agency: staff-mediated intake is how most portfolios already run, and the cost is not the logging — it is the chasing calls from tenants who cannot see whether anything is happening. If those calls are a large part of your week, a portal is the thing that removes them, and it is worth scoping rather than absorbing.
What a portal actually saves
It is worth being precise about the return, because the usual argument — that tenants will log their own repairs and save your staff the typing — is the smaller half of it.
The typing is trivial. What consumes a managing agent's week is the second contact: the tenant who reported something last Tuesday, has heard nothing, and calls to ask whether anything is happening. That call takes five minutes, produces no new information, and happens for a large proportion of open requests.
A portal removes that call by making the status visible. That is the return, and it is why status visibility matters more than submission — a portal a tenant can only submit through, without seeing what happened next, saves you the typing and none of the calls.
If you scope one, insist on these
- The tenant can see the status of what they reported, not just submit it. This is the whole return.
- It works on a phone browser with no app to install, because it will be used twice a year.
- Identification is a link plus something they know, so a forwarded message does not become somebody else.
- A locked-out tenant can be reset by your office staff rather than by a support ticket to a vendor.
- Submissions land in the same queue as staff-logged requests, not a separate inbox somebody has to remember to check.
- It carries the unit reference automatically, so the convention you chose is applied without anybody typing it.
The fifth item is the one that quietly ruins portal projects. A submission route that lands somewhere separate from the main queue creates a second place to look, and a second place to look is a place that gets looked at less often than the first.
The response-target consequences of when a ticket is created are in within one working day, the work-order handling in maintenance and work-order control, and the modelling conventions underneath all of it in no such thing as a unit.
Our take
Plan on staff-mediated intake, because a tenant cannot raise a request without an account and you are not going to give four hundred residents accounts. Make that route fast: one destination, logged while the tenant is on the phone rather than at the end of the day, with the reference read back. The end-of-day habit is the expensive one — the response clock runs from when the ticket is created, so batching reports quietly consumes hours of every target. And if chasing calls are eating your week, a tenant portal is the thing that removes them, on machinery that already works for employees and suppliers.
See intake from people without accounts
A tokenized PIN-protected portal for people who are not users, hashed PINs with lockout and a human reset, rate-limited public routes, and a signed follow-up link for supplier documents.
Explore self-service portalsFrequently asked questions
Can tenants log their own maintenance requests?
Not without a user account, which for a residential portfolio is not a realistic proposition — neither the agency nor the residents want four hundred logins to a system holding your suppliers, staff and finances. In practice requests reach the system through your staff, by phone or email or at the desk. That is how most portfolios run and it works, provided the logging happens promptly rather than at the end of the day.
Why does it matter when the request is logged?
Because response targets are anchored on when the ticket is created rather than when the tenant reported it. A report taken at nine and logged at four has silently consumed seven hours of its target before anybody looked at it. Two agencies behaving identically will show materially different response performance purely on their logging habits, and only the one logging promptly is producing a figure that means anything.
Does any kind of self-service portal exist?
Yes, for employees and for suppliers. Employees without a login get a tokenized portal protected by a PIN, covering leave, time, payslips and raising and tracking support tickets — the PIN is hashed, failed attempts are counted, the portal locks after too many and a person resets it, and the public routes are rate-limited. Suppliers get a public application plus a signed link for submitting further documents. The machinery is proven in two directions; what does not exist is a version pointed at customers or tenants.
Could we just put a public form on our website?
An unauthenticated form takes work from anybody who finds the URL, and a maintenance queue that anyone can write to stops being a queue within a fortnight. It also removes the accountability that matters most here — a repair authorised by an anonymous submission is one anybody in the building could have ordered against somebody else's tenancy. If you want tenant submission, the pattern worth having is a link plus something they know, which is exactly what the employee portal already does.
What would a tenant portal actually save us?
Not the typing, which is trivial. The second contact — the tenant who reported something last Tuesday, has heard nothing, and calls to ask whether anything is happening. That call takes five minutes, produces no new information, and happens for a large share of open requests. Status visibility removes it. Which is why a portal a tenant can only submit through, without seeing what happened next, saves the typing and none of the calls.
How do we tie a request to a specific flat?
By a convention you choose and apply consistently, because there is no unit or tenancy entity — the tenant as a customer, the building as a project, or a custom field carrying the unit reference. The important part is choosing one before you start, since a portfolio logged three different ways cannot be reported on at all, and retrofitting the reference onto eight months of tickets is work nobody ever finds time for.
