Mobile app development for a housing and utilities management company

Management Company Mobile App: Where Resident Request Intake Breaks Down

In a management company, a resident's request rarely starts with a request—it starts with a phone call.

The concierge writes the address in a paper log, the resident duplicates the same thing in the building chat, and the technician learns about the job from the dispatcher by phone.

There is no single request number, so reconstructing who took the job and when is possible only from the participants' memory.

Next, priority breaks down. A leak on a riser and a light bulb replacement end up in the same list and differ only in how alarmed the caller's voice sounds.

Emergency requests wait while the dispatcher manually sorts through incoming items, and the regulatory response deadline is already running.

The third gap is feedback. The resident cannot see the status and calls again, so request tracking grows: one job is recorded in the log, in the messenger, and in the dispatcher's memory.

The concierge shift goes to clarifications instead of taking new requests, and repeat calls distort building statistics.

Resident request intake becomes manageable when a request has structure: type of work, address with sub-object, emergency flag, assignee, deadline, and history of transitions between statuses.

Housing and utilities dispatching then turns from manual call distribution into routing of records, where escalation triggers by rule rather than by the duty officer's attentiveness.

We look at how a management company mobile app addresses this and what changes in the work of the dispatcher, technician, and resident.

Measurable Effects: Response Speed and Dispatcher Workload Relief

The first thing that changes is response time to a request. A resident photographs a leak or a stuck elevator, selects the address and problem type, and the request enters the queue with a timestamp.

Recording takes less than a minute, whereas a call to the dispatch office to clarify the entrance and apartment is several minutes of conversation and just as long again to transfer into the log. On a shift with two hundred requests, the difference adds up to hours of dispatcher work.

Dispatcher workload decreases not through speed but through self-service. Meter readings, certificates, the status of an already submitted request, and calling a technician using a template are handled by the resident without a call.

In a typical building, a third of requests go through the app, and they do not occupy the line—the dispatcher remains available for emergency and conflict cases where a person is needed.

The share of requests closed on time grows because the deadline stops being a verbal agreement. Each work category has a target time, the timer is visible to both the resident and the technician, and overdue items are automatically escalated to the district manager.

Not 'we'll try today,' but a specific interval against which the completion percentage is later calculated—by building, by district, and by contractor.

Repeat resident requests for the same problem are the most honest quality indicator.

If after a leak repair the person writes again a week later, the work was not actually accepted: the app requires before-and-after photos and a closure mark, and the history for the property is preserved.

Comparing the repeat rate before and after implementation shows whether the repair was closed 'on paper' or actually solved the problem.

Implementation Options: Ready-Made Platform, Customization, or In-House Build

The choice between three paths is determined not by preferences but by what already works in the environment: whether there is billing and a customer portal, how standard the processes remain, and whether a non-standard scenario provides an advantage worth maintaining for years. Let's examine how each path limits us after launch.

Comparison of Implementation Options

Limitations are more important than the list of capabilities: they show what cannot be changed without rewriting. That is why we start with an analysis of the current environment—a data map, exchange points, and a list of scenarios that differ from standard ones.

It shows where configuration is enough, where customization fits on the existing foundation, and where a standard platform starts to hinder processes and the logic is easier to build separately.

Implementation Stages: From Process Analysis to Handover to Operation

We fix the work order before development starts: app failures in housing and utilities arise not from the interface but from discrepancies with the accounting system—accounts diverge, a request is lost during a status change, readings go to the wrong period.

That is why we structure the implementation stages so that each link is tested on the management company's real data.

1. Process assessment. We analyze the work of the dispatcher, inspectors, and accounting: who creates a request, how statuses change, and where requests are lost now. We compile directories of buildings, premises, and accounts, and assess data quality.

2. Schema design. We fix roles and rights, the request model with change history, and the set of data that the app displays and accepts. Here we also agree on the integration map with the accounting system.

3. Configuration and integrations. We connect exchange with request accounting: charges and debt, meter reading intake, requests linked to premises, and status export back. We separately describe behavior when connectivity is lost—a request must not disappear.

4. Testing on real requests. Pilot operation on a limited group of buildings: employees work in parallel with the current process, and we reconcile discrepancies with the accounting system. The exit criterion is matching data and no lost requests.

5. Employee training. Short scenarios for each role—from request intake to closure with photo documentation—and a review of common errors using examples from the same company.

6. Handover to support. We provide access credentials, the update and request handling procedure, a known limitations log, and the procedure for rolling back to the previous working version.

After that, changes go through the same verification as launch: a change in the app must not break exchange with the accounting system. Discrepancies surface at the verification stage, not in the middle of heating season.

Deliverables: App, Integrations, Documentation, and Procedures

The delivery is not only a working app. It is a set of artifacts with which the management company's team continues to work independently: builds, source code, a diagram of connections with accounting systems, a rights matrix, and procedures. Below is what remains in your hands after acceptance.

• App builds for current iOS and Android branches, published in the stores under the customer's name, with transfer of access to developer accounts.
• Source code in the customer's repository: project structure description, branch rules, and release build procedure.
• Integration diagram with billing, accounts, dispatch service, and external information systems: exchange points, data formats, and handling of unavailability.
• Role and access rights matrix: resident, dispatcher, accountant, technician, building supervisor—what each role sees and what actions are available to it.
• Response templates for typical requests: meter reading submission, emergency request, dispute over charges, debt.
• Employee instructions: request handling scenarios from intake to closure, with handover between the dispatcher and field technician.
• Update and rollback procedure: how a new version is released, which checks are mandatory before publication, and how to return to the previous build.
• App documentation: architecture description, data schema, change log, and the procedure for accepting support requests.

Case Study: How Emergency Request Response Time Was Reduced

A management company services residential housing in several districts: the dispatch office took calls, requests were recorded in a paper log, and they were passed to the technician by voice.

An emergency leak request could wait until morning—the duty officer did not see which plumbers were on shift, and the resident did not receive a status and called again.

Where We Started: Baseline Measurement Before Launch

Before development, we manually collected metrics for two weeks: time from request to technician dispatch, the share of requests closed within the regulatory deadline, and the number of repeat calls for a single address.

The main failure point turned out to be request handover—one in five requests was lost between the dispatcher and the assignee, and there was no way to notice it: the log was not linked to accounts or building history.

What We Changed and What Resulted

A request is now created in the app, automatically linked to the building and account via 1C, and enters the duty officer's queue with priority by emergency type.

The technician closes it from a phone, attaching before-and-after photos, and the resident sees the status and does not call again.

Over three months, average emergency response time dropped from several hours to forty minutes, the share of requests closed on time grew from two-thirds to over ninety percent, and repeat requests fell by a factor of three.

The customer sums up the result briefly: 'Before, we learned about a leak in the basement from a resident; now we learn about it from the plumber who is already on the way.' They separately note that they no longer spend time sorting out disputed requests: each one has a photo, time, and assignee.

What to Do If the Management Company Already Has a Customer Portal

If a customer portal on the website already works, a separate app is not always needed. First, we analyze the mobile scenario: meter reading submission, payment, request to the dispatch office, chat with building management.

If the mobile share in the portal is growing, but drop-offs occur at meter reading submission and payment, the issue is not the absence of a client but how the forms and authentication are designed.

Preserving the existing system does not require rewriting accounting: the client connects to the same directories of accounts, charges, and requests through an access layer, and the website portal remains a working entry point.

Data migration comes down to linking the device to an account and transferring authentication—payment history is not duplicated and remains in the current database.

The selection criterion is simple: if a person returns to the service almost every week and expects notifications, a separate client pays off through retention and dispatcher workload relief.

If the scenarios are one-off and fit within a browser, portal customization solves the task faster, without a second support loop.

Common Technical Concerns: Integrations, Access, and Support

Technical concerns about a management company app relate not to the interface but to integration with what already works: the billing database, dispatch office, employee rights, and connectivity at properties. Below are four questions that most often come up during evaluation.

How is access rights differentiation handled?

We describe roles based on actual work: an owner sees their own account and requests, a dispatcher sees the whole building, a technician sees the assigned district, and a contractor sees only requests assigned to them.

Rights are checked on the service side, not in the app, so changing the role on the device achieves nothing, and actions are logged.

What happens if the resident has no network?

The request, readings, and photos are saved on the device and go to the system when connectivity appears—requests lost in entrances without coverage do not remain. Re-sending after a failure does not create duplicates.

Who maintains the app after launch?

Maintenance is a separate procedure, not a one-time customization: updates for new OS versions, availability monitoring, backups, and a fixed response time to failures. Planned changes are released on an agreed schedule, and unplanned ones on request.

Let's Discuss the Task: We'll Analyze Processes and Return with a Plan

To make the project estimate substantive rather than a rough guess, we need a minimum of input about your processes.

The first conversation takes 40–60 minutes: an engineer and an analyst review the scenarios of residents, the dispatch office, and inspectors, clarify which systems the app will need to integrate with, and identify where the bottlenecks are in the current processes.

• roles and scenarios: what the resident, dispatcher, plumber, and accountant do, and which operations move into the app;
• systems for integration: billing and charges, dispatch service, registration desk, intercom systems, state housing and utilities information systems;
• data examples: charges, requests, meter readings, payment history—standard exports will do;
• payment requirements: bank acquiring, bill printing, restrictions on payment acceptance;
• launch conditions: timelines, phasing, requirements for protecting residents' personal data;
• who on your side makes decisions and signs acceptance certificates—so approvals do not drag on.

Based on the conversation, we fix the boundaries: what we cover in the first phase and what we move to subsequent phases.

We return with a stage-by-stage work plan and the scope of work for the app—screens by role, integrations, access rights, test environment, and publication in app stores.

The project estimate is broken down by stage and with openly stated assumptions: it is clear what we take on and what remains with your team. Describe the task—we will return with an estimate and work plan.