What's the process now: Maintenance requests are created in Service Fusion, but the mobile app is slow and unreliable. The ops lead uses WhatsApp to track job progress, techs forget to clock in/out, and the multi-tech bug leaves jobs stuck on 'scheduled' even after techs start, so completed work can go missed. Every completed job is then re-edited by hand for billing — the description rewritten, the hours adjusted.

What we're going to build & how: A fast dispatch system built on Rent Manager that replaces Service Fusion. Jobs are created per building with a single arrive-by window (no separate duration estimate), assigned to one or more techs, with geofence-verified clock-in/out and simplified statuses (Started, Paused, Partially completed, Completed — plus Ready for accounting). Each job carries two descriptions: the work-order description the field crew sees (tenant phone, unit, what to check) and an invoice description drafted after completion — auto-populated with the hours each tech actually logged, fully editable, with the original work-order description preserved for lookback. After the crew closes a job it enters review: admin or office — never field crew — verify the receipt, edit hours and descriptions, and flip it to Ready for accounting, the signal that it can be billed, with at-a-glance counts of what still needs review. Dispatchers see a calendar view of all jobs with status at a glance, on the desktop and the admin phone alike, so jobs can be prepped for accounting from anywhere. Techs get a mobile app showing only their assigned jobs, with a mandatory closing note, photos, a receipt required to close (or an explicit no-receipt check), and a no-access log. The system tracks time per tech per job, and job status derives from time entries — fixing the multi-tech bug. Includes tenant no-access reporting and repeat-issue detection. How it works: The mobile app queues photos and notes offline and syncs when a signal returns, so techs in basements or dead zones aren't blocked. The data lives in Rent Manager; jobs and time entries sync via the API. Dispatchers enter jobs on the web dashboard or the admin phone, techs update status and time on the phone.

Every user signs in as themselves and holds a role that decides what they may do — raise a ticket, convert one to a job, edit hours after completion, flip a job to Ready for accounting. Roles are enforced on the server, not merely hidden in the screen, and they are part of the platform rather than an option, because a system where everyone can do everything is not a system anyone should run.

Push notifications on the phone, so a technician knows a job has landed without opening the app and an office user knows a ticket needs them. The notification plumbing is built once here and used by every part of the platform.

Tools: Rent Manager API, mobile app (Android/iOS) with offline queue, geofencing, photo upload, web dispatch dashboard.

The headache it kills: The ops lead relies on WhatsApp to track jobs because Service Fusion is too slow on mobile. This replaces the manual WhatsApp loop with a real-time dashboard.

What's the process now: Requests come in via phone, WhatsApp, and the ManageGo portal, scattered across channels. Dispatchers have to check each separately, which causes missed or delayed responses.

What we're going to build & how: A single feed that aggregates all incoming maintenance requests — phone calls, portal tickets, office-created jobs — into one prioritized queue. Dispatchers can triage, assign, and schedule from this view without switching systems. How it works: The queue merges all sources into one list, ordered by priority. Tickets are pulled from Rent Manager's service-issue records — where ManageGo portal requests already sync — alongside phone logs and manual entries, and the office or dispatcher converts each ticket into a dispatch job in one click. (With the Tenant Ticketing & Messaging build selected, tenant tickets reach this queue after the office has handled the tenant conversation there.) Data stays in Rent Manager.

Tools: Rent Manager API (ServiceManagerIssues), phone system, ManageGo, web dashboard.

The headache it kills: Currently requests come in via phone, WhatsApp, and ManageGo, scattered across channels. This brings them into one place.

What's the process now: A VA manually reviews 14 photo job logs every day to find receipts and match them against credit card charges — several hours of tedious work. Receipts with no job behind them — tools, stock, bulk buys, the ops lead's own purchases — travel over WhatsApp and are matched by hand.

What we're going to build & how: A dedicated receipt upload box on each job, plus a no-job receipt path on both the tech and admin apps for purchases that don't belong to a work order. Every no-job receipt lands in an office review queue with three routings: mark it a general expense with a GL account (written back to Rent Manager, with an approval step), assign it to a building, or match it to a specific work order. The office can also enter internal material invoices — stock used on a job with no supplier or card transaction behind it — so the building is still charged what it cost. The system pulls posted Capital One transactions (via QuickBooks or bank feed) and matches receipts to them using AI. Missing receipts are flagged on a daily report. Matching runs on a 1–2 day posting delay. How it works: Techs photograph receipts on the job; the app queues photos and uploads them when signal returns. The AI reads the amount and vendor, then matches against transactions. The daily report highlights any receipt without a match. Data lives in Rent Manager alongside the job.

Tools: Rent Manager, QuickBooks (or Capital One feed), AI matching, mobile app photo upload, office review queue.

The headache it kills: VA manually reviews 14 photo job logs to find receipts, and no-job receipts travel over WhatsApp. This automates the match, routes every receipt — job or not — to the right place, and alerts same-day if a receipt is missing.

What's the process now: There is no systematic reporting — decisions are memory-based. The team doesn't easily see that a tenant has refused access three times or that the same stove was serviced twice.

What we're going to build & how: A reporting layer over dispatch data: daily, weekly, monthly summaries, repeat-issue alerts (same unit/issue third time), tenant no-access reports, job completion metrics, and budget tracking. Includes an on-demand per-building repair report: every work order for a chosen date range compiled into a single PDF, ready to drop into the monthly owner reports. Alerts appear on the dashboard and optionally by email. How it works: Reports generate automatically from time entries and job statuses. The system flags patterns like repeated access refusals or the same issue recurring, so the team can act before a small problem becomes a big one. Data stays in Rent Manager.

Tools: Rent Manager API, reporting engine, dashboard.

The headache it kills: No systematic way to know a tenant has refused access three times, or that the same stove was serviced twice. Decisions are memory-based.

What's the process now: Tenant maintenance tickets are filed in ManageGo, where the office replies and the tenant receives an email. None of it reaches Rent Manager — ManageGo has declined to build an integration — so the ticket, the conversation and the resolution live in a system the rest of the operation cannot see. Tickets that do reach Rent Manager go straight to the field manager, with no office step in between and no way to talk to the tenant from inside the app.

What this replaces, precisely: ManageGo is five products — Payments, Maintenance, Concierge, Leasing, and Books & Accounting. This build replaces the ticketing and tenant-communication workflow of the Maintenance product, and only that. Rent collection, package and amenity handling, leasing and screening, and the accounting ledger are NOT part of it and are not affected by it; a tenant-facing app covering payments, leases and balances is a separate future quote.

Six features of the Maintenance product are deliberately NOT included, at the client's direction: ticket templates, per-type checklists, recurring tickets, automatic assignment rules, unit status shown on the ticket, and saved replies. They were offered, priced, and declined as unnecessary. They are named here so there is no question at acceptance about what was bought.

What we're going to build & how: A Messaging surface holding every tenant ticket and its whole conversation, matched to what the Maintenance product does today:
• Tickets carry subject, description, property, unit or common area, category and priority, and can be raised from the office, from the maintenance director's phone, or in the field — as well as arriving automatically from Rent Manager.
• Category-driven notification routing — administrative and leasing matters to the office, physical repairs to the crews — delivered by email and as a phone notification, so nothing depends on someone forwarding a message.
• Per-user notification preferences, so each person chooses what they are told about.

Talking to the tenant: the office replies from inside the ticket, and the tenant receives it as an email. When the tenant replies to that email it returns into the same ticket thread automatically, and the whole exchange is kept against the ticket. Who may write to the tenant follows the ticket's own progress — the office from the moment it arrives, the maintenance director once it becomes a job, and the assigned technician once it reaches him. Every message records which member of the team sent it, so the internal history is never ambiguous. A scheduled run keeps tenant email addresses current from Rent Manager so the loop never fails for want of an address. Once the office is finished, the ticket converts into a dispatch job.

How it works: Outbound replies send from a dedicated maintenance address on a client-controlled domain. Inbound replies are matched to their ticket by mail headers first, then by a per-ticket reply address, with a 'reply above this line' marker as the last resort; quoted history is stripped so threads stay readable. Messages, status changes and notes are queued and written back to Rent Manager's service-issue and history-note records in batches, staying inside the API's hourly budget — which is what puts the ticket's whole life in the system of record, and is the thing the current tool cannot do at all.

Tools: Rent Manager API (ServiceManagerIssues, HistoryNotes), transactional email with inbound parse webhook, push notifications, web dashboard, category-based routing.

The headache it kills: Tenant tickets and every conversation about them are trapped in a system that will not talk to Rent Manager. This rebuilds that product on the Rent Manager spine, so the ticket, the thread and the resolution all live where the rest of the operation can see them.

What's the process now: Compliance and inspection work — city inspections, agency filings, insurance recommendations and violations — is run by a separate crew on a shared Google calendar the office keeps by hand. It is booked a month ahead, it has nothing to do with day-to-day maintenance, and it sits outside every system the maintenance side uses.

What we're going to build & how: The same platform, taught to run two departments side by side. When a ticket is opened, whoever opens it says whether it belongs to maintenance or to field, and it is routed accordingly. Field work skips dispatch entirely: the office schedules it straight onto a calendar, because that department is booked weeks out rather than triaged the same day. The field crew work from the same application the maintenance crew use — the identical app, scoped to their department, at no additional charge — seeing only their own jobs and capturing photos on site exactly as maintenance does. Management gets one combined view across both departments plus a view of each on its own, and a switch that shows the crew belonging to whichever department is selected.

How it works: Department is carried on every ticket, job, user and crew record, and every list, board and filter respects it, so the two sides never bleed into one another while sharing one system. The field calendar runs a month-ahead horizon with filters by crew and by work type. Field scheduling lives in the platform; it is not written back to the property system, which the client has confirmed is not required.

Tools: shared platform infrastructure, department routing, month-ahead calendar with filters, existing crew mobile app.

The headache it kills: Compliance and inspection work is tracked on a hand-kept Google calendar with no connection to anything else. This brings it onto the same platform as maintenance without the two getting tangled.