Privacy Notice

1. Who we are

Mendlet is operated by Mendlet Ltd, registered in England and Wales under company number [COMPANY NUMBER — fill in on incorporation], registered office [REGISTERED OFFICE ADDRESS — fill in on incorporation]. For anything about personal data, write to info@mendlet.com.

2. Two roles: controller and processor

Data protection law distinguishes the organisation that decides why and how personal data is used (the controller) from one that handles it on that organisation's instructions (the processor). Mendlet is both, for different data.

Where we are the processor, the customer's own privacy notice tells you the full story, and section 4 below explains how to reach them. The contract that binds us to handle your data properly on their behalf is Schedule 1 of our Terms of Service.

3. What we collect and why

3.1 If you visit the website

Our web pages are served by Cloudflare, which keeps standard server logs (IP address, browser, page requested, time) for security and to keep the service running. We do not run analytics, advertising or social-media scripts, and our pages load no fonts from anyone else: they use the fonts already on your device.

Lawful basis: our legitimate interest in running a secure website.

3.2 If you use the contact form

We collect what you type — your name, email address, company, phone number, portfolio size, the topic you chose and your message — together with the page you sent it from, your browser’s description of itself and the IP address it came from, and we email it to ourselves so we can reply. When we answer and you reply to our email, your reply is stored with your message, so the whole conversation is in one place. The copy the service stores, replies included, is deleted automatically after 12 months (section 7); the email in our inbox is kept for as long as the conversation is live and for up to two years afterwards.

Lawful basis: our legitimate interest in answering enquiries, and taking steps at your request before entering a contract.

3.3 If you are a customer

To create and run your account we hold your company name, the names and email addresses of your office users, hashed passwords, sign-in sessions, your settings, your billing and usage records, support correspondence, and an audit log of significant actions taken in your account (who did what, when, and the IP address the action was taken from — the address itself, not a hash of it; for a sign-in, also the network number of your internet provider and the country, as Cloudflare reports them). Your settings include which days your office is closed (a choice of bank-holiday nation and other calendars, and dates you add) and monthly counts of problems tenants fixed themselves from the tenant portal’s “try this first” steps, in total and by kind of problem; none of this holds anything about a person. When your company signs up we also keep a record that you accepted our Terms: which version, when, and the IP address the acceptance came from, so that either of us can show what was agreed; it is kept for as long as the account exists and destroyed with it. When our Terms change materially, we email your company’s owner and the product tells them the next time they sign in; we keep the day that notice was given, and from 30 days after it your owner is asked to accept the new version to carry on. That acceptance replaces the record on the account with the new version, the time and the IP address, and your activity log records who accepted which version. We use this to provide the service, to bill you, to secure your account, to support you, and to tell you about changes to the service that affect you. We do not send marketing email unless you have asked for it, and you can stop it at any time.

Lawful basis: performance of our contract with you; our legitimate interests in security, fraud prevention and improving the service; and legal obligation for tax and accounting records.

3.4 Address search and maps (Google)

Address search and maps in the office app are provided by Google. We use Google so that an office can find a property’s address quickly and spell it the way the post does, confirm on a map that it is the right building, and give a contractor directions to the door. What goes to Google is only the address an office user types into the address box — never a tenant’s name, phone number or email address, never a tenancy, and never anything from a repair report. It reaches Google in these ways:

• Suggestions and the confirm map. As the office user types, their browser asks Google for matching addresses, and after one is picked it shows a small Google map to confirm the building. Both come from Google to that user’s browser, so their IP address reaches Google too.
• One look-up on Save. If an address is saved without picking a suggestion, our servers ask Google once, with our own key, to find the building for that address and postcode. There is no per-customer key and no arrangement between a customer and Google.
• Maps and directions for contractors. A contractor who opens a job’s map loads it from Google in their own browser. “Directions” is a link that opens Google Maps on the device of whoever presses it; we send Google nothing about that person.
• Planning a contractor’s day. When a contractor presses Plan my day in their portal, our servers send Google the locations of that day’s jobs (the office’s own pin, Google’s reference for the building, or the address), how long each visit should take and its appointment time, and the place the contractor chose to start and finish from. Google works out the order and the driving times, and My Day can show the route on a Google map in the contractor’s own browser. Nothing else goes: no name, phone number or email address, no job description and nothing from a repair report. Places a contractor saves (such as “Home”) are kept on their own phone, not by us, until they sign out, and their office never sees them; “Use where I am now” is used once, for that plan, and not kept. We keep none of the routes Google works out, and no office sees a contractor’s route. Where a job’s property has neither the office’s pin nor Google’s reference, our servers look its address up with Google and keep Google’s reference and position for that address for 30 days, as Google’s terms allow — in the planner’s own store, under a one-way hash of the address, not on the property — so that it is not looked up again for every plan; the map in My Day is given that position too. A company can switch day planning off in Settings, and its jobs then go to nobody for planning: none of them is planned or sent to the route planner. If it keeps maps on, its jobs can still be shown on the map in My Day, and our servers, not the contractor’s phone, place them there (below). A company that switches maps off has none of its jobs sent to Google for planning, nor by the map in My Day on the contractor’s phone, which lists such a job beside the map without drawing it or looking it up.
• Placing a contractor’s day on the map. When a contractor shows their day on the map in My Day, where each job goes comes from our servers, not from their phone: the office’s own pin; otherwise a position our servers already keep for it (above); otherwise our servers ask Google once — by Google’s reference for the building where the job has one, otherwise by its address — counting against that company’s daily allowance of address look-ups (and a monthly limit across all our customers), and keep the position for 30 days, as Google’s terms allow, in the planner’s own store, under a one-way hash of the address or of Google’s reference, not on the property. If Google finds nothing for an address, we keep only that fact, for one day, under a one-way hash of the company and the address as written, so it is not asked again each time; changing the address, or an office user pressing “Look it up again” on the property, asks afresh. If Google no longer knows its reference for a building, we keep that fact for 30 days, under a one-way hash of the reference, and place the job by its address instead. To show a saved place the contractor starts from, our servers send Google its reference and keep nothing of the answer; the contractor’s phone keeps the position it is given for that place, and when, for up to 30 days (section 9). The phone looks no job up with Google and keeps no job’s position.
• Address suggestions for a contractor’s saved places. When a contractor types the address of a place they want to save, their phone asks Google for matching addresses, sending what they type, and their internet address reaches Google as it does for any map. If they save it without picking a suggestion, our servers look what they typed up with Google once, to find Google’s reference for it, and keep nothing. The place is kept on their phone only, as the contractor’s own name for it, the words they typed and Google’s reference for it — never Google’s address — and we do not keep it.

What we keep with a property is the address as the office confirmed it and Google’s reference for the place, never Google’s coordinates; the only positions from Google we keep are those kept for My Day’s planner and map, for 30 days, described above; a contractor’s phone keeps only the positions of the places they saved to start from, for up to 30 days. If an office user moves the map pin by hand (for example to the right entrance of a block of flats), the position they chose is stored as the office’s own mark. An address entered by hand (“Enter manually”) is not sent to Google unless an office user chooses to place a pin for it, when its town and postcode are looked up to centre the map. The tenant portal loads nothing from Google.

Google’s use of what reaches it is governed by the Google Privacy Policy, and the maps are provided under the Google Maps/Google Earth Additional Terms of Service. The address of a property is not personal data in most cases; where it identifies a person it is processed under the customer’s instructions as described in section 2.

4. Tenants and contractors

If you are a tenant using the tenant portal, or a contractor using the contractor portal, the property manager, letting agent, landlord or business that gave you access is the controller of your information. They decided to collect it and how to use it; we hold and process it on their behalf under a written contract.

What the product holds about you is what they and you have entered:

• your name and contact details, and your address or the addresses you work at;
• the repairs you have reported or been asked to do;
• messages, photographs, videos and documents, including the conversations about a visit (below);
• for each message, when the person it was written to first opened it (the ticks);
• a place, if you choose to attach where you are to a message (the product asks your device each time, and you can type a description of the place instead);
• for contractors, the qualifications and notes the customer has recorded, and the times you signed in;
• internal notes the office keeps about a property (for example, where the spare keys are), which only the office’s own team sees;
• for tenants, the six-digit sign-in codes the portal sends you, kept for ten minutes so it can check them, and a scrambled fingerprint of the sign-in button in each email we send you, kept for seven days (the button itself is not stored);
• if you turn notifications on for a device, that device’s push subscription, so it can send them;
• for contractors, what you press at the door — On my way, Arrived, Running late (and roughly how late), I cannot get in (and why) — recorded on the job’s history with the time and your name, with any words you add.

Job reports. The office can download a report of a job that includes every message about the visit — between the tenant, the contractor and the office — with who sent each one and when, as a record of what happened. The office chooses each time whether to include the messages, and decides whom it sends a report to.

Landlords asked to approve a repair. The office can send a job’s landlord a link to a page that shows that one job, so they can approve or decline it. The link needs no account, and we keep it only as a one-way fingerprint, so a copy of our database holds no working link. The page shows the job’s title and address, the office’s own words, and only what the office chose to show — the job’s description, what the tenant reported, the job’s photographs, a price. What it shows of the job is read from the job each time the page is opened, so it is not a copy made when the request was sent; the office’s words and the price are shown as they were sent. It never shows what the office’s records hold about a tenant — not who reported the repair, not the name, phone number or email address the office keeps for a tenant, and not access notes — or any message a tenant sent after their report. But when the office chooses to include what the tenant reported, the landlord sees what the tenant wrote about the repair, in their own words (in English, where they wrote in another language), and those words may include the tenant’s name or contact details if the tenant wrote them. Those words are shown only if the office ticks them, for each request, and the box starts unticked; when it is ticked, the office is shown exactly what the landlord will see before it sends the request. The request keeps which of the tenant’s reports the office chose when it sent it, and the landlord sees exactly those, never a report linked to the job afterwards. The price is the one the office enters on the request, not a figure read from a quote, and the page says whether VAT is included, added on top or not charged; the office’s note can say what the price covers, for example labour and parts. About the landlord, the product keeps the name and email address the office entered (usually from the landlord’s company record), which parts of the job the office chose to show them, the office’s words and the price, their answer and note, and when; and, with each request, a record of exactly what it sent — the job’s title, the problem as described if it was shown, the address, the price and whether VAT is in it, the quote the office had then, which of the tenant’s reports were included and the words the landlord was shown from them, which photographs were offered and whether the work had already been done — which the office can see. That record is kept as long as the request, is included when the customer exports their data and in a tenant’s own copy of their data (their words, not who the landlord was), and, when a tenant is erased, has their own words taken out of it and their full name replaced, as in other writing about their home (section 10). The customer is the controller of all of it, as for everything in their account. If there is no answer after three days the landlord is sent one reminder. A request ends when the landlord answers it, when the office withdraws it, after 14 days, or when the job is cancelled, moved to another property, or the job or its property is put in the Trash. A request still waiting for an answer is changed only by sending it again: the earlier one is withdrawn, its link says it was replaced by a newer one, and the landlord is sent a new email and link. An answered request is never changed; if something important changes, the office may ask again, which is a new request, and the earlier answer stays on the job as it was. If the job is completed while a request is waiting, the request stays open, and the page, and any email sent to the landlord after the work was done, tell them the work has already been done and that they are approving the cost afterwards. Once a request has been withdrawn, has run out or has ended with its job, its link shows nothing of the job; once it has been answered, the link shows the landlord their answer and the request, but no longer the photographs, for 30 days after the answer, and after that only whether they approved or declined and when; if the job has since moved to another property, only their answer and when. While the customer’s account is switched off, or paused because it has not been paid for, the link shows nothing of the job and takes no answer, and no reminder is sent while it is; a reminder that falls due meanwhile is held, and sent when the account comes back if the request is still open. The link works again if the account comes back.

Contractors asked to price a repair. When the office asks contractors for a price, each contractor asked sees the repair as the tenant described it: what they wrote, their messages about it and their photographs. They do not see the tenant’s contact details, access notes or door codes; only the contractor given the work sees those.

Conversations about a visit. Each visit to an occupied home has two. Each tenant can write to the office about it. The tenant who leads the household (in a house let room by room, the tenant whose own report the visit is for) and the contractor sent to the visit can write to each other while the visit is that contractor’s; a contractor sees only their own conversation, never a tenant’s messages to the office. The office can read both, and can hide a message in either, giving a reason: the tenant and the contractor stop seeing it, and the office keeps it with the reason. Contractors and the office can send documents as PDF files (a gas safety certificate, a quote); tenants send photographs and videos, not documents. A PDF is checked before it is accepted and is only ever downloaded, never opened inside the product. The person who wrote a message sees one tick when it is sent and two when the person it was written to has opened it; the office sees the time each message was first opened.

What a contractor is given. A contractor sent to an occupied home sees, on the job, the name of the tenant who leads the household and that tenant’s phone number, so they can call about access; the email that gives them the job carries the same. In a house let room by room, a visit for one tenant’s own report gives that tenant’s name and number instead, and that tenant alone is told about the visit; the other people in the house are not. No other occupant’s number is given, and if the lead tenant has no number on record, none is. Where the customer has recorded no tenancy at a property, the contractor sees the contact name and number the customer entered for it instead. Once the visit is finished or cancelled, the name and number are no longer shown. They are not given anyone’s email address. They see what was reported — the description and the photographs sent with it — and nothing a tenant wrote to the office. A contractor the customer asks for a price, before the job is given to anyone, sees the address, what was reported and its photographs, and nobody’s name or phone number. So that a contractor can work where there is no signal, the contractor portal keeps a copy of their own open jobs on their phone, including that name and number, for up to 14 days. The copy opens only with the same sign-in or job link, and it is removed as soon as the job is seen to be finished or cancelled, and all of it when they sign out.

Maps and Google. Nothing about you as a tenant — your name, phone number or email address — is ever sent to Google. The only thing that goes to Google is the address an office user types when they set up a property (section 3.4). If you are a contractor and open a job’s map or press “Directions”, your own device loads it from Google or opens Google Maps. If you plan your day, the locations of your jobs and the place you start from go to Google to work out the route, and nothing else about you does (section 3.4). Places you save stay on your phone until you sign out. If a company you work for has switched maps off, none of its jobs is sent to Google for planning, nor by the map on your phone. If it has switched only day planning off, its jobs are not planned, but they can still be shown on the map, and our servers, not your phone, place them there with Google (section 3.4).

“That fixed it.” For some problems the tenant portal shows safe steps to try before a report is written. Pressing That fixed it — no need to report files no report. The product adds one to the customer’s count for the month, in total and for that kind of problem. So that one tenancy counts a problem at most once a day, it keeps a marker made from a one-way hash of the tenancy, the problem and the date, for 36 hours; and the button is rate-limited by a counter kept against a one-way hash of the tenancy, for fifteen minutes. Neither holds a name or anything you wrote.

Free text and photographs. A repair report, a message and a photograph are whatever the person writing them chooses to say. Someone explaining why damp matters may mention a child’s asthma; a photograph of a room shows the room. The product does not ask for health information and has no field for it, but it cannot stop it being volunteered, and information like that is special category data under UK GDPR — it needs a lawful condition on top of a lawful basis. That condition is the customer’s to hold, because the customer is the controller. What we do is hold it under the same contract as everything else, keep it to the people the customer has given access, and delete it when they tell us to. If you would rather not put something in writing here, tell your agent or landlord another way.

To exercise any right over this information — to see it, correct it, have it deleted, or object to something — contact your property manager, letting agent or landlord directly. If you contact us instead, we will tell them and help them answer you, but we cannot act on their data without their instruction.

Messages. The service sends you emails and, where the customer has enabled it, text messages on the customer's behalf: appointment reminders, updates about a repair, sign-in codes. These come from Mendlet's sending address with the customer's name on them, and replies go to the customer. The service does not send marketing to tenants or contractors on anyone's behalf.

5. Who we share it with

Mendlet runs on services provided by other companies. These are our sub-processors, each engaged under a written contract that binds them to protect personal data and to use it only for us:

We never see or store a card number. Card details are entered on Stripe’s own pages and stay with Stripe; what Mendlet keeps is a reference to the customer, which plan they are on, and whether the subscription is in good standing.

One more kind of service carries data for the product without a contract with us, and we say so rather than list it alongside the ones above:

Beyond these, we disclose personal data only where the law requires it — to a court, regulator or law-enforcement body with proper authority — or, with notice to customers, to a buyer of our business who takes on these commitments. We never sell personal data and never share it for advertising.

6. Where it is processed

Our hosting provider runs a global network, and email and text messages are delivered by providers based partly in the United States. This means personal data may be processed outside the United Kingdom. Where it is, we rely on a safeguard recognised under UK GDPR: the UK's adequacy regulations where they apply (including the UK–US Data Bridge for certified organisations), or the UK International Data Transfer Agreement or Addendum. You can ask us at info@mendlet.com which safeguard applies to a particular provider.

7. How long we keep it

8. How we protect it

Every connection to Mendlet is encrypted. Each customer's data is kept apart from every other customer's, and every request is checked against the company it belongs to. Passwords are stored only as salted, iterated hashes. Sign-in attempts are rate-limited by account and by address.

Links we email are of three kinds, and the difference is deliberate. A password-reset link, an email-confirmation link and a tenant’s six-digit sign-in code are single-use and short-lived — one hour, seven days and ten minutes respectively. A contractor’s job link is different on purpose: it is a long, unguessable address that keeps working for sixty days, because asking a plumber to create an account before they can read a job is how jobs stop getting done. It opens the job it was sent for. It stops working the moment that job is handed to a different contractor, the contractor’s account is deactivated or removed, the job is deleted, the office revokes it, or sixty days pass. Anyone holding that link can see that job, which is why it is sent to the contractor and to no one else. The button in an email to a tenant — about a visit, an update on a repair, or a new message — signs that tenant in, for the same reason: typing a code into a phone is the step people give up at. It works for seven days, opens the visit or repair the email is about, and gives exactly what the six-digit code would give, no more. It stops working after seven days, or sooner if the tenant signs out everywhere, their tenancy ends, or they are erased. Anyone holding that email can sign in as that tenant until then, so it is sent only to the tenant’s own address; a tenant should not forward it. A contractor’s job and portal links, a password-reset or invitation link, an inspection or photo-gallery link, a landlord’s link, and a tenant’s seven-day button and ten-minute sign-in link carry their key after a “#” in the address, a part a browser does not send to a server, so the key is not in the addresses our hosting provider’s logs record.

And it can be exchanged for a sign-in, deliberately. A contractor reading a live job from that link can press through to their own portal without typing a password, which gives them a twelve-hour session showing the work that contractor account is entitled to see — their own jobs for the customer who sent the link, and nothing belonging to any other contractor or any other customer. It is refused if the job is finished or cancelled, if nobody is assigned, or if the contractor’s account has been switched off. We say this plainly because it is a decision rather than an oversight: a tradesperson should not need to create an account before they can be told about a repair, and the same reasoning applies to the second screen as to the first.

Access to production systems is limited to the people who run the service. We keep backups for disaster recovery. No system is perfectly secure; if we become aware of a breach affecting your data we will tell the customer without undue delay and, where the law requires, the ICO and the people affected.

9. Cookies and local storage

We do not use cookies for tracking, advertising or analytics. The product sets no cookie of its own: it uses your browser's own storage for things it needs to work, and one payment provider sets its own when you pay:

Because none of this is used to track you, no consent banner is required and we do not show one. You can clear it all with your browser's normal controls; the only effect is that you will be signed out. The office app no longer sets the cookie version 1.7 of this notice described (mendlet_office_resume): signing in or out deletes any copy a browser still holds.

10. Your rights

Under UK GDPR you have the right to ask for access to your personal data; to have it corrected; to have it erased; to restrict or object to processing; to have it moved to another provider; and, where processing is based on consent, to withdraw consent. You also have the right not to be subject to a decision based solely on automated processing that has a legal or similarly significant effect on you — the urgency the tenant portal suggests for a report is not such a decision: it is a sorting aid for the office, and a person decides what happens.

Where we are the controller (customers, website visitors, enquirers), write to info@mendlet.com. We will respond within one month, and we will not charge you unless the law allows and the request is manifestly unfounded or excessive.

Where we are the processor (tenants, contractors, landlords in a customer's account), contact the customer; section 4 explains why. If you write to us we will forward your request to them the same working day where we can.

What the product can actually do, so that neither of us is promising something that has to be done by hand.

Seeing your data. A customer can download, in one action, what their account holds about one tenant or one contractor: their details, what they reported, and the messages they wrote — in repair reports and in the conversations about a visit — with any place they attached and their photographs listed. For a tenant’s report messages it also gives when the office and the contractor opened each one. What the office and the contractor wrote to that person is quoted as their own portal showed it; what anybody else wrote — another tenant’s messages, the office’s internal notes — is listed as a message from them, not quoted, because it is their data.

Erasing a tenant. A customer can erase a tenant’s details in one action. What goes: the name, email address, phone number and access notes; the words the tenant wrote, in repair reports and in the conversations about a visit, with any place they attached; their sign-in; and the send receipts for messages sent to them. Their photographs and videos are kept with their name taken off, because a picture of a black ceiling is the landlord’s evidence as much as the tenant’s (UK GDPR Article 17(3)); the customer is shown how many there are and can choose to delete them instead. What stays: the repair history — the record that a leak was fixed at a property is the landlord’s, not the tenant’s to remove — and the replies the office and contractors wrote, word for word except that the tenant’s full name, wherever it appears in writing about their home (the office’s internal notes included), is replaced by “(former tenant)”. A first name on its own (“Thanks, Sam”) is not recognised and stays. An inspection checklist of the tenant’s home keeps its answers and the signature image; the tenant’s name in it is replaced by the word “Tenant” wherever it matches the name on the tenancy, ignoring capital letters and spaces at either end — a nickname or a misspelling is not recognised. One thing is deliberately kept: if there is a do-not-contact entry for that address or number in the account, the entry stays, holding the address, with the reason removed. Deleting it would hand the office back the ability to write to somebody who asked not to be written to, which is the opposite of what an erasure is for. It is in the table in section 7, and it goes when the account does.

Closing an account. A customer can close their account from within the product: that sets a date thirty days out, leaves the account working until then so they can export everything and change their mind, and destroys the data on the day, unless a hold (section 7) stops it. Erasures and closures are recorded, and what is recorded is that they happened and when — not another copy of what was deleted.

11. Children

Mendlet is a business service and is not directed at children. A customer must not add a person under 16 as a tenant portal user; where a household includes children, the portal user should be an adult member of the household.

12. Changes to this notice

We will update this notice when what we do changes — for example if we add a service provider. The date at the top is the date of the current version, and material changes will be announced in the product and, for customers, by email. When the version changes materially, each customer company’s owner is told by email and in the product, and is asked to accept it; a version that changes only wording is not asked for again.

13. Contact and complaints

Questions and requests: info@mendlet.com, or by post to Mendlet Ltd, [REGISTERED OFFICE ADDRESS — fill in on incorporation].

If you are unhappy with how we have handled your personal data you have the right to complain to the Information Commissioner's Office: ico.org.uk/make-a-complaint, or 0303 123 1113. We would appreciate the chance to put things right first.