Privacy policy

01 Who we are

Lanyard is made by Agent M LLC (“we”, “us”). Questions about this policy, or about the app: hello@agentm.co.uk.

02 Whose data this is really about

Most privacy policies describe data collected about you, the user. Lanyard is unusual, and being straight about it matters more than sounding tidy.

When you scan a badge or a business card at a trade show, the name, email address, phone number, job title and employer that Lanyard reads belong to the person you just met — not to you, and not to us. That person never opened this app and never saw this page.

In the language of the UK GDPR and EU GDPR: you, or the organisation exhibiting, are the data controller for the leads you capture. Your leads leave this phone only when you are signed in on a plan that includes backup, or when you tap an AI feature, Find email or Check emails that you have allowed. Photos and voice recordings never leave it. When lead data does leave it, it goes only where section 04 lists: to your backup, kept in Google’s Firestore database in Belgium and deleted when you delete your account, to Google’s Gemini for the AI requests you tap, to Hunter.io, through our server, for the work addresses you ask it to find or check (section 06), and to LinkedIn, as the search your own browser opens when you tap Find on LinkedIn.

We have not yet put a written processing agreement (the contract Article 28 describes) in place with customers. If your organisation needs one before leads are backed up or sent to an AI feature, write to us before you buy a plan that includes backup, and leave the AI features off until then: everything at the booth works without either. On a new install, before either, no lead data reaches us; what does reach us about you — including what you send by tapping Fill in from my website: your company’s website text, company name and job title — is set out in section 04.

Practically, that means it is your responsibility to have a lawful basis for capturing someone’s details, and to tell them what you will do with them — under Article 14, at your first communication with them. Lanyard helps by recording, on every capture, which event it belonged to and the legal basis you rely on for it, frozen at the moment of capture so it can be shown months later. For every new event that basis is legitimate interest (UK and EU GDPR Article 6(1)(f)), and Lanyard shows it when you create the event. Lanyard does not record consent: no screen asks the person to agree to any wording, so the app never labels anyone as having consented. An event created by an earlier version as “They said yes when I asked” keeps that record, and the CSV export marks it explicit_consent_unrecorded, because the wording that person agreed to was never recorded.

03 What Lanyard handles

The organiser’s lead list. If you open an organiser’s lead file in Lanyard, the file is read on your phone and is never uploaded or kept, and it fills in only the blanks on leads you already scanned: what it fills in is then treated like a field you typed — backed up with the lead on a plan that includes backup, and sent to an AI feature or Find email only when you tap one — each marked as from the organiser’s list.

Your account. Lanyard asks you to create an account, or to sign in to one, before you use it: you can sign in with Google, with Apple, or with an email address and a password. From Google or Apple we receive your name and your email address. If you use Apple’s “Hide My Email”, we receive an address Apple creates that forwards to yours, and we never see your real one. Google or Apple will know that you signed in to Lanyard; that is between you and them, under their own privacy policies. Having an account does not, on its own, send your leads anywhere. Backup starts when you are signed in on a plan that includes it (section 04). Leads already on your phone when you first sign in are kept, and become your account’s.

Lanyard does not read your location, your contacts, your calendar, your messages, your photo library, or any advertising identifier. It has no access to any of them.

04 Where it is stored, and what leaves the device

Everything above is stored on your device: leads in an encrypted database, photographs and audio in the app’s private storage. Other apps cannot read them.

The app contains no analytics SDK, no crash reporting, no advertising SDK and no tracker of any kind. Nothing about how you use Lanyard is reported to us. One piece of software inside it does report to its maker: the badge and card reading on the Capture screen is Google’s ML Kit, which sends Google diagnostics about itself — the twelfth item below says exactly what, and that there is no switch. And the one thing the app sends to make reading better — the shapes of scans you correct, under Help improve reading below — carries no identifier of you, your phone or your account.

Follow-up reminders, if you allow them, are scheduled on your phone and shown by your phone: no push service is involved, and nothing is sent.

Corrections teach this phone. When you correct a badge read, the phone remembers only where that show prints the name, employer and job title — a layout, never any words — so its next badges read better. That stays on this phone and is never sent. It holds no name, no employer and no character of any badge, so it is not deleted with a show’s photos and recordings: there is nothing in it about anyone.

Checking which line is which runs on your phone. On a phone with its own built-in AI model — Apple Intelligence on iPhone, Gemini Nano on Android — Lanyard asks that model which printed line of a badge or card you scanned is the name, the company and the job title. It runs entirely on your phone and sends nothing: what was read never leaves it, so no permission is asked and no plan is needed, and Lanyard never downloads the model itself. It only ever suggests — a suggestion is shown for you to take or leave, and it never changes a lead by itself.

So that a problem can still be diagnosed, the app keeps a short list of its own most recent errors on your phone: the time, which part of the app failed, and a shortened technical message with anything resembling an email address or phone number removed. It contains no lead. It goes nowhere unless you choose Settings → Support → Email support, which opens a draft in your own mail app with that list in it — you can read it, edit it, and decide whether to send it.

When a badge or a card has been read wrong, a lead’s page also offers Send this scan to support. It opens your phone’s share sheet with that one capture: the code and the printed lines the camera read, where each line sat, and the details the app saved from them. Unlike the error list, it does contain that person’s details, because the misreading is the problem. The app sends nothing itself — it goes only where you choose to send it, and nowhere if you do not.

The app sends lead data off your phone in exactly three circumstances. Your leads leave this phone only when you are signed in on a plan that includes backup, or when you tap an AI feature, Find email or Check emails that you have allowed. Photos and voice recordings never leave it. Backup starts when you are signed in on a plan that includes it: buying the plan is what starts it, and there is no separate switch. The AI briefings and drafts described in section 05 are off until you allow them, and ask the first time you tap one; so are Find email and checking an address, described in section 06. On a new install, before any of them, no lead is transmitted anywhere. Beyond them, a lead’s details leave only by your own hand: a file you export or share, a scan you send to support, an email you write, or a LinkedIn search you open (the fourth item below).

Twelve things use the network. Only the first four can carry anything about a lead:

• Backup, on a plan that includes it. When you are signed in on such a plan, leads and note text are copied to our Firestore project, so a copy exists off your phone, each stamped with an identifier this installation of the app made for itself, so the backup can tell which phone uploaded what. Any phone you sign in to with that account reads its own backup back, so your shows, leads and note text are restored on it and kept the same on each. A booth is one backup that phones on a paid plan upload into, under the account that set it up: each phone on a paid plan uploads what it captured, a phone on the free plan uploads nothing to it, and what that phone captures stays on it. Of everyone on a booth, only the account that set it up can read its backup, and its phones show all of it; a colleague who joins can add to it and cannot read anything in it, including shows backed up before they joined, so their phone shows only what it captured. Badge photographs and voice recordings are not included — there is no code path that uploads either — and Settings → Privacy tells you which state your phone is in. In a team, when a colleague assigns you a lead — and, once after a show, to its owner and admins, how many leads each person has followed up — a notification is sent through Firebase Cloud Messaging (and Apple’s push service on an iPhone): it names the lead and the show, and your phone’s push token is kept with your account until you sign out or delete it.
• AI briefings and follow-up drafts, once you allow them. Off by default. Section 05 sets out exactly what is sent, what is not, and where it goes. Two requests do not wait for that switch, and neither carries anything about a lead: Fill in from my website, which sends your company’s website text (or, if it cannot be read, the sentence you type), your company name and your job title to the same place — with contact details and the names we recognise on the page taken out, and never your own name added — only when you tap it; and the AI self-test in Settings, which sends one fixed test sentence, with nothing of yours in it, when you tap it.
• Finding a work email address, or checking one, once you allow it. Off by default. When you tap Find email on a lead (in the Android app), Check this address, or Check emails for a show, either the address read off that person’s card, or — for a badge with no address, in the Android app only — their first and last name and their employer, its website when known, go to our server and from it to Hunter.io, and nothing else about them. Section 06 sets out what comes back and what is kept.
• Links you tap. “Find on LinkedIn” opens LinkedIn’s people search in your own browser, signed in as you, with the person’s first and last name and, when known, their employer as the search: that much of a lead reaches LinkedIn, as a search you could have typed yourself. We store no profile and call no data vendor. Any other link you tap, such as a source listed under a company look-up, opens in your browser as an ordinary visit.
• Two anonymous identifiers, from the first launch. The first time the app opens with a signal, it signs in to Firebase anonymously, which creates an anonymous user ID on Google’s servers; Firebase keeps that sign-in current while the app is in use. Every launch also asks RevenueCat, our billing provider, whether this phone has a paid plan, which gives RevenueCat an anonymous customer ID and your purchase status. Neither carries a lead, your name or your email address.
• Reading your company’s website, if you ask. When you tap Fill in from my website, the phone fetches your homepage (and at most one About page) directly; that site sees an ordinary visit from your phone. A link to a page that lists people — team, leadership, careers — is never followed, even through a redirect, and sections a page marks as team or testimonials are skipped; email addresses, phone numbers and the names we recognise on the pages read are taken out before anything is sent; and no copy of any page is kept.
• The transcription model. If you choose to download it, the app fetches a language model file (about 78 MB) from Hugging Face. That is a plain file download; no data of yours is sent. Turning a voice note into text then runs entirely on your phone, always, signed in or not and with no network — and the audio recording itself never leaves the handset under any setting.
• Purchases. If a paid plan is offered in your version and you buy one, the purchase is handled by Apple or Google, and their receipt is validated through RevenueCat, our billing provider. They receive an anonymous customer identifier and the purchase itself. On an iPhone, RevenueCat also receives Apple’s ad attribution token, which says whether an Apple Search Ads campaign led to the install; Apple provides it without tracking you, and it carries nothing about you or your leads. They do not receive your leads. We never see your card details.
• Feedback you send. When you write to us from Settings → Support → Send feedback, your message, the reply address you give (if you give one), the app version and your phone’s operating system and its version go to our server, and Resend, our email delivery service, delivers them to our support inbox. Nothing about your leads is in it, and the error list above is not either. Our server keeps only a count of how many messages you sent each day.
• Rating the app, on Google Play or the App Store. At most three times a year — when you open your leads once there are three or more, after you export leads or follow them up, and never on the Capture screen — Lanyard asks the store your phone uses to show its own rating card: Google Play’s on Android, the App Store’s on iPhone. The card is the store’s: a rating or review you leave in it goes to Google Play under your Google account, or to the App Store under your Apple Account, as a public review. Lanyard sends nothing to it, and is never told whether the card appeared or what you did. Settings → Support → Rate Lanyard on Google Play (on iPhone, Rate Lanyard on the App Store, once Lanyard’s App Store page exists) opens the store page instead, and after that the app never asks.
• Help improve reading, unless you turn it off. When you correct a scan — type over a field, move a value to another field, take a reading the app offered, or keep one it doubted — the phone works out what that correction teaches and sends only that, a while later, to our server. For each line the camera read: where it sat on the card or badge, how large its type was beside the rest, the shape of each word (a capital letter becomes X, a small letter x, a digit d, and a run of more than four is cut to four, so “Merlehan” leaves as “Xxxxx” and an address as “xxxx@xxxx.xxx”), whether the phone’s own word lists know the word as a first name, a surname, a job word, a department, a legal form, badge wording or a place, how the camera’s frames agreed, what the app had saved the line as and what you left it as. For a badge at a show it also sends three things as one-way hashes, never as text: the show (its name and month); a number that is the same for this phone at that show and different at every other show, so three phones can be told from one; and the words you threw out as not the person, such as ATTENDEE or the show’s own name — never a word the phone knows as a first name or a surname, and never a line the app had saved as the person’s name unless you yourself mark it as not a person. When you fill leads from an organiser’s list, it sends the file’s layout: each column heading as a hash and a shape, and which column held the badge ID, the names, the employer, the job, the email and the phone — never a value from any row, and no layout for a file whose first row is not a row of headings. No word, number, name or address read off a card, a badge or a file, no lead, no identifier of a lead, a scan or a phone, and nothing about you is ever in what it sends. Our server keeps it without your user ID — it uses that only to count how much one phone sends in a day — with only the day it arrived and the app version. A show’s layout reaches other phones at that show only once three different phones agree on it, and the reader treats it as a hint, never a rule: a badge’s barcode still decides whose badge it is. When a show is created or becomes active, the phone asks our server for that show’s layout, by its hash. It is on unless you turn it off in Settings → Privacy → Help improve reading, which says: “When you correct a scan, Lanyard sends its shape — where each line sat and what it turned out to be, never a word or number from it and nothing about you — so every customer’s scans read better.” Off, nothing is sent and nothing is asked for, and anything waiting to be sent is discarded.
• Google’s ML Kit, reporting on itself. The software that reads badges and cards on the Capture screen is Google’s ML Kit, running on your phone. The image and what it reads stay on the phone — Google’s terms say ML Kit does not send them — but whenever a badge or card is read it sends Google diagnostics about the reading software: your phone’s make, model and operating-system version and which ML hardware it has; the app’s name and version; an identifier ML Kit makes for this installation, which Google says is not intended to identify you or your phone; how long each read took; the image size and format; which features ran, and any error codes. Never a photograph, never a word it read, never a lead, never your account. There is no switch: it is built into Google’s software, and neither we nor you can turn it off without taking the camera out of the app. Google describes it at developers.google.com/ml-kit/android-data-disclosure (and the matching iOS page) and keeps it under its own privacy policy.

Who receives what. Everyone Lanyard sends anything to, and where it is kept:

Outside the UK and the EU. The backup and our server are in Belgium; not everyone above is in Europe. Firebase Authentication keeps accounts and the anonymous ID in the United States, whatever region the rest of our project uses. Gemini and Google’s search are not tied to one region. RevenueCat, Resend and Hunter.io are companies in the United States: RevenueCat receives the anonymous customer ID and purchase status above; Resend receives only a feedback message you send; and what a find or a check sends goes from our server in Belgium to Hunter.io, which handles it under its own privacy policy. Apple, Google and LinkedIn act under their own policies, and so does Google for what ML Kit reports about itself, which is not tied to one region.

No one else receives anything from Lanyard: no analytics company and no advertiser. Hunter.io, which keeps a database of published work addresses, receives only what section 06 describes, and only on your tap.

If a future version transmits something this page does not describe, this page will be updated before that version ships, and the store listings will change at the same time.

05 The AI features, and what they send

Lanyard can do four things for you: fill in a company profile from what Gemini already knows about the company on a badge (for one lead, or for up to 50 at a show at once with Look up companies), write a short briefing about the company and the job title, look a company up on the web and summarise what it has been doing, and write a draft follow-up email based on your own notes on that lead, typed or spoken. All four are generated by Google’s Gemini, reached through Firebase AI Logic.

Filling in your own company is separate. Fill in from my website, in setup and in Settings → Profile, reads your own company’s website on your phone and asks Gemini what the company sells and to whom, plus one first-person sentence built from your job title. It is about you and your company, never about a lead, so the switch below does not govern it: it runs only when you tap it, sends your company’s website text (or, if the site cannot be read, the one sentence you type about what you sell), your company name and your job title — with contact details and the names we recognise on the page taken out, and never your own name added — and nothing is saved until you review it and tap Save.

A company profile asks what Gemini already knows. Most badges carry a name and a company and nothing else, and a briefing needs more than a name. So Lanyard can ask Gemini, from its own memory and with no search, what the company is: it is sent the company name, the website domain printed on the card or taken from the email address, the name of the event and any product and competitor names saved on it. What comes back is shown on the lead’s Company tab as unverified, is yours to edit or clear, and is used to write the briefing. It can also count toward a lead’s fit score, marked as estimated. The fit score is computed on your phone, and when nothing better is known it may use Gemini’s estimate of the company’s industry and size: such a score is labelled as estimated (“Possible fit (estimated)”), is never called a strong fit, and an estimate alone never makes a lead a weak one. Where leads are backed up, the fit that is backed up with the lead may rest on such an estimate, and the CSV export says so in its own column. Clearing or correcting the estimate scores the lead again. A briefing asks for a profile itself when the company name is all it has, and is then marked as built partly on unverified facts. Gemini is never asked about the person, and the profile is refused outright when the company on the badge is the person’s own name.

A company look-up searches the web. When you ask for one, Google searches the web for that company name and its website, together with the country the show is in and the current month so it can tell same-named companies apart and date what it finds, and the pages it found are listed under the result so you can check them. It is never asked about the person you met — their name is not part of the request and cannot be added to it. The result is shown with Google’s own search suggestions, as Google requires, stays on your phone for thirty days and is then removed, and is never backed up or used to score a lead.

They are off until you turn them on. A new install has them off, and so does an update that changes what they send: a yes covers the list you read when you gave it, not anything added to it later. Buying a paid plan does not turn them on. Lanyard asks the first time you use one: tap a company profile, a briefing, a company look-up, a draft or Look up companies, and it shows what that request sends and where it goes, and nothing is sent unless you tap Allow. They can also be switched on in Settings → AI, after reading the same list you are reading now — and they are switched off again in the same place, with one tap, taking effect on the very next request.

While they are on, and only when you ask for a company profile, a briefing, a company look-up or a draft, this is what is sent to Google:

Nothing is sent in the background. Every request follows a button you pressed. One button, Look up companies on the queue, sends one company-profile request per lead for up to 50 leads at a show that cannot be ranked yet — it shows you how many, and what each request sends, before you confirm, sends them one at a time only while the app is open, and stops when you leave the app or cancel. Every other button sends one request about one lead. Nothing is generated while the app is closed, and opening the queue sends nothing.

The feature needs a paid (Blaze) Firebase project, and that is a privacy decision rather than a capacity one. On Google’s free tier the Gemini terms permit Google to use submitted content to improve its products, and permit human reviewers to read it. Those are not terms anyone may accept on behalf of a person whose badge was scanned at a stand, so the feature is not offered there. On the paid tier, Google’s terms say prompts and responses are not used to improve their products.

A briefing is a summary of what the app already holds about a company plus a generalisation about a job title. It is not research about a person, and Lanyard never writes one from a company name alone — because a model given only a name writes a confident paragraph about a firm it has never heard of. When the name is all it has, it first asks for the company profile described above and writes the briefing on that, labelled as resting on unverified facts. What is generated is stored on your phone and is never backed up.

The first name in a draft is a greeting, not a question. It is included so the email you are about to send opens the way you would open it yourself. The model is never asked anything about that person, and a draft that comes back containing an email address or a phone number has it stripped out before it is stored — a model must never be the source of a contact detail.

06 Finding and checking an email address

Most badges print a name and an employer and no way to reach the person. On a lead like that, Find email asks for their work address — in the Android app; the iPhone app checks addresses and does not search for them. And an address read off a business card can be misread by a letter: Check this address, or Check emails for a whole show, asks whether it accepts mail. Both are part of the event pass and Pro: up to 100 verified addresses found and 500 addresses checked at each show, from its first day until 30 days after its last, and, across all your shows, at most 300 verified addresses found and 1,500 checked in a calendar month.

It is off until you allow it. The first time you tap Find email or a check, Lanyard shows what is sent and asks; nothing is sent unless you tap Allow. One answer covers both. It is separate from the AI features: allowing one does not allow the other. You can turn it off in Settings → Privacy → Finding and checking email addresses, taking effect on the very next request; turning it off deletes nothing.

What is sent. Lanyard sends the address read off their card, or for a badge with no address their first and last name and their employer (its website when known), to Hunter.io, which checks whether that address accepts mail or looks for one it can verify does; if the card’s address does not exist, the other ways the camera read it are checked too. Nothing else about them is sent — no badge ID, no notes, no grade, no phone number, no photo. An address you typed yourself is never checked. The request goes from your phone to our own server, a Google Cloud Function in Belgium (europe-west1), and from there to Hunter.io, a company in the United States; your phone never contacts Hunter.io itself. Each request carries a Firebase App Check token, for which the app asks Google Play (on Android) or Apple (on iPhone) to attest that it is the genuine app; that carries nothing about the person.

What comes back, and what is kept. For a find, only an address Hunter.io has verified accepts mail comes back to your phone; one it could not verify is not sent to you, not saved and not counted, and neither is a search that found nothing. A verified address is saved as that lead’s email, only if the lead has none — an address you typed is never replaced — and an Undo takes it off again. For a check, the answer is all that comes back, and it changes nothing on the lead: an address that exists is marked as checked; one that does not is shown to you as something to correct, with any other reading of it that does exist offered for you to take. Your phone keeps a record of each search and each check (when, and what the answer was), so the same person or address is not asked about again for the same answer. Our server keeps only a count of how many addresses you have found and checked at each show and each month, and how many searches you made each day — never the name, the employer or the address.

Hunter.io is its own controller. It processes what it receives under its own privacy policy. Once Hunter.io tells us someone has asked it to stop, Lanyard never searches for them or checks their address again on this phone.

You are responsible for emailing them. Follow up only people who came to your stand and would expect to hear from you. For someone you met at a show in Germany or Italy, where a first email needs the person’s agreement even between businesses, Find email waits until you say, on that lead, that they agreed to hear from you; that is recorded as what you said, never as their consent. Your first email to an address that was found — the plain one and the drafted one alike — ends with a line saying where you found their address, so they can ask you to stop.

07 What we never do

• Sell or rent personal data.
• Share data with advertisers, or give anyone a lead for their own marketing.
• Track you across other apps or websites. Lanyard requests no tracking permission and uses no advertising identifier.
• Send marketing email to the people you scan.
• Send anything in bulk on your behalf.
• Send anything about a lead, or anything you wrote, to a model without your having switched that on first. Two exceptions: the AI self-test in Settings, which sends one fixed test sentence — nothing of yours — and only when you tap it; and, when you tap Fill in from my website, the text of your company’s website (or, if it cannot be read, the sentence you type), your company name and your job title — with contact details and the names we recognise on the page taken out, your own name never added, and never anything about a lead.
• Ask an AI model to invent a fact about a named person, or to invent an email address or a phone number. A briefing names no individual, and a generated draft is stripped of any contact detail the model produced before it is stored.
• Upload a photograph or an audio recording. Neither leaves your phone under any setting.
• Send a word or a number read off a card, a badge or an organiser’s file to improve the reader. Only shapes and one-way hashes leave (Help improve reading, section 04), never with anything that identifies you, and not at all once you turn it off.
• Look anybody’s email address up, or check one, without your having allowed it first, or keep our own list of the addresses Hunter.io finds or checks: a found address is saved only as that lead’s email, like one you typed.

08 Keeping and deleting

Nothing is deleted on a schedule. Leads, photographs, voice recordings and what Gemini wrote stay on your device until you remove them. You can delete a show’s photos and recordings, or its Gemini text, yourself in Settings → Photos and recordings: your leads, their details and your notes stay, a company fact you typed or confirmed stays, and a recording that has not been turned into text is kept unless you tick the box that deletes it too — its words would then be lost. Deleting your account deletes the backup.

Discarding a lead hides it; it does not delete it. A discarded lead stops appearing in your lists, and an Undo is offered for a moment so an accidental tap at a busy stand is not permanent — but its details, its scans, its photographs and its notes stay on the phone, and if it was backed up, the backed-up copy stays too, marked as discarded. Scanning the same person again brings it back. Deleting the app removes the database, the badge images and the voice notes from the phone. Deleting your account removes everything backed up to your workspace.

What Help improve reading sent is kept by us to make the reader better, without your user ID or anything else that identifies you, your phone or a lead — so it cannot be picked out and deleted for you, and deleting your account does not remove it. It holds no word, number or detail of anyone. Turning the switch off discards whatever had not been sent yet.

If your leads have never been backed up, we hold no copy: we cannot delete your leads for you and we cannot recover them if you delete them. If they have, the copy in your workspace goes when you delete your account — covered on its own page. Briefings and drafts are held only on the phone that generated them and are never backed up, so deleting the app removes them. The diagnostics Google’s ML Kit reports about itself (section 04) are a record Google holds under its own privacy policy: they name no one, and deleting the app or your account does not reach them.

Your company profile — your company’s name, what you sell and to whom, your usual ask, your job title, your bio, the proof points you kept, and a record of which website they were filled in from and when — is kept on your phone only and is never backed up or synced, and is removed from the phone when you delete your account. What Fill in from my website sends to fill it in — your company’s website text (or the sentence you type), your company name and your job title — goes to Google’s Gemini through Firebase, on a paid project whose terms say prompts are not used to improve Google’s products, because you asked for it: the lawful basis is your own request, to provide the feature (UK and EU GDPR Article 6(1)(b)). Google is the only recipient.

09 Rights of the people you scan

Anyone whose details you capture may have the right to ask for a copy of what you hold, to correct it, or to have it erased. Those requests go to you, as the controller. What Lanyard lets you do today: find the lead in Leads and export it to CSV for a copy; correct their name, company, job title, email address or phone number by editing it; and remove any of those with its Clear control — a field you clear is cleared in your backed-up copy too. Clearing is not erasure. A lead identified by an email address, or by a name and company, keeps that identifier as its internal key, on the phone and in any backup, after the field itself is cleared; the code scanned from a badge or card, and your notes about them, stay on the phone and in any backup; the printed text read from a badge or card stays on the phone, and its photograph and your voice recordings until you delete them (section 08); and a LinkedIn address, website or second phone number read from a card cannot be cleared one at a time. Discarding the lead is not erasure either (section 08). What the app cannot yet do is erase one person completely: all of that stays until you delete the app or your account. A way to remove one person entirely, from the phone and the backup, is coming.

10 Children

Lanyard is a business tool for trade-show exhibitors. It is not directed at children and is not designed for or marketed to anyone under 16.

11 Changes to this policy

If this policy changes materially — in particular if a future version transmits something this page does not describe, or turns something on that this page says is off — the date at the top will change and the store listings will be updated at the same time.

12 Contact

Agent M LLC · hello@agentm.co.uk

Kept with the app’s source code and published here unchanged.

How AgentM handles data across all its products