Legal

Vendoo privacy policy

1. What Vendoo is and who it is for

Vendoo is a working tool for field sales forces, developed and distributed by GUUAO LLC through the app stores of Google — Google Play, for Android — and Apple — the App Store, for iPhone. The two versions are the same app and do the same things; where this document describes something that depends on the operating system, both are named, because they do not always match. Anyone can download it, but without an account it does nothing: credentials are created and handed over by the company that contracts the service, and the app does not allow accounts to be created and has no sign-up. It is not a consumer app.

There are two kinds of people whose data is processed, and they are worth separating. On one side the rep, an employee of the company that contracted Vendoo, who uses it in the course of their job. On the other, that company's customers — the shops the rep visits — whose information the app downloads so that work can be done, and about whom visits, orders and payments are recorded.

Who is responsible for what. The information the app collects is sent to the management system of the company that contracted Vendoo, which is where it lives and where that company keeps it in accordance with its own policies and with the law. That company decides what commercial data it loads and what it uses it for. GUUAO LLC provides the app and processes that information on that company's behalf, without using it for purposes of its own. For any question about this document or about what the app does on the phone, the point of contact is hola@vendooapp.com.

The data processing described here forms part of the employment relationship between the rep and their employer, and rests on the employer's legitimate interest in organising, coordinating and verifying field sales activity.

That is why the app shows no consent dialog and offers no switches to turn data collection off. This is not an oversight: recording location during the working day, recording visits and reporting crashes automatically are the very purpose of the tool, not optional extras. A consumer app would ask permission; a working tool informs. This document is that information, and it is given to each rep along with their access credentials.

Permissions are still requested by the phone's own operating system — Android or iOS, depending on the device — and the rep grants or denies them there; what does not exist is an additional consent layer inside the app. There are three, and they are the same on both systems: location, camera and notifications. The app does not request photo library access: when the rep picks a saved image, they do so in the system's own picker, which hands over that image and nothing else (clause 2.b).

Change note. Until 11 September 2026 Vendoo existed only for Android, and this document was written that way: it named Android where it really meant “the phone's operating system”. That day the iPhone version appeared and the policy was revised in full to tell the two apart. Every clause that changed carries its own note — they are this one, 2.e, 2.g, 2.i, 2.j, 4 and 5.

What data is collected and what for did not change, and the two exceptions are stated where they belong: on the iPhone the notification additionally passes through Apple's infrastructure (clause 2.j) and, the other way round, the barcode reader stops sending technical data to Google (clause 2.i). Two things changed in this paragraph in particular: permissions are no longer “still requested by Android”, and “photo access” was removed from the list — that was never accurate, because neither version requests that permission.

2. What data we collect and why

a) Geographic location (precise)

Vendoo records the phone's position in two distinct situations, and they are worth separating because they are not the same thing:

• On starting (check-in) and closing (check-out) each customer visit, and when putting the order together, along with the accuracy of the reading and the time.
• During the working day, periodically, only while the app is open. With the app on screen, a point is taken every five minutes. With the app closed or in the background, none is taken: the only thing that happens on waking in the background is sending the points already taken. For each point, the position, the accuracy and — if the device supplies them — the speed and heading are stored. Battery level is not recorded, nor whether the screen is on: that would measure the person and not the work.

What for: to record that the visit to each customer happened, where it happened and how long it lasted, and to let sales supervision follow field activity over the course of the day.

Who sees it: sales supervision and authorized staff at the company, inside their management system.

Nature: the location permission is required in order to record orders and payments: without it the app will not let them be made, and explains what is missing. If the permission is not granted or the phone's location service is off, the periodic recording simply does not happen, and the app does not make up for it in any other way. If in one particular shop the device cannot get a fix, the rep can carry on with the visit regardless.

Change note. Until 1 September 2026 this clause said that Vendoo did not track the rep's route between visits, and on that date it was true. From that day the periodic recording described above became part of the app, by the company's decision, and this clause was rewritten to say so. The notice the app shows on screen was updated in the same move. On 2 September 2026 recording with the app closed was withdrawn, and this clause went back to saying only what the app does: position is taken only while the app is in use.

b) Photographs

On each visit the rep may attach up to five photographs, taken with the phone's camera on the spot. They are resized on the phone itself before being sent and lose the camera metadata, including the coordinate the device embeds in the file.

What for: to leave evidence of the state of the point of sale, the product display, the stock or any incident.

Nature: optional. A visit closes with no photographs at all.

The visit photograph comes only from the camera: the app does not allow it to be picked from the gallery, so that an image from another day cannot pass for today's evidence.

There are three cases where an image may come from the phone's gallery, and in all three the rep picks it: the receipt for a payment — and the additional photographs accompanying it (clause 2.e) — because these are usually screenshots of a bank transfer; the rep's own profile photograph (clause 2.g); and the attachments to a chat with the back office (clause 2.k). In each one the app reads only the image picked, and never goes through the gallery on its own.

c) The customer's handwritten signature

At the signature step, the customer can sign with a finger on the screen. The signature is stored as an image.

What is stored is the image and nothing else: the vector stroke, the pressure, the speed and the timing of the gesture are not kept.

What for: to record the customer's agreement with the order as taken.

Nature: optional.

d) Information about the company's customers

The app downloads from the company's systems the customer list assigned to each rep: name or business name, tax ID, address, telephone, delivery addresses, shop coordinates, applicable price list, credit limit and availability, and unpaid invoices.

This information belongs to the company, is not generated by the app, and is held on the phone solely so that the rep can work offline. The app does not send it back: when it sends an order or a visit, it identifies the customer by their internal number in the company's system, not by their details.

What is sent is what the rep produces during the visit: the order lines, the stock count, the returns and any free-text notes they write. Because those notes are an open field, they may contain a customer's name or address if the rep writes them there.

e) Customer payment data

When a rep records a payment request, the amount, the date, the bank or journal, the bank reference and, if attached, the image of the receipt are sent. They may also attach up to three additional photographs — the rest of the transfers, the change, whatever is needed to support the payment — which stay in the chat for that request (clause 2.k). If they write a comment, that text stays in that same chat.

Change note. The additional photographs were added on 11 September 2026. Until that day a payment request allowed a single image, the receipt, and this clause named only that one.

f) Requests to add or correct customers

The rep cannot create or modify a customer record: what they can do is propose an addition or a correction, which someone at the company then approves or rejects. With that proposal travel the details the rep typed — name or business name, tax ID, telephone, address — and, in the case of an addition, the supporting documents the company's checklist requires, photographed at the shop and converted to PDF inside the phone. Among those documents are identity and tax papers belonging to the customer or their representative.

On converting them, the app strips the photographs' metadata. None of these proposals writes anything into the company's systems by itself.

g) The rep's account data

Email address and password on signing in, and the name they go by in the company's system. The password is transmitted in order to authenticate and is not stored on the phone. Session credentials are stored in the operating system's secure storage — the Keystore on Android, the Keychain on the iPhone — not in the app's database.

The app also has a local lock PIN, of the same kind as a banking app's. That PIN never leaves the phone: it does not travel to any server and is not stored in the clear, only its cryptographic hash inside the secure storage. If the rep picks a profile photograph, that photograph is stored on the phone and sent to the company's systems.

Change note. Until 11 September 2026 this clause named only the Android Keystore, because Vendoo existed only for Android. The iPhone Keychain was added, which is the same mechanism on the other side. What is stored did not change.

h) Operational diagnostics and crash reports

When the app fails, freezes or closes unexpectedly, this is recorded automatically: date and time, type of error, the error message, the first lines of the technical trace, the phone's operating system version, the device model and the last screens the user went through. On a reduced sample of sessions, performance measurements are also recorded (how long the app took to start or to sync) along with the list of network requests made, without their content.

This information travels by two routes: to the company's servers and to an external software diagnostics provider (see clause 4).

What is stripped before it goes to the external provider: the app automatically filters the text going out and replaces with generic tags anything that looks like an email address, a telephone number, an identity or tax number, geographic coordinates or a sum of money. No screenshots are attached, nor the screen's element tree, nor the content of server requests, nor the phone's IP address. Of the rep's identity, only their internal employee number is sent, never their name or their email address.

And what that filter cannot strip, said plainly: it works by recognizing shapes — what looks like an email address, a phone number, an ID number, a coordinate or an amount — and a personal name or an address written in prose has no shape that tells it apart from the rest of the text. If an error message drags along what the rep wrote in a free-text note, that text may reach the diagnostics provider as it stands. That is why this policy declares — and the app store listing does too — that a customer's name and address may be shared by this route, even though the app never sends them deliberately.

What for: to diagnose and fix failures. Before this channel existed, crashes in the field were only known about if the rep wrote them down by hand in a note.

Nature: mandatory, with no way to switch it off from the app.

i) Technical data from the barcode reader

To read product barcodes, each version of the app uses its operating system's library, and that changes who receives what. On both, the code is read entirely inside the phone: neither the image captured by the camera nor the code read leaves the device.

• On Android it is ML Kit, a Google library, and it is the one that sends the technical data described below.
• On the iPhone it is Vision, the library belonging to Apple's own operating system. It works inside the device and sends nothing to anyone: by this route not one piece of technical data leaves the iPhone, neither to Google nor to Apple.

On Android only, that library sends Google, on its own account, technical data about its own operation: the phone's model and manufacturer, its operating system version, the name and version of this app, a technical identifier specific to the installation, response times, the configuration the library was invoked with, and any error codes produced.

What for, according to Google: to measure the performance of its libraries, debug them, maintain them and detect misuse.

Nature: mandatory on Android. That transmission is made by Google's own library and cannot be switched off from the app; the only alternative would be to remove barcode reading altogether. On the iPhone there is no transmission to switch off.

Change note. Until 11 September 2026 this clause said, without distinguishing, that the app uses ML Kit and that this library transmits technical data to Google. That was true, because the only version was the Android one. That day the iPhone version appeared, which reads codes with Apple's library and makes no such transmission, and the clause was split in two so as not to attribute to the iPhone a transfer that does not happen.

j) Registering the phone to receive alerts (notifications)

Vendoo tells the rep about things that happen when they are not looking at the screen: that an order was confirmed or canceled, that a payment request was approved or sent back, that a customer was assigned to them or taken away, or a message from the company. For an alert to reach a particular phone, that phone has to be registered first. That registration is what is described here.

What is sent and to whom. There are two transmissions and they go to different places:

• To Google — and, on the iPhone, to Apple as well. On starting up, the app asks Google's notification service — Firebase Cloud Messaging — for a registration token: a long string that identifies this installation of Vendoo on this phone and which is the only thing that makes it possible to deliver an alert to the right device. In doing so, that service also generates, on its own account, a technical identifier for the installation, of the same kind as the one described in clause 2.i. On the iPhone there is one more step, because iOS admits no other route: before that, the device obtains from Apple its own token — that of the Apple Push Notification service — and it is that one Google needs in order to be able to deliver an alert to that iPhone.
• To the company's servers. The app then hands them that token, so an alert can be directed to this rep. Traveling with it are: a phone identifier of the app's own, generated at random the first time and kept in the operating system's secure storage; the platform name (android or ios, depending on the device); the version of Vendoo installed; and a device tag (the operating system version and build), which is what makes it possible to know which phone to look at when a rep reports that nothing is reaching them.

About the app's own phone identifier: it is a random number created inside the device, does not come from the hardware or from any user account — neither the Google one on Android nor the Apple one on the iPhone — and identifies the phone, not the person: that is why it survives signing out, and why it also accompanies the rest of the requests the app makes to the company's servers. It is deleted when the app is uninstalled.

What is not sent in that registration: neither the rep's name nor their email address — the session already says whose phone it is — nor location, nor any customer data.

The text of every alert passes through Google, and on the iPhone it passes through Apple as well. It is written by the company's system and, to reach the phone, it crosses the notification service's infrastructure: Google's in both cases and, when the destination is an iPhone, Apple's on the last leg. It is the same route by which any notification reaches that phone, and there is no other: an alert that does not go through there does not arrive.

Nature: the rep can deny the notifications permission from their phone's settings — on Android or on the iPhone alike — and will then see no alerts. It is worth being precise: the phone is registered regardless, because that is part of how the app works and not of how alerts are presented. On signing out, the app deregisters, so that alerts about one customer list do not keep arriving at a phone that has changed hands.

Change note. This clause was updated on 11 September 2026, the day alerts started reaching the iPhone too. Two things change and are worth saying: the platform name traveling in the registration is no longer always android, and on the iPhone the alert crosses, in addition to Google's infrastructure, that of Apple — which previously played no part. What is sent and what for did not change.

k) Chats with the back office

An order, a payment request, a customer or an invoice has, in the company's management system, a chat — the same message thread the back office sees — and the rep can read it and write in it from the app. What is sent is what the rep writes and picks: the message text, the mentions of people at the company that they themselves flag, and the attachments they decide to add — a photograph taken on the spot, an image from the gallery, or a PDF put together by photographing pages. Attachments are resized if they are too heavy, are sent only with a connection, and none travels without the rep having picked it one by one.

Where it is stored: in the company's management system, alongside the document it belongs to, just like everything else the app sends (clause 4). The rep sees only the chats for their own documents and for the customers on their list; an internal back-office note is visible to them only if they are mentioned in it.

On the phone: so it can be read offline, the app keeps an encrypted copy of the first page of every chat the rep has opened — along with the list of people who can be mentioned in it — inside the same local database described in clause 4, and when showing it, says how old that copy is. A message written with no signal waits on the phone and goes out by itself when the signal comes back.

Change note. This clause was added on 2 September 2026, the day chats arrived in the app.

3. What we do NOT do

Vendoo does not:

• show advertising or contain any advertising library;
• use behavioral analytics, user profiling or marketing tracking tools;
• collect any advertising identifier: neither Android's advertising ID nor Apple's (IDFA) on the iPhone — the app does not even request the tracking permission iOS requires for that;
• access contacts, the microphone, messages, the calendar or the call history;
• sell, rent or transfer data to third parties for commercial purposes;
• create automated profiles producing legal effects on people.

On identifiers: the diagnostics tool described in clause 2.h, the barcode-reading library described in clause 2.i — on Android only — and the notification service described in clause 2.j each generate a technical identifier specific to each installation, and the app itself also generates its own to identify the phone to the company's servers. All are random numbers created on the phone, which do not come from the device or from any account, and serve to group the records of one device together. They are not used for advertising, are not shared with advertisers, and disappear when the app is uninstalled.

4. Where the data is stored

On the phone: the app keeps an encrypted local database so work can go on offline, holding the customer list, prices, visit drafts, location points not yet sent, photographs and signatures awaiting despatch, and the copy of the chats the rep has opened (clause 2.k). This database is excluded from cloud backup — neither Google's on Android nor iCloud's on the iPhone — so that the company's information does not reach the employee's personal account. On Android it is also excluded from the direct transfer of data when changing phones. And, on both systems, the key that decrypts that database is stored in such a way that it travels in no backup and to no other device: a database without its key cannot be read. Each rep has their own: on a shared phone, one does not see a single row of the other's.

On the company's servers: all synced information — visits, orders, routes, photographs, signatures, payment requests, customer requests and the messages and attachments from chats — is sent to the management system of the company that contracted Vendoo, where it is integrated with the rest of its commercial information. That system is its own: the app keeps no parallel copy anywhere else.

External diagnostics provider: the crash reports and performance measurements described in clause 2.h are additionally processed in Sentry (Functional Software, Inc.), a software diagnostics service whose receiving servers are in the United States. That entails an international transfer of that diagnostic data, limited to what is described in that clause and with the filtering explained there. Sentry acts as a processor on the company's behalf and is not authorized to use that information for any purpose of its own. No external advertising or product analytics provider is used.

Barcode-reading library (on Android only): the technical data described in clause 2.i is transmitted to Google LLC, whose receiving servers are in the United States, which likewise entails an international transfer, limited to that technical data. Google uses it to maintain and improve its own libraries, in accordance with its terms of use. Neither the camera images nor the codes read are transmitted. On the iPhone this transfer does not exist: there the reading is done by the operating system's own library, inside the device.

Notification service: the registration described in clause 2.j is handled by Google LLC through Firebase Cloud Messaging, with receiving servers in the United States: this too is an international transfer. Passing by that route are the phone's registration token, the technical installation identifier the service itself generates and the text of every alert, which is what has to be delivered. Google is involved here in order to get the alert to the right phone, and is not authorized to use that information for any purpose of its own beyond providing that service.

Apple's notification service (on the iPhone only): iOS does not allow an alert to arrive by any route but its own, so on the iPhone the last leg is handled by Apple Inc. through the Apple Push Notification service, with receiving servers in the United States: this too is an international transfer. Passing by that route are the registration token Apple assigns to that iPhone and the text of every alert. Apple is involved, like Google, solely to deliver the alert to the right device.

Maps: the screens that show a map — a customer's record, the detail of one of their branches, and the one where the rep confirms where the shop is — download their imagery from OpenStreetMap, a free public service. Requesting a map tile reveals, to whoever serves it, the area being looked at. That is why the map is drawn only on those detail screens, never in a list, and never in advance: a map the rep has not opened is not downloaded.

Change note. Until 6 September 2026 the map was drawn on a single screen, and this clause said so. That day, by the company's decision, it also began to be drawn on the customer record and on the detail of their branches. Who it is shared with did not change — it is still the same public service, and still no data about the rep or the customer travels — but how many times did: the clause was corrected on 11 September 2026, when it was reviewed in full.

Transmission: all of the app's communications take place exclusively over HTTPS. The app is configured to reject any unencrypted connection.

An external service, with no personal data: to show the reference exchange rate, the app queries public sources for the exchange rate in Venezuela. Those queries carry no data about the user or the customer: they include no credentials, no identifiers and no content at all.

5. For how long

On the phone: route points already sent to the server are deleted automatically after seven days, and the same goes for everything else that went out through the send queue — photographs and signatures included — which is deleted from the phone seven days after being sent. Anything not yet sent is kept until the sync is confirmed, so as not to lose the rep's work.

On signing out, the credentials are removed from the device; the rep's local database stays, encrypted, precisely so as not to lose what has not gone out yet. The app itself allows it to be viewed and wiped under Manage accounts on this phone, on the sign-in screen, saying first how many pending submissions would be lost. When the app is uninstalled, the phone deletes its local files, the encrypted database included.

Change note. Until 11 September 2026 this sentence named Android, which was the only system Vendoo existed on. It was rewritten so that it holds on both.

On the company's servers: information is kept for as long as the applicable accounting, tax and labour obligations in Venezuela require, and in any event while the associated tax obligation has not lapsed. Visits, photographs and signatures form part of the commercial document they belong to — the order, the payment request, the visit record — and are kept alongside it and for the same length of time: they have no shorter period of their own. Route points may be purged separately, and on that it is worth being exact: the management system includes an automatic route-purging task, with ninety (90) days as a reference value, but it ships switched off and is not switched on today. While that remains so, route points are kept in the management system for as long as the company keeps them. No period that nobody has set is announced here: the day the company sets one and switches that purging on, it will be said on this same page.

At the diagnostics provider: crash reports and performance measurements are kept for thirty (30) days, which is the period configured in that service, and are then deleted.

On the retention period for photographs and signatures: announcing an early deletion for them, shorter than that of the document they form part of, was considered and decided against. They are the evidence that the visit happened and that the customer agreed, and separating them from the document they support would leave it without evidential value exactly when it is needed. Announcing a period that is then not applied would be worse than announcing none.

6. Who it is shared with

Inside the company: the information Vendoo collects is transmitted to the management system of the company that contracted the service, and only authorized staff (sales supervision, administration and IT) have access to it in the exercise of their duties. On GUUAO LLC's side, access is limited to the technical staff strictly needed to operate and support the app.

Outside the company, only with the providers identified in clause 4 — the software diagnostics provider; Google, for the notification service and, on Android, for the barcode-reading library; and Apple, on the iPhone, for the last leg of that same notification service — and limited in each case to what is described there. No other category of information — location, photographs, signatures, orders, customer or payment data — is transmitted to third parties, with two caveats worth stating clearly rather than leaving implicit:

• the text of a crash report may drag along whatever the rep wrote in a free-text note, and a customer's name or address may appear there (clause 2.h);
• the text of an alert crosses Google's infrastructure and, if the destination is an iPhone, Apple's too, because that is the only way for it to reach the phone (clause 2.j).

Information may only be disclosed to other third parties where a competent authority requires it under Venezuelan law.

The website. This policy is about the app. The site vendooapp.com, which you are probably reading it on, uses Google Analytics (through Firebase, of Google LLC) to measure how many visits it gets and which pages are read. It is audience measurement and nothing more: the site shows no advertising, creates no marketing profiles and stores no personal data of its own — the only thing that reaches GUUAO LLC from the site is whatever you type into the contact form, which travels as an email.

One exception that depends on the rep: the app can generate an order note as a PDF — including the customer's name, the order lines, the prices, the total and, where there was one, their signature — and send it from the phone itself through the apps installed (messaging, for instance). That sending is decided and carried out by the rep, and its destination is outside the app's control. The company instructs its staff to share that document only with the customer it belongs to.

7. Rights: access, correction and deletion

Anyone whose data is processed through Vendoo — reps and the company's customers — may request access, correction or deletion of their data by writing to hola@vendooapp.com, putting Data request — Vendoo in the subject line and supplying enough information to identify themselves.

The request will be answered within a maximum of thirty (30) business days. Deletion may be limited where retention is necessary to meet legal, accounting or tax obligations, or to defend claims; in that case the reason and the period will be stated.

Signing out does not delete data from the server: it only removes the credentials from the phone. To delete data, use the channel above.

8. Minors

Vendoo is aimed exclusively at adults working as field sales reps for one of the companies that contract it. Although the app downloads freely from Google Play and from the App Store, without an account issued by one of those companies there is nothing to use. It is not intended for minors and does not knowingly collect data about minors.

9. Security

Session credentials are stored in the operating system's encrypted storage. The app's local database is encrypted, and its key lives in that same protected storage on the phone. The app communicates exclusively over HTTPS. Local data is excluded from cloud backup and from device-to-device transfer. The app locks itself with a local PIN after fifteen minutes of inactivity. Server access is restricted to authorized staff.

No security measure is absolute. The company works continuously on strengthening the protection of the information held on devices.

10. Changes to this policy

Any amendment will be published at this same address with a new update date. Substantial changes will additionally be communicated to reps through the company's internal channels and will be reflected in the notice the app itself shows on screen.

11. Contact

GUUAO LLC
hola@vendooapp.com

Vendoo · GUUAO LLC