How to use a CRM in property management
Landlords, tenants, guests and contractors need different things from you. A useful CRM keeps those relationships clear and makes the next action easy to find.
Read the guideWhat belongs in a property management CRM?
Imagine a colleague taking over a heating repair while you are away. They can find the tenant’s name, but not the agreed visit, the owner’s authorisation or the promise you made that morning. The CRM has names and numbers but does not help them continue the job.
This guide explains how to organise the people and work around a property, from the first enquiry to the end of a tenancy or instruction. It covers residential lettings and short stays. The examples are fictional and the software references describe documented capabilities, not a ranking or a paid endorsement.
A contact is a person, not a stage
CRM stands for customer relationship management. In property management, that includes people who are not customers in the usual sales sense. A tenant needs a repair, an owner wants a statement explained and an engineer needs an agreed appointment. The record should help the next colleague understand that relationship and carry out the next action.
A person can own several properties, rent another home and work for a supplier. Keep their identity separate from each role. The role belongs to a particular relationship, with its own dates and context. Moving an application to referencing should not permanently turn the person into a referencing stage.
Use a stable record identifier. Names change, people share email addresses and a company may use one mailbox for several staff. Search for possible matches before creating or merging records. A shared email address is a reason to investigate, not permission to combine two people.
The property and the agreement need their own history
The property record describes the home. A tenancy or booking describes a particular agreement involving that home and particular people. If you overwrite the previous tenant whenever somebody moves in, the repair, deposit and correspondence history becomes impossible to interpret.
Link each joint landlord and each tenant separately. A guarantor needs a guarantor relationship to the relevant agreement, not a tenant label. For a company let, distinguish the contracting company, its contact, the person staying and the party paying. They may be different.
Do not assume a CRM replaces your tenancy, booking, accounting or compliance software. Decide which system maintains each operational record and how the CRM refers to it. A reference to the current booking is useful. An independently edited copy of its dates can become an expensive mistake.
A task should say what happens next
A note records what happened. A task commits somebody to an action. A work order records the repair itself. They are connected, but they do different jobs. “Chased contractor” is a weak note and an even weaker plan. “Confirm whether the engineer can attend tomorrow, then tell the tenant by 4pm” gives a colleague something they can finish.
Link that task to the repair and the conversation that created the promise. Give it a responsible person and a due time. Record what counts as completion. Sending a message may finish a sending task; it does not prove the engineer accepted the job or the tenant agreed to access.
A contact edit, email open or task tick is not evidence of a useful conversation. Keep the actual outcome visible. Someone covering an absence should be able to find the commitment without reading every message in the account.
One person can have several relationships with you
Alex owns Sample Home A and works for the company maintaining Sample Home B. Keep one person record, a separate company and separate property records. Alex’s owner correspondence does not belong in the other property’s repair history.
The same principle applies to a landlord who rents another home, a guest who later becomes an owner, or a company with several employees arranging stays. Let the relevant property, agreement and work carry their own history. Do not grant additional access just because a person has another role.
What to record throughout each relationship
Choose the people you work with to explore the records, decisions and handovers they need. Every example continues beyond the initial enquiry.
Follow the instruction and the owner relationship separately
A landlord enquiry is a possible instruction. Once the property is under management, the relationship becomes an ongoing service responsibility. Keeping every owner in a permanent sales pipeline obscures that change.
Enquiry and property discussion
Record how the enquiry arrived, which property it concerns, the owner’s objective and the agreed next action. Qualify the actual opportunity: suitability, timing, decision makers and whether the owner wants residential, short stay or flexible management. An existing owner asking about another home creates another opportunity, not another person.
Proposal and onboarding
Keep the proposal, agreed service, required handover documents and unresolved questions against the instruction. Identify joint owners and any authorised company representative. Agree who receives statements and who may instruct work. A nominated correspondence contact is not automatically the only person entitled to make decisions.
Active management
Use the relationship record for service preferences, property links, promised updates and open issues. Put a statement question against the relevant period. Put a repair authorisation against the work. The owner’s record should tell a colleague what needs attention, not just when the contact was last edited.
Change, renewal and departure
A new property, change of ownership or different service needs its own dated record. At departure, assign the final statement, document handover and any unresolved claim. End the active relationship and review access. Keep only the records your documented purposes require; do not delete unresolved financial or complaint evidence just to tidy the pipeline.
Try this case in your CRM
Two joint owners share a mailbox. Keep two people linked to the property and the agreed instruction arrangements. A request to change the payment destination goes through your verification procedure, even if it arrives in an existing conversation.
Keep the application distinct from the tenancy
An applicant can enquire about several homes, apply jointly and later become a tenant. Their search, application and tenancy each need their own context. A sales stage on the contact cannot reliably describe all three.
Search and viewing
Record the requirements the applicant gave you, the homes discussed, the viewing arrangement and its actual outcome. Do not manufacture an appointment from an email open. When somebody withdraws, record the reason they supplied rather than a speculative judgement about their finances or behaviour.
Application and agreed tenancy
Link every applicant to the application and the proposed agreement. Keep referencing and identity documents in appropriately restricted records, rather than general contact notes. Record a guarantor separately and connect them to the relevant obligation. Once the tenancy starts, stop inappropriate prospect messages.
Living in the property
Associate repairs, access arrangements, payment queries and complaints with the current tenancy and property. A household may have several occupants, but an individual’s private circumstances do not belong in a shared household message. Check the agreed recipients before discussing a sensitive issue.
Notice and the end of the tenancy
Track the agreed departure arrangements, inspection, outstanding issues and next contact. Ending occupation does not automatically settle the deposit or a complaint. Close the active tenancy when the underlying records support it, then apply the relevant retention and access rules.
Try this case in your CRM
An engineer finds no answer at the property. Record the attendance time, the booking messages and the tenant’s account. “Tenant refused access” is not an established fact if nobody confirmed the appointment.
Use the current booking to guide the conversation
The guest, booking organiser, company paying and people staying may not be the same. A repeat stay should add another booking relationship while preserving the person’s identity and current communication preferences.
Enquiry and reservation
Connect the conversation to the actual booking, property and booking channel. Distinguish a question from a confirmed reservation. If a company arranges accommodation for an employee, record who may change the booking and which information each party needs. Do not send the traveller’s private conversation to the company by default.
Before arrival
Use the confirmed dates, current property instructions and permitted channel. An old stay must not supply an old door code or an incorrect arrival time. Record questions that require a real answer, such as an access arrangement, instead of relying on a generic scheduled message to resolve them.
During the stay
Attach a reported issue to that stay and property. Separate the guest’s report, the team’s checks, the action taken and any outstanding promise. A colleague covering the evening should see whether the heating problem was investigated and what the guest was told, not just a contact tagged unhappy.
After departure and another stay
Resolve outstanding service issues and record the actual outcome. Keep any review request appropriate to the booking channel and its rules. A future reservation is a new booking. Being a previous guest does not by itself permit promotional email, sharing their details or carrying old access permissions forward.
Try this case in your CRM
A guest returns six months later. Keep the earlier stay in history, but check the new property, booking organiser and arrival details. Reusing the person record should not reuse an old booking instruction.
Separate the supplier from the person attending
A maintenance business may send different engineers to different properties. The company record holds the supplier relationship; the named engineer holds the contact identity. Neither should become the sole location of the work order.
Supplier setup
Record the services offered, coverage, current point of contact and the documents your supplier process requires. Give document checks an owner and review date. A file uploaded to the CRM is not proof that it was checked or remains current. Keep bank details and verification evidence appropriately restricted.
Job assignment and access
The work order needs the property, reported fault, agreed scope, authorisation and access arrangements. Record who accepted the job and which engineer will attend. Share the information needed for the visit. A contractor does not need the tenant’s referencing report or the owner’s portfolio finances.
Attendance and evidence
Record what was checked, what was done, any change to the scope and the evidence supplied. If another visit or approval is needed, create the next action before closing the task. Keep a quote, an attendance report and an invoice distinct; they describe different events.
Verification and the ongoing relationship
Check completion against the agreed work and any remaining occupant report. Record unresolved issues before accepting closure. Payment follows your accounting and authorisation process, not a contact label. Review recurring missed appointments or poor evidence using specific jobs rather than unsupported personal notes.
Try this case in your CRM
The company sends a replacement engineer. Update the attendance contact and access arrangement on the work order. Keep the supplier company, original instruction and approval history intact.
Give each additional relationship a clear purpose
A CRM may also contain staff, guarantors, referring agents, professional advisers and neighbours. Including someone does not mean giving them access, adding them to marketing or collecting their full personal history.
Referrals and professional contacts
Connect the referring person and agency to the particular instruction opportunity, together with any agreed referral arrangement. A permanent referral source on the landlord can incorrectly credit every future instruction. Sharing the full owner record is not a necessary consequence of recording a referral.
Guarantors and other agreement parties
Link the person to the relevant agreement and role. Keep the scope and dates understandable. A guarantor is not an occupant, and a correspondence contact is not automatically authorised to act for the contracting party. Your agreement and verification procedure determine the arrangement.
Staff and cover
Connect colleagues to assigned work and necessary operational contacts. Keep HR and sensitive employee information in appropriately restricted systems. A staff label on a contact should not grant a login. When someone leaves, reassign open promises and revoke their actual account and integration access.
Neighbours and incidental contacts
Record the issue and the minimum contact information needed to respond. A noise complaint should show what was reported, what was checked and what happened next. It is not a reason to build a speculative profile of the neighbour or reveal a guest’s booking details.
Try this case in your CRM
An agent introduces one owner for one property. Attach the introduction to that opportunity. If the same owner later brings another home directly, preserve its actual source rather than copying the earlier referral.
Follow a heating repair through the CRM
Here is the same fictional repair at four points. The tenant, owner and contractor receive different information. The responsible manager can see the whole job, including the outstanding promise.
Monday, 9.10am
The tenant reports that the heating is not working
Tenant
The issue has been recorded. The manager will confirm the next step by 11am.
Owner
The reported fault and the manager’s initial checks are recorded against the property. Any required spending authorisation remains open.
Contractor
No job has been assigned yet. The tenant’s report does not grant access to the home.
The manager’s next action
Sam will check the reported symptoms and agreed repair arrangements, then update the tenant by 11am.
The original message and report time are linked to the repair. The cause is not yet established.
Monday, 10.35am
The visit is agreed and the engineer accepts the work
Tenant
The agreed visit is Tuesday between 10am and noon. The tenant has confirmed the access arrangement.
Owner
The agreed scope and authorisation are recorded. The owner receives the update required by the management arrangement.
Contractor
The engineer receives the address, fault description, agreed scope and current access arrangement. Referencing and financial records are not shared.
The manager’s next action
Sam will confirm attendance on Tuesday and keep the tenant informed if the appointment changes.
The tenant’s access confirmation and the supplier’s acceptance are recorded separately. Sending the work order was not enough.
Tuesday, 11.20am
The engineer reports a replaced heating timer
Tenant
The engineer says the heating was tested. The manager asks the tenant to report whether the issue persists.
Owner
The attendance report describes the fault found and the completed work. The invoice remains subject to the usual checks.
Contractor
The engineer supplies the attendance record and work evidence. Any further work requires a new agreed action.
The manager’s next action
Sam will review the report and check the reported result with the tenant before closing the repair.
An invoice alone would not establish that the heating worked. The attendance report and the remaining service question are visible.
Wednesday, 9.30am
The work has been checked and the tenant confirms the heating works
Tenant
The tenant’s confirmation is recorded. The repair can now be closed with a clear explanation of what was done.
Owner
The completed work, checked cost and outcome remain available against this repair and property.
Contractor
The verified completion is recorded. Payment follows the accounting process; closure is not a claim that payment has already occurred.
The manager’s next action
Sam records the confirmation, closes this repair and leaves any separate accounting action with its responsible person.
The record now contains the reported issue, accepted visit, work evidence and verified outcome. Another colleague can understand why it was closed.
Real repairs do not always follow this tidy sequence. An engineer can decline, a visit can fail or the first fix can leave the fault unresolved. Keep the actual state and create the next action. Do not move the repair to completed because the diagram has reached its last step.
How to set up a CRM for your property management business
Start with a process the team can carry out reliably. The software should make that work easier to record, find and continue. Importing every old contact and switching on every automation is not a substitute for deciding who is responsible.
Start with a real handover
Choose a recent owner enquiry, a tenancy issue and a contractor job. Reconstruct each with the colleague who handled it. Find where the relationship became unclear, where a promise disappeared or where the same fact had to be copied into several tools. Those are more useful starting points than a large catalogue of fields.
Agree what the next colleague must be able to discover. For the heating repair, that means the report, current access agreement, assigned supplier, spending authority, responsible manager and next update. Ask the supplier to demonstrate those facts in the proposed CRM before buying it.
Decide which records describe which things
Define the person, company, property and agreement separately. Then decide how an instruction opportunity, repair and task attach to them. Give relationships a role and dates where the system supports them. If your software cannot represent joint landlords or repeated bookings cleanly, find that limitation before importing thousands of contacts.
Avoid a mandatory field just because it exists in the software. A general next action needs a responsible person, due time and related work. A marketing preference needs its channel and evidence. A supplier record needs the facts your purchasing process uses. Tenants and guests should not be forced to provide information that serves no relevant purpose.
Separate a field’s meaning from who may see or change it. A contractor tag describes a role. It should not expose every contractor conversation to every supplier. Decide who may change payment details, approve expenditure, merge people and export records, then test the actual account permissions.
Clean a small sample before the full import
Keep the original export securely and work on a copy. Preserve stable identifiers and the source of each record. Normalise obvious formatting differences, but investigate possible duplicates before merging them. Two people sharing one address or mailbox may be joint owners, a household or a supplier team.
Trial a mixed sample with a joint ownership, a joint tenancy, a repeat guest, a supplier employee and an open complaint. Import relationships as well as people. Reconcile the resulting count and read the actual records. A successful import notification does not establish that dates, attachments or assignments survived.
Check notes and files separately. Some CRM exports separate them from contacts and opportunities. Pipedrive’s export documentation, for example, describes separate exports for activities, notes and files, with limitations for externally stored files. Understand the export path before relying on it for a handover.
Test access as the person who will use it
Use test accounts for a manager, cover colleague and any portal users. Open the same repair as each person. Try an older tenancy and a different owner’s property. Check search results, notifications, file links and exports, not just the main contact screen. A hidden tab is not a security boundary if its documents remain accessible elsewhere.
Reassign an open task and remove a departing employee’s actual access. Check what happens to their conversations and promised updates. Test a contractor replacement and the end of a tenancy. Relationships change; permissions must follow the change rather than remain attached to an old label.
Introduce automation only after the manual case works
Begin with internal reminders that have an obvious owner and recovery path. Check what happens if the booking dates change, the engineer declines, the landlord has already replied or the contact has opted out. Avoid an automated customer message until its trigger, recipient, content and exception handling have been tested.
Replayed imports and duplicate events must not send the same message again. A failed integration needs a visible exception and somebody responsible for it. If staff are working around an unreliable sync, document that reality and fix the workflow before expanding it. Our guide to property management automation covers the wider tradeoffs.
Practise the difficult cases before the switch
Train the team by doing the work, not just touring the interface. Ask a cover colleague to continue the unresolved repair from its record. Ask another colleague to deal with two landlords who have different correspondence arrangements. Test a withdrawn application, a repeated stay and a correction to an inaccurate note.
Agree the cutover date and where staff should record new work. Keep a controlled way to retrieve necessary historical records. Check an export and recovery procedure before retiring the old system. Set a review after the first working period to correct fields and reminders that staff cannot use consistently.
A starter record for your trial
This fictional example describes a repair, not a complete CRM configuration.
{
"example": "Fictional repair record for a CRM trial",
"property_reference": "Sample Home B",
"tenancy_reference": "Sample tenancy B",
"reported_issue": "Heating is not working",
"status": "Visit agreed",
"supplier_company": "Sample Heating Company",
"attending_contact": "Taylor, engineer",
"access": {
"arrangement": "Tenant confirmed the visit",
"confirmed_at": "Tuesday, 9am"
},
"scope": "Inspect the reported fault within the agreed authorisation",
"next_action": {
"responsible": "Sam, property manager",
"action": "Confirm attendance and update the tenant",
"due": "Tuesday, noon"
},
"completion": {
"required_evidence": "Attendance report and checked repair outcome",
"verified": false
}
}Copy the example into a supplier demonstration or use it to agree the fields your team actually needs. Change the names, dates and responsibilities to suit the test. Do not paste genuine tenant, guest or identity information into an unsecured trial account.
Examples of CRMs used around property management
These products illustrate different approaches. There is no universal winner: the right choice depends on the work, permissions, integrations and export you can demonstrate in the plan you will actually buy. The linked official documentation was checked on 7 October 2026. Features and plans can change.
HubSpot
HubSpot illustrates a configurable CRM organised around records and their associations. Its documentation describes contacts, companies, tasks and tickets. That can be useful for an owner enquiry and service workflow, provided you establish where property, tenancy and booking records belong.
Its documented custom objects require an Enterprise subscription. Do not buy a lower plan on the assumption that every property model you imagine will be available. Demonstrate the actual permissions, associations and required integrations in the proposed plan.
Pipedrive
Pipedrive illustrates a sales CRM with people, organisations, activities and deals. An owner can have several instruction opportunities. That is a sensible use of a deal pipeline; treating every tenant issue as a deal usually is not.
The documented primary contact associations on a deal have limits. Test joint owners and company representatives rather than assuming labels solve the relationship. Also check how the operational system will carry the tenancy, repair and booking once an instruction is won.
Reapit
Reapit’s lettings documentation distinguishes applicant, landlord and property records, including joint landlords, tenancy progression and works orders. That makes it a relevant example of software built around agency operations rather than only a general sales pipeline.
Ask for the full workflow in the products and integrations you are considering. A documented feature is not a guarantee that the particular subscription, migration or configuration will cover your process.
Arthur
Arthur’s documentation describes separate manager, tenant, contractor and owner user groups with different portal functions. This is useful when evaluating who needs to report an issue, accept work, view a statement or approve a quote.
Test those roles with your sample property and restricted documents. Check the available plan and how accounting, messages and contact history connect. Different portals are helpful only if the underlying work remains understandable to the team.
Run the same sample through each serious candidate. Ask a colleague to continue the repair, view the joint ownership, find the guarantor and arrange the repeated booking. Then test the restricted account and export. The answers are more useful than a supplier saying that everything is customisable.
Permissions, personal data and marketing preferences
Keep enough information for the job
For a UK operation, decide the purpose and lawful basis for processing the information you keep. Do not treat consent as a universal answer for every operational record. Your privacy information should reflect your actual purposes, recipients and retention arrangements, including contact information received through a referring agent.
The ICO’s data minimisation guidance calls for relevant information limited to what is necessary. A generally visible contact note is not a sensible home for a complete referencing report, identity document or medical history. A staff member should be able to handle the relationship without seeing unrelated sensitive material.
Write notes that distinguish facts from opinions
Record the source, date and substance of a relevant event. “Tenant is difficult” is an opinion with little operational value. “Tenant says the appointment was not agreed; manager to check the booking messages” identifies the disputed fact and the next action. A colleague can work from it without inheriting an unsupported conclusion.
Corrections should make the current record accurate while preserving an understandable history where appropriate. Do not silently turn an allegation into a fact or retain an obsolete instruction as though it were current. See the ICO’s accuracy guidance.
Keep service messages separate from marketing
A message about tomorrow’s repair serves a different purpose from an offer of another service. Adding promotional content can change how the message is treated. A contact’s landlord, tenant or guest role is not marketing permission. The ICO distinguishes service messages and marketing.
For electronic marketing, understand the rules for the recipient and channel. Individual subscribers, including sole traders in the relevant context, are not treated like limited companies. Where consent or a soft opt in is relied on, keep evidence that the applicable conditions were met. Record the channel, date and collection wording, and make objections reach every sending tool and later import. Read the ICO’s electronic mail guidance.
Booking channels also have their own rules. Airbnb’s off platform policy restricts taking current or future bookings off platform and collecting contact details for marketing. Copying a guest into a CRM does not remove those restrictions. Our direct booking guide explains the distinction between your own permitted acquisition and an existing platform booking.
Use retention rules that match the record
There is no universal UK GDPR retention period for every CRM record. Define the purpose, the event that starts the period, the review date and the eventual deletion or anonymisation action. An unsuccessful enquiry, active tenancy, completed repair and unresolved complaint may need different treatment. Archiving is not deletion.
Restrict export and document access to the people who need it. Review actual accounts when staff or suppliers leave. The ICO’s storage limitation, privacy information and practical security guidance are useful starting points. Some ICO guidance is under review following legislative changes. Check the current guidance and seek appropriate advice for your circumstances; this article is not a legal retention schedule.
How to tell whether the CRM is helping
Judge the CRM by whether people can act on it and whether the records reflect the work. Contact counts and a full activity feed do not tell you that a landlord received the promised update.
Can a colleague keep the promise?
Take an unresolved case and ask someone who was not involved to continue it. They should find what happened, who is responsible and what was promised next. Count overdue commitments using the actual due time. A busy activity feed can conceal a service failure if nobody owns the outstanding action.
Does completion mean the work was done?
Sample closed repairs and completed onboarding records. Look for the evidence your process requires and a recorded outcome. Distinguish an accepted instruction, confirmed visit, completed repair and paid invoice. If staff close tasks to clear reminders while the work continues elsewhere, the figures are not measuring the service.
Where did the enquiry become a client?
For owner acquisition, keep received enquiries, qualified opportunities, proposals and won instructions distinct. A page visit, download or tracking event is not a received enquiry. Record the actual decision and property instruction. Attribute a referral or campaign to that opportunity rather than permanently crediting every future property from the same owner.
What happens when the software is wrong?
Review duplicate records, failed integrations, unassigned work and access mistakes. Check whether opt outs survive imports and whether current booking details reach the right message. Use the findings to repair the process. More fields, reminders or automation will not correct an unclear responsibility.
A note that leaves work behind
“Chased contractor.”
A next action someone can carry out
“Sam will confirm whether the engineer can attend tomorrow, then tell the tenant by 4pm. The repair and booking messages are linked.”
How the CRM fits into Upgraded OS
Upgraded OS is software from our wider business, so this is not an independent recommendation. Its existing CRM keeps contact roles, property links and related work beside conversations. You can record notes, link the task behind a promise and keep internal discussion separate from the customer reply.
A contact can have several roles, and a business can have people associated with it. The CRM’s contact activity records edits; an edit is not proof that a customer conversation took place. The useful test is still whether a colleague can understand the relationship and continue the work.
Access is currently limited. Read the Upgraded OS Inbox explanation or ask the team about fit and access. Check the required workflows and available integrations for your operation rather than assuming every example in this guide is supplied as a ready made feature.
Common questions about property management CRMs
What is the difference between a CRM and property management software?
A CRM organises people, relationships, conversations and the work arising from them. Property management software may maintain tenancies, bookings, accounting, maintenance and compliance records. Some products combine these jobs. Check the actual record model and integrations rather than assuming the CRM label means every operational function is included.
Should landlords, tenants and contractors share one CRM?
They can share one contact system when their roles and relationships remain distinct and access is properly restricted. Sharing a system does not mean sharing every note or document. A contractor should see the information needed for the assigned job, not the tenant’s referencing file or the owner’s unrelated finances.
Should I create a new contact for each property or booking?
Usually the person should keep one identity while separate properties, agreements and bookings carry their own records. Investigate possible duplicates carefully: shared names, addresses or email accounts do not prove two records describe one person. A repeat guest needs a new booking relationship, not a replacement of the previous stay.
Can I use a spreadsheet before buying a CRM?
A controlled spreadsheet can help a small team define its records and test a sample. Be honest about access control, simultaneous editing, reminders, relationship links and file security. If colleagues cannot identify the current record or continue an unresolved case safely, the spreadsheet is not solving the operational problem.
Can I send marketing to everyone in the CRM?
No. An operational relationship is not blanket marketing permission. The lawful basis, electronic marketing rules, recipient type, channel preferences and booking platform terms matter. Record the relevant evidence and make opt outs reach every sending tool. Keep necessary service messages distinct from promotion.
Which CRM is best for a property management business?
Test the systems against the work your business actually does. Use a joint ownership, a tenancy with a guarantor, a repeated booking and a contractor repair. Ask the supplier to show the relationships, permissions, handover, export and recovery in the proposed plan. A sales CRM may suit instruction enquiries while needing a separate operational system.
Start with the next unresolved job
Open the next owner question, tenancy issue or guest repair waiting for attention. Can another colleague establish what happened and keep the promise you made? Fix that record and its handover first. It gives you a practical standard to use when choosing, configuring and reviewing the rest of the CRM.
If you are preparing to run a management business, our management company startup guide covers the broader operating decisions. If you are comparing the work a manager takes on, read what property management services cover.