Privacy Policy

Servizato processes information supplied through account forms, profiles, enquiries, bookings, service delivery and the optional features you use. Different information is needed for a customer account, a provider business and an assigned Pro.

• Account identity and contact information: name, email, telephone number, account role and account status, used to create accounts, authenticate users and connect service participants.
• Business and Pro information: business owner and company details, business type, description, contact address, service coverage, offerings and prices; Pro identity/contact details, skills, provider relationship, availability and work records, used to manage and deliver services.
• Service information: selected area, confirmed service address, requested offering, quantity, preferred time, instructions, booking and job status, assignments, parts, proof of work and completion records.
• Communication and feedback: enquiry details, message text and attachments, conversation participants and read status, ratings, review comments, cancellation reasons and bill/dispute notes.
• Financial and device information: invoice and payment records, optional provider bank/UPI payout details, session information, notification records and browser push subscriptions, as explained below.

Registration asks for a name, email, telephone number and password. Provider registration also asks for business details. Providers can create Pro accounts linked to their team and issue initial credentials that the Pro is required to change.

Passwords are processed to create or check password hashes. If Google sign-in is configured and selected, Google and the authentication service process the sign-in exchange and basic account identity/profile information; Servizato links the resulting account to its application profile. If SMS sign-in is configured, your telephone number is sent to Twilio to deliver a one-time code. Code records, expiry and use status are stored for verification.

Sign-in also creates a session and records account role and credential status so that protected features can check access. A customer's service profile and saved contact/address information are distinct from the sign-in account; editing one does not necessarily change the other.

You can enter a city, state, locality and PIN code to discover available services. The selected area is saved in this browser, with account scoping where supported, so it can be restored on later visits. It is a discovery preference, not automatic confirmation of a booking address.

When you choose a current-location feature and permit browser location access, coordinates, accuracy and reading time can be processed. Where configured, Google Geocoding receives coordinates to suggest an address. A service destination is saved with a booking/request only through the address-confirmation workflow; manual address entry remains available.

An assigned Pro can enable location reporting for an active job to support navigation and arrival checks. The workflow processes recent location readings, accuracy, timing and arrival evidence for that assigned job. It is not a promise of continuous background or off-duty tracking. Google map embeds or navigation links may receive the service destination when used.

Requests, bookings and jobs link customers, provider businesses and assigned Pros. Records can include the service address, selected offering and price snapshot, quantity, preferred date, instructions, assignments, progress timestamps, work/parts notes, completion proof and cancellation or review information.

These records support fulfilment, coordination, invoices, payment reconciliation and review of problems. Authorised participants receive the information their service workflow exposes, including relevant contact and destination information. Operational staff have role-based tools for administration and dispute review.

Provider business images and Pro service-proof photos use the configured Cloudinary upload service. The application stores media URLs and related identifiers/metadata alongside the business or job. Media is retrieved through those delivery links; an upload permission check is not a guarantee of private or revocable download access. The proof API also accepts supported proof types and optional notes/metadata; the current Pro photo form does not itself require identity documents or biometric verification.

Messages can include text, attachment links, file descriptions and size/type information. Conversation records track participants, timestamps and read status. Job conversations and support-conversation records are processed through the existing chat features. A support conversation is not a designated privacy or statutory grievance channel unless the business explicitly appoints it for that purpose.

Ratings contribute to public marketplace summaries. Review comments are stored with the completed booking for feedback and moderation and can appear in the relevant authenticated feedback views. Free-text fields and uploads may contain additional personal information supplied by the sender; avoid including unrelated sensitive details about yourself or other people.

Where online payment is available, Razorpay processes the payment interaction. Servizato exchanges invoice/order references, amount and currency, and, for payment-link flows, customer name, email and telephone number. The application retains payment references, method/status, amounts, verification/reconciliation information and relevant payment-link metadata.

The reviewed checkout integration does not provide a Servizato form for collecting card PINs or CVVs. This does not mean that no financial information is retained: invoices, payment-link data, direct-payment confirmations, refund references, commission terms/acceptance and payout audit records are part of the service records.

Provider payout setup can collect the account-holder name, bank name, account number and IFSC, or a UPI identifier. When secure payout storage is configured, sensitive payout fields are encrypted in application storage and masked in routine views; authorised review/reveal actions are recorded. Recording a payout or refund is distinct from actually transferring funds.

Authentication uses session and anti-forgery cookies. The application uses JWT-based sessions with a configured maximum age of seven days; this is not a seven-day deletion policy for account or service records. Clearing cookies or signing out affects sign-in access, not the retention of completed service records.

Browser storage is also used for the selected discovery area, theme, account-scoped notification-invitation dismissal and push-device association. The address-suggestion endpoint sets a short-lived client identifier cookie for request limiting. The push worker uses local browser storage for its account/device binding and recent notification identifiers.

You can change browser permissions and clear site storage in browser settings. Doing so can remove saved preferences or require sign-in and device setup again. The reviewed application code does not install a dedicated advertising or analytics tracker; hosting and third-party operational logging still require deployment review.

In-app notification records include their recipient, event information, destination, timestamps and read state. They support booking, job and related operational updates independently of browser notifications.

Web Push is optional and is requested only after an explicit Enable action. A device registration stores a browser push endpoint, encryption keys, readable device label, timestamps and an account/login association. The browser's push service processes delivery; the implementation supports reviewed Google, Mozilla, Apple and Windows push-service endpoints.

Browser alerts use generic display text and resolve access through the signed-in account. You can disable push for this device or another listed device in notification settings. Browser permission is controlled separately in browser site settings. Disabling push does not erase notification history or unrelated service records, and deactivated device metadata can remain stored.

Information is shared within the service workflow with the relevant customer, provider business, assigned Pro and authorised operational staff. Public provider listings, business images, service coverage and rating summaries expose the information returned by marketplace discovery; private account or financial fields are not intended as public listing content.

The implemented integrations include MongoDB-backed application storage, Google sign-in and mapping/geocoding when configured, Twilio SMS when configured, Cloudinary uploads, Razorpay payments and browser-vendor push delivery. A feature's availability depends on the deployment configuration. These providers process the data needed for the feature and may apply their own notices and terms.

Information may also need to be handled for a valid legal request or to investigate security or service problems, subject to applicable law. Actual hosting/database regions, processor contracts, subprocessors and international-transfer arrangements have not been confirmed in this review.

The implementation retains account, service, communication, notification and financial records. It does not define a complete retention/deletion schedule for these categories or a general automatic account-erasure process. Login or OTP expiry controls whether a credential can be used; it does not establish when the underlying database record, backup or provider copy is deleted.

A final retention policy needs to account for service fulfilment, accounting and other applicable legal requirements, dispute handling and security, and must include media, backups and third-party copies. No fixed retention period or deletion deadline is promised in this review edition.

Implemented safeguards include password hashing, signed/encrypted session handling, server-side authentication and role/ownership checks, input validation, protected upload signing, payment verification and conditional encryption of sensitive payout fields. Security also depends on correct deployment, secret management, permissions and operational monitoring.

These measures do not establish that every system is risk-free. This review makes no certification, independent audit or guaranteed-security claim. Incident response, breach communications and operational security procedures require an approved business process.

Existing profile screens allow permitted contact/address changes. You can use manual location entry, control browser location permission, manage push devices, change browser notification permission and sign out. These controls have different effects and do not amount to automatic deletion of all stored information.

Requests for access, correction, erasure, withdrawal of consent or other applicable privacy rights need identity verification and review under the law in force. The application does not currently offer a general self-service export, erasure or nomination workflow. The absence of that workflow does not remove any statutory right.

The approved privacy/grievance contact is still pending, as shown below. This page does not submit or track a request. Identity checks, request handling, lawful exceptions and response/escalation procedures must be established before this review edition is treated as a final notice.

Registration does not currently collect a date of birth or implement a parent/guardian consent workflow. A verified age/eligibility policy and any necessary protections for children's data have not been approved. No age-verification or parental-consent capability is claimed here.

The Digital Personal Data Protection Act, 2023 and the notified 2025 Rules have phased commencement. As of this review date, the published schedule has not yet brought the main processing and Data Principal rights provisions into force. Existing applicable information-technology, sensitive-data and consumer-protection requirements still need to be addressed; phased commencement is not an exemption from all privacy obligations.

The date above identifies this source review, not legal approval or an effective contractual date. Material processing changes should be reflected in a reviewed update, with any notice or consent steps required by applicable law. Publication alone does not demonstrate legal compliance.