Legal

Zentrix Sales privacy policy

1. What Zentrix Sales is and who it is for

Zentrix Sales 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 Zentrix Sales, 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 Zentrix Sales, 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@zentrix.company.

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 Zentrix Sales 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)

Zentrix Sales 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, which is the default interval: the company can change it from its system, and the app never takes more than one point a minute. 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, the time and the company being worked with are stored. Battery level is not recorded with the route, nor whether the screen is on: that would measure the person and not the work. (A crash report, described in clause 2.h, does carry the phone's battery level at that moment, as technical data for diagnosing it; it does not travel with the route.)

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 Zentrix Sales 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. If the visit leaves a return, up to five photographs of the returned goods may also be attached, likewise from the camera only and with the same treatment.

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 as such: 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. The exception is collections: with each payment go the balances of the customer's invoices that the rep had in front of them (clause 2.e). They go to the same company system they came from, not to third parties.

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.

Each payment request also carries the balances the rep had in front of them when collecting: the list of the customer's invoices with their number and their balance in dollars, which of them the rep touched in that payment, the sum of those balances and the time those balances were read. They let whoever approves the request know what debt the payment was made against.

Separately from the payment, from an invoice the rep can record the customer's payment commitment — the date they promised to pay and, if they said it, the amount — and change that invoice's tags.

All of this goes only to the company's servers, to the same system the invoices came from. It is not sent to any third party.

Change note. The balances and the payment commitment have been named since 23 September 2026. The app was already sending them; this clause did not say so, and clause 2.d stated that customer information was not sent back.

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 the photographs to PDF, the app strips their metadata. A supporting document can also be a PDF the rep already has on the phone — for instance, one the customer sent them by messaging — picked in the operating system's own file picker. That PDF, of up to 1 MB, travels as it is: the app does not modify it, so it carries whatever metadata it came with (author, program, dates). 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 Zentrix Sales 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.

Each report also carries the phone's technical context that the diagnostics service itself collects, depending on what each system supplies: manufacturer and model, free memory and storage, battery level and whether it is charging, screen orientation, connection type (Wi-Fi or mobile data), language and time zone, and whether the operating system has been modified (rooted). And it carries some tags of the app's own, so the failure can be classified: the number of the company being worked with, the subdomain of the company's server and the version of its system, whether the phone had signal at that moment, and the store the app was installed from.

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. The phone's IP address is not stored in the report, but the provider sees it on receiving it, like any server, and uses it to note the approximate city and country it came from: that does stay in the report. 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.

And since version 5.2.11 there is a second route, which the rep opens themselves: the «Report a problem» form (Profile › About). It has a single field, free text, where the rep says what happened to them; on sending it, that text travels together with the same technical data described above — version, model, operating system, last screens, the phone's context, the tags and the internal employee number. It does not ask for the rep's name or email address, attaches no screenshots and sends nothing until «Send report» is tapped.

What is written in that field goes through the same filter and has the same limit as the previous paragraph: a name or an address written in prose cannot be told apart from the rest of the text. It is, in fact, the place where they are most likely to appear, because it is the rep who does the writing. It is best to say what happened and with which customer by their code, not by their name.

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.

Change note. This clause was updated on 23 September 2026, the day the app introduced the «Report a problem» form. Neither the categories of data nor the recipients change: what that form sends is what this same clause already described, and it goes to the same provider, with the same filtering and the same retention period. What changes is who triggers it — before, only a failure; now, the rep too — and that the text is written by a person, which is the case where the filter's limit weighs most.

Change note. That same day the list of what travels was also corrected: the phone's technical context, the app's tags and the approximate city and country were already being sent, and this clause did not name them; and it said the IP address was not sent without making clear what the provider deduces from it.

Nature: the automatic crash reporting is mandatory and cannot be switched off from the app. The «Report a problem» form is voluntary: it only sends something if the rep writes it and sends it.

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)

Zentrix Sales 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 Zentrix Sales 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 Zentrix Sales 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.

l) App usage (product measurement)

Since version 5.2.1, the app measures how it is used with Google Analytics for Firebase, from Google LLC. It sends two things: which screens are opened, by their generic name (for instance, «/pedidos» or «/factura»), and a closed list of about thirty usage events — that a visit was opened or closed, that the barcode reader was used, that a payment was recorded, that someone signed in, that a submission went to the queue or was rejected, among others.

What each event carries: only counts, whole numbers such as how many orders, lines, photographs or invoices that visit or that payment had. The app discards any other data before sending it: no name, email address, telephone, tax ID or address travels, no coordinate, no amount or balance, nor the number of a customer, an order or an invoice. A screen's name is trimmed so that it never carries an identifier. The rep's employee number is not sent either.

What Google adds on its own account: as in any app using that service, each transmission carries a technical installation identifier generated by the library itself, the phone model, the operating system and app versions, the language, and the approximate city and country Google deduces from the connection. The library also records, by itself, the first use, the start of each session and the time in use.

No advertising identifier: collection of the advertising identifier is switched off on both versions — on Android, the permission that would provide it is also removed — and what is measured is not used to personalize ads. That is why the app does not request iOS's tracking permission.

What for: to know which parts of the app are used and where reps get stuck, in order to decide what to improve.

Nature: always sent, and it cannot be switched off from the app.

Change note. This clause was added on 23 September 2026. The measurement has existed since version 5.2.1, of 16 September 2026, and until today this policy said, wrongly, that the app used no analytics tools and no external product analytics provider.

3. What we do NOT do

Zentrix Sales does not:

• show advertising or contain any advertising library;
• use user profiling or marketing tracking tools. It does measure how the app is used (clause 2.l), but that measurement counts screens and events, with no personal data and no advertising identifier;
• 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 —, the notification service described in clause 2.j and the usage measurement described in clause 2.l 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.

A caveat about photographs, the signature and supporting documents: while a visit or a customer addition is still open, those files are stored as loose files in the storage the operating system reserves for the app, outside the encrypted database and unencrypted, so that a draft does not lose them if the system closes the app. That storage is also excluded from cloud backup. When the visit is closed, the photographs and the signature move into the send queue, inside the encrypted database, and those loose files are deleted.

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 Zentrix Sales, 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 provider is used.

Usage measurement: the events and screens described in clause 2.l are sent to Google LLC through Google Analytics for Firebase, with receiving servers in the United States: this too is an international transfer, limited to what is described in that clause. Google processes that information under the terms of that service; the app has advertising-identifier collection and ad-personalization signals switched off.

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: they request it from tile.openstreetmap.org, operated by the OpenStreetMap Foundation, based in the United Kingdom. Requesting a map tile reveals, to whoever serves it, the phone's IP address and the area being looked at, which on a customer's record is the area where their shop is. 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 — but how many times did: the clause was corrected on 11 September 2026, when it was reviewed in full. On 23 September 2026 it was corrected again: it said no data about the rep or the customer traveled by this route, and the area being looked at and the phone's IP address do reach whoever serves the map.

«Ir con Google Maps» (Go with Google Maps): that button opens the phone's maps app to get to the customer's shop — Google Maps if it is installed; if not, whichever the phone has, which on the iPhone is Apple Maps — and hands it the shop's coordinates and, depending on the case, the customer's name and address. It only happens when the rep taps it. What that app then does with that data depends on its own policy.

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 seven days after being sent. Everything else that went out through the send queue — photographs and signatures included — is deleted from the phone once sent, as soon as it is more than seven days old counting from when it was recorded (not from when it was 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 Zentrix Sales 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 have a period of their own, a shorter one: the management system deletes them automatically ninety (90) days after they were taken, with a purging task that runs every night. Ninety days is the default value; the company can change it from its system's settings. It is the same period the notice the app shows on screen states.

Change note. Until 23 September 2026 this paragraph said that purging ships switched off and was not switched on, and that route points were therefore kept with no set period. The first part is true — it ships switched off — but on the company's system it was already switched on: the paragraph was corrected to state the period actually applied.

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 Zentrix Sales 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, for usage measurement and, on Android, for the barcode-reading library; Apple, on the iPhone, for the last leg of that same notification service; and the OpenStreetMap Foundation, for the map imagery — 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 these caveats, worth stating clearly rather than leaving implicit:

• the phone's approximate city and country, which the diagnostics provider and Google deduce from the connection on receiving a report or a usage event (clauses 2.h and 2.l);
• the area looked at on the map, which reaches OpenStreetMap when its imagery is requested and which, on a customer's record, is the area of their shop (clause 4);
• the shop's coordinates, and sometimes the customer's name and address, which the «Ir con Google Maps» button hands to the phone's maps app when the rep taps it (clause 4);
• 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 zentrix.company, which you are probably reading it on, uses no analytics tools and no cookies, shows no advertising, has no forms and stores no data about its visitors. Like any website, it is served by a hosting provider (GitHub, with Cloudflare in front), which sees the connection's IP address in order to deliver the page.

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 Zentrix Sales — reps and the company's customers — may request access, correction or deletion of their data by writing to hola@zentrix.company, putting Data request — Zentrix Sales 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

Zentrix Sales 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 photographs, signature and supporting documents of a visit or a customer addition still open are kept separately, without that encryption (clause 4). 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.

Change note (23 September 2026). This policy was checked against what the app does, and what it failed to say or said wrongly was corrected: usage measurement with Google Analytics for Firebase (new clause 2.l, and the denials in clauses 3 and 4); the invoice balances that reach the company with each payment, and the payment commitment recorded on an invoice (2.d and 2.e); the retention of the route on the company's system, which is deleted after ninety days and not kept with no set period (5); OpenStreetMap and the «Ir con Google Maps» button as third parties (4 and 6); what the diagnostics provider actually receives (2.h); that the photographs, signature and supporting documents of open work sit outside the encrypted database (4 and 9); and details of the route, return photographs, PDF supporting documents and the send queue (2.a, 2.b, 2.f and 5). Nothing changed in the app that day: what changed is that the policy now says it.

Change note (13 October 2026). The app was renamed Zentrix Sales, and this policy moved from vendooapp.com/en/privacy.html to zentrix.company/sales/en/privacy.html. What is collected, why, and who it is shared with did not change. The website paragraph (clause 6) was rewritten, because the new site uses no analytics and no contact form.

11. Contact

GUUAO LLC
hola@zentrix.company

Zentrix Sales