Privacy policy

iSales is a product of Indrajeet's iQuanta Edu Services Private Limited, a company in India, with its office at Plot No 126, Udyog Vihar Phase 4, Gurugram, Haryana 122015, India. You can reach us at info@iquanta.in or +91 81309 00243.

This policy covers the iSales web app at app.isales.in, the iSales app for Android and iOS, the iSales API at api-v2.isales.in, and the integrations our customers connect to iSales. Our marketing website, isales.in, has its own privacy policy for the enquiry forms on it.

In the terms of India’s Digital Personal Data Protection Act, 2023 (the “DPDP Act”), the organisation that decides why and how personal data is processed is its Data Fiduciary, and an organisation that processes it on their behalf is a Data Processor. iSales is both, for different data:

• We are the Data Fiduciary for the account data of the people who use iSales (their sign-in details, profile, security and device information, and how they use the service), for our billing records with customers, for messages sent to us for support, and for enquiries made to us. This policy is our notice to you about that data.
• Our customer is the Data Fiduciary, and we are its Data Processor, for everything a customer puts into iSales or collects through it: its leads and students, its conversations and payments with them, the job candidates it lists, and the attendance, location, face and call records iSales keeps about its own staff. The customer decides what is collected and why, and is responsible for having a lawful basis for it, including any notice and consent the law requires. We process that data only to provide iSales to that customer, under our agreement with it.

If you are a student or enquirer of one of our customers and want to see, correct or delete your data, please contact that business. If you contact us instead, we will pass your request on to it; see Data deletion instructions.

Each customer adds its own staff to iSales as users: counsellors, managers and admins. For each user, iSales holds:

• Account and profile: name, work email, an optional phone number, the calling and WhatsApp numbers used for work, a profile photo if you add one, role, teams and products, working hours, skills and lead capacity, and whether the account is active.
• Sign-in and security: your password, stored only as a one-way (bcrypt) hash; the secret for two-factor authentication if you turn it on; the time of each sign-in (not your IP address or device); and invite links and password-reset links an admin issues, which expire after 7 days, and forgot-password links, which expire after 1 hour.
• Devices and notifications: if you turn on notifications, a notification token for that browser or device with its type (Android, iOS or web), app version, a label such as “Chrome on macOS”, and when it was last used. Also your notification preferences, and the notifications iSales shows you, which can include lead names and the start of a message.
• Your work in iSales: the notes, calls, messages, tasks, stage changes and other actions you record on leads; an audit log of sensitive actions such as revealing a masked phone number, exporting data, changing settings, connecting or disconnecting apps, and resetting face check-in; and your dashboards, saved views, targets and goals.
• Copilot: your questions to the iSales Copilot, its answers, the actions it proposed or took, and usage figures (the AI model used and the amount of text processed).
• Feedback: what you send through the in-app feedback form, with the app version and platform.
• Phone app details: the app tells our servers its version and operating system with each request.

If your organisation publishes lead microsites, your name and phone number, with a WhatsApp link, appear on the microsites for your leads; booking pages show your name. Anyone with the link to one of these pages can see it.

Checking in and out is part of iSales for every organisation, because iSales assigns new leads automatically only to people who are checked in and not on a break, on leave or on a day off. For everyone, iSales records:

• Shifts: when you check in and out, your breaks, how each check-in was made (web, phone app, automatically or by a manager), the IP address it came from, minutes worked, active and late, leave requests with the reason you give, rosters and shift swaps, and any review or correction by a manager.
• Automatic check-out: iSales looks at when you last did something in it, such as a call, a note or a lead update. If you have done nothing for a set time (2 hours, unless your organisation sets a different time for your shift), iSales checks you out as of your last activity, tells you, and marks the shift for your manager to review. A shift still open 12 hours after its scheduled end is closed the same way.

The features below stay off until your organisation turns them on, and your organisation decides how they are used. Your organisation can also allow check-ins only from its own network, using the IP address above. When they are on, iSales records:

• Location: only if your organisation marks office and work-from-home days by location. The phone app then reads your location once, when you check in, while the app is open. iSales does not ask for or use location in the background. We keep the coordinates, how accurate they are, whether the phone reported them as coming from a fake-location app, and the distance to your organisation’s nearest office. Checking in on the website does not send a location.
• Check-in selfies: if your organisation requires one, the photo taken when you check in, kept with that shift. Your managers can see it.
• Field visits: a separate module that is off unless your organisation turns it on. It records your location when you start and end a visit to a lead, an optional photo at the start, and your visit notes.

Face check-in (biometric data)

If your organisation turns on face check-in:

• Notice first. Before any face photo is taken, the app and website show you this notice: “Your face photos are used only to confirm it’s you when you check in. Admins can see them and reset them.”
• Enrolment. You take 3 photos of your face. We store the photos and, for each one, a face template: a list of numbers describing the face, produced by a face-recognition model. The phone removes camera details, such as where a photo was taken, before uploading it.
• Each check-in. Your selfie is compared with your own templates to confirm it is you. We store the result (a match or not, with a score) and a template of the selfie, and compare the selfie with your selfies from the last 30 days to catch a reused photo. When you enrol, your face is also compared with the other people enrolled in your organisation, so one person cannot enrol for two accounts.
• Where it happens. Face matching runs on our own servers. Face data is not sent to any outside face-recognition service. On the phone, Google ML Kit checks that a face is in the frame to help you take the photo; it looks at the photo on the phone itself (see Google data).
• Who holds it, and where. Indrajeet's iQuanta Edu Services Private Limited (iSales) stores face photos and templates for your organisation, with the rest of iSales’ data, at our hosting providers in Singapore, outside India (see Where data is stored).
• Purpose. Face data is used only to confirm that the person checking in is the account holder. We do not sell it, use it for any other purpose, or share it beyond the hosting providers that store iSales data for us (see Who we share data with).
• Who can see it. Admins with permission to manage attendance can see your enrolment photos and reset them. Managers who review check-ins can see check-in selfies and refused attempts.
• How long it is kept. Enrolment photos and templates are kept until an admin resets them, and are replaced if you enrol again. Turning face check-in off, or disabling your account, does not delete them by itself: ask your admin to reset them, or contact us. Photos from refused check-ins are deleted after 60 days. Check-in selfies are kept with your attendance records.
• Your choices. You do not have to give face data, and you can withdraw it at any time: ask your admin to reset your face check-in, which deletes your face photos and templates, or contact us. While face check-in is on, you cannot check yourself in without it, so your organisation has to give you another way to check in; iSales lets a manager check you in, with a reason that you are told about.

Placing calls, the caller card and adding your calls to lead timelines are what the app is for. So on Android, the permissions marked “Required” below are needed to use the app: it asks for them right after you sign in and does not open until they are allowed, and if you switch one off later in your phone’s settings, the app stops at that screen again until it is allowed. (A phone that cannot draw over other apps, or has no battery optimisation setting, skips that step.)

The other permissions are optional. You can refuse or withdraw them in your phone’s settings; only the feature that needs them stops working. On iOS, the app asks only for optional permissions.

The app does not ask for access to your contacts, and does not use your location in the background.

Call logs (Android)

• While you are signed in, the app reads the calls in your phone’s call history (number, incoming or outgoing, answered or not, start time and duration) and sends them to iSales.
• iSales keeps a call only if its number belongs to a lead you can see in iSales. Every other call, including personal calls, is discarded without being stored.
• Contact names saved on your phone are shown in the app on your phone, and are never uploaded.
• Numbers you mark “Not a lead” get no caller card and are not looked up on our servers. Calls with them are still sent during call sync, and discarded like any other call that is not with a lead.
• When a call rings or is dialled, the app sends the number to iSales to check whether it is a lead. These lookups are not stored.
• iSales records a call only when your organisation connects a cloud calling service (Plivo) and a counsellor places a cloud call through it; calls from your own phone are not recorded. A recording link from another calling service your organisation connects can also appear in iSales. See “Cloud calls” below.

Cloud calls

If your organisation connects Plivo, a counsellor can place a cloud call: Plivo rings the counsellor’s phone, then the lead. These calls are recorded from when the lead answers, and the lead hears a notice that the call may be recorded, unless the organisation turns the notice off. The recording stays on the organisation’s Plivo account; iSales plays it to people who can see the lead without storing a copy. iSales then turns the recording into a transcript with a speech-to-text provider (Deepgram, or Plivo’s own), and writes an AI summary from the transcript.

Customers use iSales to record and follow up enquiries from prospective students and other customers (“leads”). Leads reach iSales through the customer’s website forms and website chat, its booking pages, the ad platforms it connects (such as Facebook and Google lead forms), WhatsApp (a message or call to the customer’s WhatsApp number, or contacts and their chat history imported from its Bluck account), imports, the API, webhooks and Zapier, or are entered by its staff. Depending on how a customer uses iSales, its records about a lead can include:

• Contact and profile: name, phone number (Indian or international), email, city and state, custom fields the customer defines, tags, and the courses or products the person is interested in, with target year.
• Sales follow-up: stage, owner, follow-up dates, priority, reasons a lead was lost, tasks, notes, meeting bookings, and documents prepared for the lead, such as proposals and invoices.
• Source and attribution: where the enquiry came from (source, campaign, ad platform, UTM tags, ad click identifiers such as gclid and fbclid, landing page and referrer), and for each registration the IP address, browser and device details, page address, and any extra details the form sent.
• Conversations: WhatsApp messages, SMS and emails sent through iSales; website chat conversations; call records (direction, duration, outcome, and any transcript a counsellor adds or a connected calling or voice-AI service sends); transcripts of cloud calls and links to their recordings; and managers’ call reviews.
• Engagement: when the person opens a microsite or document the customer sent them, which links they click, and how long they spend on each part of a microsite.
• Payments: payment links, amounts and status, the payer’s name, email and phone, and refund or failure reasons. iSales never receives card or bank account numbers: payment is made on the payment gateway’s own page.
• Consent and preferences: consent records (what was agreed, when, through which channel and, for consent given on a public booking page, from which IP address) and do-not-call and do-not-message flags. iSales checks these flags before calling or messaging, and a WhatsApp reply of “STOP” or “unsubscribe” sets do-not-message automatically.
• Scores and AI insights: lead scores, win probability, student health and refund-risk flags, and AI-written call summaries and suggested next steps, to help the sales team prioritise.
• Other records: events from the customer’s own learning app, if it connects one (such as mock test scores or logins); a lead’s location, only if a field visit records it; one-time codes that counsellors read out to verify a lead; uploaded import files; and testimonials (student name, result, quote and photo) that the customer publishes on its microsites.
• Intake logs: each attempt to add a lead through a form, the API, a webhook or an ad platform, as it was received, with the sender’s IP address and browser details. These are deleted automatically after 90 days, our standard setting.

Customers can also list job candidates in iSales’ hiring pipeline: the role, the candidate’s name, the stage and a note, typed in by their staff.

We use personal data to:

• provide iSales: run each customer’s account, show data to the people allowed to see it, send the messages and place the calls its staff ask for, sync with the apps it connects, and run its automations, assignment rules, scores, reports and AI features;
• sign people in, keep accounts secure, prevent misuse (for example by limiting repeated sign-in attempts), and keep audit records;
• send service emails (invites, password resets, security notices and billing notices) and the notifications users turn on;
• give support, fix problems, and act on feedback;
• bill customers and keep our business records; and
• meet our legal obligations and respond to lawful requests.

We do not sell personal data. We do not use it for advertising, build advertising profiles from it, or share it with advertisers. We do not use customer data to train AI models. Each customer’s data is kept separate and is used only to provide iSales to that customer.

Some iSales features send data to an AI provider to produce a response. We use Anthropic’s Claude models by default; a feature may use OpenAI’s models instead where we, or for the Copilot your organisation’s admin, choose them. Each feature sends only what it needs:

AI output can be wrong, so check it before relying on it. We keep a log of AI inputs and outputs so that what the AI did can be reviewed. On the phone, voice input is turned into text by your phone’s own speech service before anything is sent to iSales.

The DPDP Act’s main duties and rights take effect on 13 May 2027. Until then, the Information Technology Act, 2000 and its Reasonable Security Practices and Procedures and Sensitive Personal Data or Information Rules, 2011 (the “SPDI Rules”) apply. We already honour the rights described in Your rights.

For the data we are the Data Fiduciary for, we process personal data:

• for the purpose you gave it to us for, such as your account, profile and support requests (once the DPDP Act applies, a legitimate use under its section 7 for data provided voluntarily for a specified purpose);
• with your consent, where we ask for it, such as for notifications you turn on; and
• to comply with the law, such as keeping tax records or responding to lawful orders.

You can withdraw consent at any time, for example by turning notifications off or by emailing info@iquanta.in. Withdrawal does not affect what was done before it, and the feature that depends on it will stop working for you.

For data our customers collect, the customer chooses and is responsible for the lawful basis: consent from its leads, or a legitimate use the law allows, such as employment purposes for its staff’s attendance records. The customer gives its own notices to the people concerned.

Under the SPDI Rules, which apply now, passwords, financial information such as card and bank details, and biometric data such as face templates are sensitive personal data. iSales stores passwords only as hashes and does not store card or bank account numbers. It takes face photos only when the person’s organisation has turned face check-in on, and only after showing the notice in section 4. The SPDI Rules also require written consent (an electronic record counts) before biometric data is collected, and a way to decline or withdraw it. iSales does not yet record that consent itself, so an organisation that turns face check-in on must get and keep its staff’s consent, tell them that the data is stored in Singapore, and offer another way to check in to anyone who declines or withdraws.

Service providers that run iSales for us

We use these providers to run iSales. They receive only what they need to provide their service.

Services a customer chooses to connect

When a customer connects one of these in Settings → Apps, iSales sends that service the data the feature needs. The service’s own terms and privacy policy apply to what it does with the data.

• Meta (Facebook and Instagram lead ads) and Google Ads: see the next two sections.
• WhatsApp, through Bluck (bluck.in), which works through Meta’s WhatsApp Business Platform: lead phone numbers, message text and media, template values, campaign recipients and call-permission requests. Replies come back the same way.
• Plivo (cloud calling), on the customer’s own Plivo account: the lead’s and the counsellor’s phone numbers to connect the call, and the call’s recording, which Plivo keeps. See “Cloud calls” above.
• MSG91 (SMS), on the customer’s own MSG91 account: lead phone numbers and the values filled into SMS templates.
• The customer’s own email server (SMTP): lead email addresses and the email.
• Payment gateways (Razorpay, Easebuzz, Pine Labs), on the customer’s own merchant account: the payer’s name, phone and email, and the amount, to create a payment link.
• Zapier, Google Sheets, the iSales API and webhooks: data from these comes into iSales as new leads. API reads return masked phone numbers and emails, and the names, emails and roles of the customer’s users. Webhooks send events (such as a new lead, with its phone number masked) to addresses the customer chooses.

Other sharing

• Within a customer, people see data according to the roles and permissions the customer sets.
• Public pages a customer publishes (microsites, booking pages and chat) show what the customer puts on them, including its counsellors’ names, and on microsites their phone numbers.
• A small number of our own staff can access data when it is needed to run, support or secure iSales.
• We disclose data when the law requires it, for example under a court order or a lawful request from a government authority.
• If our business is merged or sold, data may pass to the new owner, who must protect it as this policy describes. We will tell customers before that happens.

iSales connects to Meta through our Meta app, “iSales CRM”, using Facebook Login for Business. A customer’s admin chooses to connect it in Settings → Apps, signs in with Facebook, and chooses what to allow. The connection asks for these permissions:

What we store:

• an access token for the connection, encrypted. Page tokens are fetched when needed and never stored;
• the ad accounts, Pages and lead forms the admin chose, by ID and name;
• for each lead form submission: name, phone number, email, city and state, the campaign’s ID and name, the form ID, and Meta’s ID for the lead (so it is not imported twice). Other answers on the form are not kept; and
• each campaign’s daily spend, impressions and clicks.

We do not read anyone’s personal Facebook or Instagram profile, friends, posts or messages, and iSales does not post anything on Facebook or Instagram.

How we use it: only to provide the connected features to that customer: putting its lead ad leads into its iSales account, and showing its ad spend and cost per lead. We do not sell this data, use it for advertising or profiling, share it with other customers, or send lead data back to Meta. Leads imported this way are the customer’s data, as described in Our role.

Disconnecting and deleting:

• In iSales, an admin can open Settings → Apps → Meta Ads and choose Disconnect. This deletes the stored access token and the lead form choices, and stops all syncing. Leads and spend figures already imported stay in the customer’s account as its records, until the customer has the leads erased or asks us to delete its data. Deleting a lead in iSales only hides it; the record stays.
• In Facebook, go to Settings & privacy → Settings → Business integrations (or Apps and websites), find “iSales CRM” and remove it. This ends iSales’ access on Meta’s side. Disconnecting in iSales does not do this for you, so do both to end the connection fully. Until it is removed there, Facebook may keep notifying iSales of new leads on a Page that was connected; iSales ignores them once disconnected.
• To have data deleted, follow our data deletion instructions.

Google Ads

A customer’s admin can connect Google Ads in Settings → Apps by signing in with Google and allowing iSales to access Google Ads (the adwords permission). iSales uses it only to:

• list the Google Ads accounts the admin can access, with their name and currency, so the admin can choose one;
• import lead form submissions: name, phone number, email, city and region, and the campaign; and
• read each campaign’s daily spend, impressions and clicks, to show cost per lead.

We store a refresh token for the connection, encrypted. iSales only reads from Google Ads: it does not change campaigns, ads or budgets, and does not upload anything to Google Ads.

iSales’ use and transfer of information received from Google APIs adheres to the Google API Services User Data Policy, including the Limited Use requirements. We use this data only to provide the connected features to that customer. We transfer it only as needed to provide those features (including to the service providers and connected services this policy describes), for security, to comply with the law, or as part of a merger or sale of our business with the customer’s explicit prior consent. We do not sell it, use it for advertising, or use it to train AI models, and our staff do not read it unless the customer asks us to for support, it is needed for security, or the law requires it.

To disconnect, open Settings → Apps → Google Ads in iSales and choose Disconnect. This deletes the stored token and stops syncing; leads and spend already imported stay in the customer’s account until the customer has the leads erased or asks us to delete its data. To end the access on Google’s side as well, remove iSales from your Google Account’s third-party connections at myaccount.google.com/connections.

Other Google services

• Browser notifications are delivered through Google Firebase Cloud Messaging, as described above.
• On Android, voice input uses Google’s speech service, and location at check-in uses Google Play services.
• Google ML Kit runs on the phone to help frame face photos; the photos are analysed on the phone and are not sent to Google. Google says ML Kit sends it metrics about how ML Kit performs and is used, such as device and app details.
• The Google Sheets connection works through an iSales API key that the customer adds to its own sheet; iSales does not access anyone’s Google account for it.
• Google Maps opens only when you tap a map link.

The iSales database and servers are in Singapore, so data in iSales is stored outside India. iSales’ own emails are sent from Amazon Web Services in Mumbai. Notifications pass through Google’s network, and AI features through Anthropic and OpenAI, which may process the data outside India.

Under the SPDI Rules, which apply now, sensitive personal data such as face data may be transferred outside India where that is needed to perform a lawful contract or the person has consented, and the recipient protects it to the same standard. From 13 May 2027, the DPDP Act allows personal data to be transferred outside India except to countries the Government of India restricts by notification. We will follow any such restriction.

When a customer’s agreement with us ends, we keep its data, with access suspended, until the customer asks us to delete it, or until we delete it after giving the customer at least 30 days’ notice by email. We then delete it, except what the law requires us to keep, such as our invoices. Our database provider keeps backups on its own schedule; deleted data disappears from them as they are replaced.

We protect personal data with these measures:

• Connections to iSales are encrypted with HTTPS.
• Passwords are stored only as bcrypt hashes. Public API keys, invite links and password-reset links are stored only as hashes.
• Tokens and passwords for connected services (Meta, Google Ads, payment gateways, email and SMS accounts) and AI provider keys are encrypted with AES-256-GCM and are never shown back in full.
• Access is controlled by role: each customer decides which data each role sees (own, team, product or all leads), which fields are hidden, and whether phone numbers and emails are masked. Revealing a masked number is recorded in the audit log.
• Optional two-factor authentication; sessions that expire after 8 hours; and admins can sign a user out everywhere. Disabling an account, resetting a password or changing a role ends existing sessions.
• Limits on repeated sign-in attempts and on API and public form traffic.
• Signatures are checked on incoming notifications from Meta, payment gateways and our email provider.
• An audit log of sensitive actions, which admins can review and export.

Apart from the secrets listed above, data in the database, including two-factor secrets, webhook signing secrets and the addresses of incoming webhooks, is protected by these access controls and by our database provider’s own safeguards, not by hashing or an additional layer of encryption of our own. No system is perfectly secure. If a personal data breach affects your data, we will inform the affected customers and, where the law requires, the authorities (such as CERT-In, and from 13 May 2027 the Data Protection Board of India) and the people affected.

We honour these rights now, and from 13 May 2027 the DPDP Act gives them to you by law. You have the right to:

• get a summary of your personal data and how it is processed, and know who it has been shared with;
• have it corrected, completed or updated;
• have it erased, unless it must be kept for a lawful purpose;
• withdraw consent you gave;
• have a grievance addressed; and
• nominate someone to exercise these rights for you if you die or become unable to.

If you use iSales: you can update your name, phone and photo in Settings → My profile, and your password and two-factor authentication in Settings → My security. For anything else, ask your organisation’s admin or email info@iquanta.in.

If you are a lead or student of one of our customers: contact that business. It can correct your details in iSales itself. Erasing them cannot yet be started from iSales’ own screens: the business asks us at info@iquanta.in to raise an erasure request in its account, and its admin then approves and completes it in Settings → Erasure requests. Erasure replaces your name with “Erased”, removes your phone number, email, city, state, custom fields, tags, ad click identifiers, landing page and referrer, removes the IP address and device details recorded with each registration and your details in intake logs and payment records, and blocks further calls and messages. It does not yet remove the content of past messages, call records and notes, consent records, any location recorded on a field visit, or the ad platform’s ID for a lead from a Facebook, Instagram or Google form; the business can ask us to remove those too. If you contact us instead, we will pass your request to the business.

To contact us, email info@iquanta.in from the email address linked to your data if you can. We may ask you to confirm your identity. We will acknowledge your request within 7 days and respond within 30 days. From 13 May 2027, if you are not satisfied with how we handled a grievance, you can also complain to the Data Protection Board of India, after first raising it with us. The Board works as a digital office: you complain to it online, in the way it publishes.

iSales is a business tool for organisations and their staff, not a service for children. Users must be at least 18.

Many of our customers are coaching institutes, so their leads and students may be under 18. From 13 May 2027, section 9 of the DPDP Act requires a customer that processes a child’s personal data to first get verifiable consent from the child’s parent or lawful guardian, and not to track or monitor the behaviour of children or direct targeted advertising at them; our terms require this of customers now. Each customer is responsible for meeting these duties for the data it puts into iSales, including not using features that track engagement, such as microsite and document tracking, on children’s data. iSales does not record a lead’s age unless the customer adds it.

iSales does not use cookies: neither the web app nor the API sets any. It uses no third-party analytics or advertising tools. The only tracking is the first-party engagement tracking on microsites and documents described in section 6, which customers control.

• The web app keeps a few items in your browser’s storage: your sign-in token, your theme and layout preferences (such as the sidebar and the AI history panel), the leads you selected when starting a campaign, and notification settings. When notifications are on, Google’s Firebase code keeps its own data in your browser too. Signing out removes the sign-in token.
• The chat widget on customers’ public pages stores a chat session ID, so a visitor’s conversation can continue.
• The phone app keeps your sign-in token, how far it has synced your calls, and the numbers you marked “Not a lead” on your phone.
• The field visit map loads map images from OpenStreetMap, which receives your IP address as any website does.

When we change this policy, we update this page and the date at the top. If a change materially affects how we use personal data, we will tell customers’ admins by email or in iSales before it takes effect, and ask for consent again where the law requires it.

For questions, requests or complaints about personal data in iSales, contact our Grievance Officer. We acknowledge grievances within 7 days and resolve them within 30 days.

Grievance Officer
Indrajeet's iQuanta Edu Services Private Limited
Plot No 126, Udyog Vihar Phase 4, Gurugram, Haryana 122015, India
Email: info@iquanta.in
Phone: +91 81309 00243

You can ask for this policy in English or in any language listed in the Eighth Schedule to the Constitution of India by emailing info@iquanta.in.