Shipping and Delivery Policy

Part A: General

Applies to: All BizSensei Digital properties

1. Purpose and scope of this Part

This Part sets the general rules that apply to every BizSensei Digital property, product and service. The later Parts of this policy add property specific detail for the main website, the store, the agency services, the blog, the BizSensei OMS portal and marketplace, and Qiaomed. Where a later Part adds detail, that detail should be read together with this Part. Where a later Part is silent on a general question, this Part answers it.

The general rules in this Part cover the meaning of electronic delivery, the legal framework for electronic records in India, the moment at which delivery is treated as complete, the duties of the buyer, the diagnosis of failed delivery, re-delivery, delivery of updates, delivery records, outages and force majeure, accessibility of delivery, gift and transfer purchases, and the express position on physical goods and couriers. Every customer, buyer, subscriber, client, restaurant, practitioner and user of a BizSensei Digital property is encouraged to read this Part first, because it contains the commitments that BizSensei Digital makes across the whole ecosystem.

2. Digital only: the foundational rule

BizSensei Digital is a digital business. Its catalogue consists of software licences, downloadable software, hosted software access, digital downloads, subscriptions to online services, and professional services such as marketing, design, development, search optimisation, retention work, content and consulting. None of these things has a physical form that can be boxed, labelled, handed to a courier or tracked through a parcel network.

Because nothing physical is sold, there are no parcel shipping charges, no cash on delivery for physical goods, no courier tracking numbers for products, no warehouse dispatch queues and no transit insurance for goods in the ordinary sense. Any page or checkout that refers to delivery timelines is referring to the time needed to generate, send and make available an electronic item, or to complete a service milestone, and not to the time needed to move a parcel from one place to another.

The single exception that involves physical movement of any kind is described in Part F of this policy. On the BizSensei OMS marketplace, food prepared by independent restaurants is physically carried to customers by those restaurants or by their own delivery partners. That movement is not performed by BizSensei Digital, is not a shipment of a BizSensei Digital product, and is governed by Part F and by the terms between the customer and the restaurant. Outside that marketplace activity, there is no physical delivery anywhere in the BizSensei Digital ecosystem.

3. Express schedule: no physical goods on any property

For complete clarity, BizSensei Digital records the following schedule as an express statement of fact and of contractual intention. This schedule applies even if any older page, archived document or third party listing uses shipping language loosely.

If a customer believes that a physical item was promised, the customer should contact BizSensei Digital promptly at info@bizsensei.co.in with the order number or proposal reference so that the record can be checked. BizSensei Digital will correct any misunderstanding in writing and, where a purchase was genuinely made on the mistaken understanding that a physical good would be supplied, will address the matter fairly and in accordance with applicable consumer law and the refund arrangements that apply to that product or service.

4. Electronic delivery and the Information Technology Act, 2000

Electronic delivery under this policy is delivery of electronic records. The Information Technology Act, 2000 recognises electronic records and provides, in plain terms, a framework for when an electronic record is treated as dispatched and when it is treated as received. This clause explains that framework in ordinary words. It is a summary for delivery purposes and is not a substitute for the text of the Act or for legal advice.

Under that framework, dispatch of an electronic record generally occurs when the record enters a computer resource outside the control of the sender. In practical delivery terms, that means a licence email, an activation link, an invoice or a download notification is dispatched when BizSensei Digital's mail system or store system sends it out into the network, beyond the direct control of BizSensei Digital, addressed to the email address or account that the buyer supplied or holds.

Receipt of an electronic record is treated differently depending on how the record was addressed. Where the buyer has designated a specific email address, inbox, account or system for receiving records of that kind, receipt generally occurs when the record enters that designated resource. Where no specific resource has been designated, receipt generally occurs when the record is retrieved by the addressee. Where a record is sent to an address that is not the designated address, receipt is generally linked to the record coming to the attention of the addressee at the correct place of business or residence, as the Act provides. BizSensei Digital applies this dispatch and receipt logic in a practical and fair way when it assesses whether delivery happened, when it happened and what should happen next.

Place also matters under the Act. As a general summary, an electronic record is treated as dispatched from the sender's place of business and received at the addressee's place of business, even though the servers and networks involved may be located elsewhere. That is why a delivery email sent through an external mail provider, or a download served through hosting infrastructure, is still a delivery from BizSensei Digital to the buyer for the purposes of this policy.

Applying that framework, BizSensei Digital treats the following events, taken together or separately as appropriate to the product, as the core delivery events: the generation of a licence key for the buyer's order, the sending of the delivery email to the address supplied by the buyer, the appearance of the licence, download or invoice inside the buyer's store or portal account, the provisioning of a workspace or account with login access, and the handover of a service deliverable through the agreed channel. If one channel fails but another channel has successfully made the item available to the buyer, delivery may already be complete through the successful channel, and BizSensei Digital will explain that position clearly if a dispute arises.

5. What counts as delivered: general definitions

Because BizSensei Digital sells several different kinds of digital things, the meaning of delivered must be specific to each kind. The following general definitions apply across all properties, and the later Parts add further detail for their own products and services.

• Licence key. A licence key counts as delivered when the key has been generated for the buyer's order, sent by email to the address supplied by the buyer, and made visible inside the buyer's account where an account based system applies. The buyer does not need to activate the key for delivery to be complete, although activation is needed to use the licensed product.
• Downloadable file. A downloadable file counts as delivered when a working download link or download button has been made available to the buyer through the delivery email, the buyer's account or both, and the file is downloadable through that route at the time it is made available, allowing for ordinary internet connectivity on the buyer's side.
• Hosted software access. Access to hosted software counts as delivered when the workspace, portal account or application access has been provisioned for the buyer, the plan or entitlement purchased has been activated on that workspace or account, and login credentials, an invitation or an activation link have been sent to the buyer or to the administrator nominated by the buyer.
• Subscription or plan entitlement. A subscription entitlement counts as delivered when the entitlement is recorded against the buyer's account or workspace, the features and limits of the plan become available for use, and a confirmation has been sent or displayed to the buyer.
• Service deliverable. A service deliverable counts as delivered when it has been handed over through the channel agreed for that engagement, such as email, a shared drive, a code repository, a staging link, a content system or production deployment, in the format agreed for that deliverable.
• Invoice and order documents. An invoice, receipt or order document counts as delivered when it has been sent by email, made available for download inside the buyer's account, or both.
• Update or new version. An update counts as delivered when it has been made available through the product update mechanism, the buyer's account, the hosted service itself or another channel notified to customers, while the relevant licence or subscription is active.
• Newsletter and content email. A newsletter or content email counts as delivered when it has been sent to the email address held for the subscriber. Article access on a website is not a delivery event at all, because the article is simply available on the website when published.

Delivery is about making the item available to the buyer in the agreed way. It is not dependent on whether the buyer immediately opens the email, downloads the file, activates the licence, logs in to the workspace or reads the deliverable. A buyer who delays opening a delivery email for personal reasons has still received delivery, although BizSensei Digital will always help a buyer who later cannot find the email or the link, in accordance with the re-delivery provisions of this policy.

6. Delivery timelines: general commitments

BizSensei Digital makes the following general timeline commitments for standard digital products. Products are digital; licence keys and download links are delivered by email within 24 hours of payment confirmation, usually within minutes. In the ordinary course, automated systems generate the licence and send the delivery email shortly after payment is confirmed, and the buyer will also find the relevant items inside the account. The outer limit of within 24 hours exists to cover payment verification, fraud screening, system maintenance, provider delays and manual review where those steps are genuinely needed.

Payment confirmation means the point at which the payment gateway or payment method confirms that payment has succeeded and the funds or authorisation are treated as received for the purposes of the order system. Time spent waiting for a bank, card network, wallet, unified payments interface or gateway to confirm a payment is not counted as delivery delay by BizSensei Digital, because BizSensei Digital cannot deliver against a payment that has not been confirmed. If a payment remains in a pending or failed state, the buyer will be guided to complete or retry payment, and delivery will follow confirmation.

Services are delivered per the timelines in the proposal or agreement. Service delivery is milestone based rather than instant, and the proposal, statement of work, email agreement or order document for the engagement is the authoritative schedule for that work. General statements on websites about typical project durations are indicative only and do not override a written engagement schedule.

Hosted software provisioning timelines are described in the relevant Part for the product concerned. Where provisioning is automated, access may be available within minutes of confirmation. Where provisioning involves configuration, data import, branch setup, training or manual verification, the timeline communicated during onboarding will apply, and BizSensei Digital will keep the buyer informed if that timeline needs to change for a genuine reason.

7. The buyer's duties for successful delivery

Electronic delivery depends on accurate information from the buyer. The buyer has the following duties, which are conditions of smooth delivery and which BizSensei Digital asks every buyer to take seriously at checkout and during onboarding.

1. Give a working email address that the buyer controls, that is spelled correctly, and that the buyer can access at the time of purchase and afterwards.
2. Keep mailbox space available so that delivery emails, invoices, activation links and support replies are not rejected for a full inbox.
3. Check spam, junk, promotions and filtered folders after purchase, because automated delivery emails are occasionally filtered by mail providers even when they are correctly sent.
4. Whitelist or add the sender addresses used by BizSensei Digital to the buyer's contacts or safe sender list where the buyer's mail system allows it, especially for business mail systems with strict filtering.
5. Tell BizSensei Digital promptly if delivery does not arrive, by writing to info@bizsensei.co.in with the order number, the email address used at checkout and a short description of what is missing.
6. Keep licence keys, download links, passwords, one time codes and account credentials secure, and do not publish them, share them publicly or hand them to unauthorised persons.
7. Provide accurate account, business, domain and onboarding information where provisioning depends on that information, and correct any error promptly when it is noticed.
8. Use a device, browser and internet connection that are capable of receiving email, opening the account, downloading files and accessing hosted software, and seek help promptly if a technical barrier appears.

If a buyer supplies an email address belonging to another person, a disposable address that expires quickly, a group inbox that the buyer cannot access, or an address with a spelling error, delivery to that address may fail or may go to a place the buyer cannot reach. BizSensei Digital will help correct the record and re-deliver to the account holder after identity checks, as described in this policy, but the buyer bears the initial responsibility for the accuracy of the address supplied.

8. If delivery does not arrive: first steps

If a delivery email has not arrived within the expected window, the buyer should first check spam, junk and promotions folders, search the mailbox for the order number and for messages from BizSensei Digital, confirm that the mailbox is not full, and log in to the relevant account to see whether the licence, download or invoice is already visible there. Many apparent delivery failures are resolved at this stage because the item is present in the account even though the email was filtered.

If the item cannot be found after those checks, the buyer should write to info@bizsensei.co.in with the order number. Including the order number is important because it allows the support team to locate the payment record, the licence record and the email log quickly. A buyer who writes without an order number should include the full name used at checkout, the email address used at checkout, the approximate date and time of purchase, and the product purchased, so that the order can still be traced.

BizSensei Digital will investigate the delivery record, confirm whether the email was sent and whether it bounced, check whether the licence was generated and whether it appears in the account, and re-deliver where re-delivery is appropriate. The fairness commitment in this policy is central: BizSensei Digital will always re-deliver a digital product that genuinely never arrived, after the checks described in this policy are completed.

9. Failed delivery: diagnosis

When a delivery problem is reported, BizSensei Digital works through a structured diagnosis so that the true cause is found and the correct remedy is applied. The usual causes, and the usual responses, are as follows.

Diagnosis is evidence based. BizSensei Digital uses order logs, email logs and activation logs, as described later in this Part, to establish what was generated, what was sent, when it was sent and what happened next. A buyer will not be asked to prove a negative beyond providing the order details reasonably needed to locate the record.

10. Re-delivery rules

Re-delivery means sending or making available again a licence key, download link, invoice, activation link or account item that was part of an earlier delivery. Re-delivery is available while the licence is active and the store account exists, and for hosted services while the relevant subscription or account is active, subject to the identity and security checks in this clause.

Re-delivery is made to the account holder only, after identity checks. Those checks may include confirming the order number, the email address used at checkout, payment details in masked form, account sign in, or other reasonable verification steps proportionate to the value and sensitivity of the item. BizSensei Digital applies these checks to prevent licence keys and account access from being handed to a person who is not the buyer, and a buyer who is the genuine account holder should expect the checks to be straightforward.

Expired links are regenerated. A regenerated link replaces the expired link and should be used promptly. Download and re-delivery limits may be applied fairly to prevent abuse, such as automated scraping, public sharing of links or repeated requests that are inconsistent with genuine personal or business use. BizSensei Digital does not use re-delivery limits to defeat a genuine customer's access to a product that the customer has paid for and is entitled to use while the licence is active. If a limit is ever reached in error, the buyer should contact support and the position will be reviewed on its facts.

Re-delivery does not create a new licence, extend a licence term, add a domain, add a branch or add any entitlement that was not part of the original purchase. It restores access to what was purchased. If the original licence has expired, been revoked for breach, or been refunded, re-delivery of the underlying product may no longer be available, and BizSensei Digital will explain the position and any renewal or repurchase route that exists.

11. Delivery of updates and new versions

For downloadable software and plugins, updates and new versions are delivered through the buyer's account or through the product update mechanism, while the licence is active. The buyer is responsible for applying updates in accordance with the product instructions, for backing up the buyer's own site or data before applying a significant update where the product guidance recommends a backup, and for checking compatibility with the buyer's own environment.

For hosted software, including BizSensei OMS, updates arrive as service updates. That means BizSensei Digital deploys improvements, fixes and new features to the hosted service, and customers receive them as part of the service without needing to download or install a package. Release behaviour, maintenance windows and any customer action needed for a particular update will be communicated through the product, by email or through support channels as appropriate.

Delivery of an update does not restart licence terms, does not guarantee that every future version will be identical in feature set, and does not oblige BizSensei Digital to maintain compatibility with modifications, custom code or third party extensions that BizSensei Digital did not supply. Security updates and critical fixes are treated as a priority for delivery through the normal update channels.

12. Risk, responsibility and the limits of liability for delivery

Risk and responsibility for a digital item pass on delivery as described in this policy. Once a licence key has been delivered, the buyer is responsible for keeping it secure and for using it only within the licence terms. Once account credentials or an activation link have been delivered, the buyer is responsible for securing the account, setting a strong password, and controlling who inside the buyer's organisation has access. Once a service deliverable has been handed over, the buyer is responsible for reviewing it within any acceptance window that applies, for backing it up, and for any use the buyer makes of it after acceptance.

BizSensei Digital is not liable for delivery failure caused by an incorrect email supplied by the buyer, by the buyer's mail filters, or by third party email and hosting outages, because those matters are outside the reasonable control of BizSensei Digital. That statement is subject to an important saver. Nothing in this policy limits a consumer's statutory rights. BizSensei Digital will always re-deliver a digital product that genuinely never arrived, after the checks in this policy, and no exclusion in this policy is intended to leave a genuine buyer without the product that the buyer paid for.

No exclusion or limit in this policy covers fraud or wilful misconduct. Estimates of delivery timing are given in good faith and, except where a specific written commitment states otherwise, estimates are not guarantees. Where BizSensei Digital has given a specific outer limit, such as delivery of standard licence emails within 24 hours of payment confirmation, BizSensei Digital treats that limit as a genuine service commitment and will explain and remedy any case in which it is missed.

13. Delivery records and proof of delivery

BizSensei Digital keeps delivery records so that delivery questions can be answered with evidence rather than recollection. The records ordinarily kept include order logs showing the order, the product, the payment status and the licence or entitlement generated; email logs showing that a delivery message was sent, the address it was sent to and any bounce information returned by the receiving system; account records showing that a licence, download or invoice was made available inside the account; activation logs showing when and where a licence was activated; provisioning records for hosted workspaces; and handover records for service deliverables, such as email threads, repository commits, deployment records and shared drive activity.

These records are retained for so long as is reasonably needed for order administration, licence administration, accounting, dispute resolution, fraud prevention and compliance with law. They are handled in accordance with the privacy arrangements that apply to the relevant property. If a buyer asks what delivery records show for an order, BizSensei Digital will provide a clear summary of the delivery events for that order, subject to security checks and to the protection of other customers' information.

Delivery records are evidence, not a trap. If the records show that an email was sent but the buyer genuinely never received the benefit of the product, the re-delivery commitment applies. If the records show that a licence was activated and used, that fact will be relevant to any later claim that the product was never delivered, and BizSensei Digital will discuss the records openly with the buyer so that the true position can be established.

14. Outages, maintenance and force majeure

Delivery depends on systems that BizSensei Digital does not wholly control, including payment gateways, email providers, hosting providers, domain and network infrastructure, app distribution channels and the buyer's own systems. If a gateway, hosting or email provider outage, a network failure, a cyber incident, a government action, a natural event or another force majeure event affects delivery, delivery periods pause during the period of the disruption, and BizSensei Digital will complete delivery as soon as it reasonably can after service is restored.

Where an outage affects a significant number of customers or a time sensitive delivery, BizSensei Digital will give notice through the affected property, by email or through support channels, as practicable in the circumstances. Notice may follow the start of the incident where the incident itself prevents immediate notice. A pause under this clause is not a cancellation of the order and does not by itself create a right to treat the product as undeliverable if delivery is completed within a reasonable period after restoration, subject always to a consumer's statutory rights.

Planned maintenance is handled in a similar spirit. Where planned maintenance is expected to affect delivery or provisioning, BizSensei Digital will try to schedule it to minimise disruption and will communicate the window where the impact is material. Automated licence delivery may continue during some maintenance windows and pause during others, depending on which systems are affected.

15. Accessibility of delivery

BizSensei Digital wants delivery to work for every customer, including a customer who cannot access email in the ordinary way because of a disability, a technical barrier or a temporary loss of access to the mailbox. A customer who cannot access email may request an alternative delivery channel by contacting BizSensei Digital at info@bizsensei.co.in or by phone at +91 93726 65745 and explaining the barrier in general terms.

Alternative delivery may include guided access through the buyer's account with support assistance, delivery to a corrected or additional address that the account holder verifies, or another secure arrangement that is appropriate to the product and to the identity checks required. BizSensei Digital will not weaken licence security or hand credentials to an unverified person in the name of accessibility, but it will work in good faith to find a channel that is both accessible and secure. Customers are encouraged to raise an accessibility need early, ideally before purchase, so that delivery arrangements can be agreed in advance.

16. Gift purchases and transfers

A person may buy a digital product intending it for someone else, for example a business owner buying for a manager, or a consultant buying for a client. Unless the checkout provides a specific gifting function and that function is used, delivery goes to the buyer's account and to the email address supplied by the buyer. It is the buyer's responsibility to use any gifting function correctly, or to arrange onboarding so that the intended user's access is set up properly with BizSensei Digital's help.

Licences are non-transferable except where the licence terms for the specific product expressly allow a transfer and the transfer process in those terms is followed. Buying a product does not create a right to resell the licence, lend the licence key, activate the product for unrelated third parties, or move the licence to another person or business at will. Where a business is sold, merged or restructured and a licence needs to move as part of that genuine change, the account holder should contact BizSensei Digital so that the request can be considered under the licence terms and, where transfer is permitted, recorded correctly.

Gift delivery does not change the buyer's duties in this policy. The buyer must still supply accurate delivery information, and the recipient's use of the product remains subject to the licence and service terms that apply to it.

17. Communications about delivery

Delivery communications include order confirmations, licence emails, download notifications, invoice emails, provisioning invitations, onboarding messages, update notifications and support replies about delivery. These are transactional communications that form part of the purchase or service, and they are distinct from marketing communications. A customer who unsubscribes from marketing email will still receive transactional delivery communications for purchases the customer makes, because those communications are necessary to deliver what was bought.

BizSensei Digital may send delivery communications from automated systems as well as from support staff. An automated email is a real delivery communication even though no individual typed it at the moment of sending. If a customer is unsure whether a message that appears to come from BizSensei Digital is genuine, the customer should not click links in the suspicious message, and should instead sign in to the account directly or contact info@bizsensei.co.in for verification.

18. Changes to delivery methods

BizSensei Digital may improve or change its delivery methods over time, for example by changing email providers, account layouts, download systems, update mechanisms or provisioning workflows. A change in method does not change what was purchased. Where a change materially affects how existing customers receive licences, downloads or updates, BizSensei Digital will communicate the change and, where needed, provide guidance so that customers can continue to access what they have bought while their licences are active.

No change to a delivery method will retrospectively turn a completed delivery into an undelivered one. If a customer cannot access a previously delivered item because of a method change made by BizSensei Digital, the customer should contact support and BizSensei Digital will restore access through the new method or another suitable route.

19. How to contact BizSensei Digital about delivery

For all delivery questions, the first point of contact is email at info@bizsensei.co.in. The phone number +91 93726 65745 may be used where a delivery issue is urgent or where email itself is the channel that has failed. When contacting BizSensei Digital, include the order number where there is one, the name and email address used for the purchase or engagement, the property concerned, and a clear statement of what was expected and what has or has not arrived. Clear information at the first contact materially shortens the time needed to diagnose and fix a delivery problem.

Delivery promise in brief: digital products only, licence keys and download links by email within 24 hours of payment confirmation and usually within minutes, account copies for safekeeping, honest diagnosis when something goes wrong, and re-delivery of anything that genuinely never arrived.

Part B: BizSensei.co.in

Applies to: bizsensei.co.in

1. Role of the main website in delivery

The website at bizsensei.co.in is the main public website and software showcase for BizSensei Digital. It presents products, services, features, resources and company information. Depending on the journey a visitor takes, the main website may introduce a purchase that is completed on the store, may provide product information that supports a purchase made elsewhere in the ecosystem, may host enquiry and contact routes, and may provide access points into accounts, billing journeys and product information. This Part explains delivery where the main website is involved, while Part C governs the store checkout in detail.

Nothing on the main website is a physical product. Product pages that describe software, plugins, tools and services are describing digital items and digital work. Screenshots, mockups and packaging style images, where used, are visual representations of digital products and do not mean that a boxed product will be sent by courier.

2. Enquiries, demos and information requests

Submitting an enquiry form, a contact form or a request for information on the main website is not a purchase and does not by itself create a delivery obligation for a product. The delivery that follows an enquiry is a response: an email reply, a phone call, a proposal, a quotation, a demonstration invitation or other information appropriate to the enquiry. Response timing depends on the nature of the enquiry and on business hours, and any specific timing promised in an automated acknowledgement or in correspondence will be honoured in good faith.

Where the main website offers a demonstration, trial information, a resource download or a tool, delivery of that item is electronic. A resource is delivered by displaying it on the website, by making it downloadable from the page, or by sending it to the email address supplied for that resource. A demonstration invitation is delivered by email or through the booking channel used for the demonstration. Access to an online demonstration or demo environment, where offered, is delivered by sending access details or by opening access for the account or email address nominated by the requester.

3. Purchases that start on the main website

Some purchase journeys may start on the main website and finish on the store or in a billing flow. Where that happens, delivery of the purchased product is governed by the Part that applies to the completing channel, ordinarily Part C for store purchases and Part F for OMS provisioning. The main website's role in such a journey is presentation and routing; the delivery event itself is the licence generation, email sending, account availability and provisioning described in the governing Part.

If a price, plan or feature is described on the main website and the purchase is completed elsewhere, the order confirmation and the account record for the completed purchase are the reliable records of what was bought and what was delivered. A customer who believes that delivery does not match what was described on the main website should contact BizSensei Digital with the order number so that the description, the order and the delivery record can be compared and any genuine mismatch resolved fairly.

4. Account linked delivery from the main website

Where the main website provides sign in or account linked routes, items connected with the customer's account, such as licences, billing information, downloads and support information, are delivered or made available through that account in accordance with Part A. A customer must sign in with the account that holds the purchase. Signing in with a different email address will show a different account that may be empty, and that does not mean delivery failed; it usually means the wrong account is being viewed.

Password reset and account recovery messages are delivery communications for account access purposes. They are sent to the email address held for the account and are subject to expiry and security controls. A customer who cannot receive account recovery email should contact BizSensei Digital for identity checked assistance, in accordance with the accessibility provisions in Part A.

5. Free tools and website resources

The main website may provide free tools, calculators, checkers, templates and informational resources. Access to a free tool on the website is immediate when the tool page loads and the tool functions in the browser or through the website service. There is no separate delivery event for a tool that is used in place on the website. Where a tool produces a result that can be downloaded, copied, emailed or saved, the chosen output route is the delivery route for that result, and the user is responsible for saving the result at the time it is produced if the tool does not promise stored history.

Free resources carry no delivery guarantee of the kind that applies to paid products, but BizSensei Digital maintains them in good faith and will correct material delivery faults, such as a broken download link on a resource page, when they are reported. A free resource may be changed, replaced or withdrawn without a delivery obligation for the earlier version, unless a separate written commitment says otherwise.

6. Service information and proposal delivery

Where the main website is the first point of contact for agency or consulting services, the proposal, quotation and engagement documents are delivered electronically, ordinarily by email or through a shared document link. Delivery of a proposal is not acceptance of the proposal. The services themselves, if engaged, are delivered under Part D of this policy and under the timelines in the proposal or agreement.

Case studies, portfolio items and service descriptions on the main website are information, not deliverables. Viewing them involves no delivery beyond the ordinary loading of the website. Customers should not treat a portfolio example as a promise that an identical item will be delivered for their own engagement; each service deliverable is defined by its own proposal or agreement.

7. Website availability and delivery

Access to the main website itself is provided over the internet and depends on hosting, network and device factors. Temporary unavailability of the website does not undo a delivery that was completed through email or through an account, and does not extend a licence term unless BizSensei Digital states otherwise or the law requires otherwise. Where website unavailability prevents a customer from reaching a download or account item at a time sensitive moment, the customer should contact BizSensei Digital by email or phone so that an alternative route can be considered while the website issue is resolved.

Part C: BizSensei Store

Applies to: bizsensei.store

1. Role of the store

The store at bizsensei.store is the commerce home of the BizSensei Digital ecosystem. It is where products are presented for purchase, where checkout is completed, where payment is taken through the payment routes offered at checkout, and where the buyer's account holds the licences, downloads, invoices and order history for store purchases. This Part describes store delivery in detail and should be read with Part A.

Every product sold through the store is digital. The store sells software licences, plugins, downloads, OMS billing plans and related digital entitlements and add-ons as presented at checkout from time to time. No store product is a physical good, no store order produces a parcel, and no store delivery involves a courier.

2. Order flow from checkout to delivery

The ordinary store order flow has the following stages. Understanding the stages helps a buyer identify exactly where an order has reached if delivery appears delayed.

1. The buyer selects a product, plan or add-on and proceeds to checkout.
2. The buyer supplies the required details, including an email address controlled by the buyer, and completes any consent and checkout steps presented by the store.
3. The buyer pays through the payment route offered, and the payment provider processes the payment.
4. The store receives payment confirmation, or records the order in a pending or failed state if confirmation is not received.
5. On confirmation, the store creates or updates the buyer's account record, generates the licence or entitlement, records the order and invoice, and sends the order confirmation and delivery emails.
6. The licence key, download link and invoice become visible inside the buyer's account, where the account system applies.
7. The buyer activates the licence, downloads the file or uses the entitlement in accordance with the product instructions.

If the flow stops at the payment stage, delivery does not follow because there is no confirmed order to deliver against. If the flow reaches confirmation but an email is delayed by a mail provider, the account copy will ordinarily already exist and can be used while the email catches up.

3. Order confirmation emails

After payment confirmation, the store sends order confirmation email to the address supplied at checkout. The confirmation ordinarily identifies the order, the product or plan purchased, the order number and the next steps for accessing what was bought. Depending on the product and on system configuration, the licence key and download instructions may be included in the confirmation email itself or in a separate delivery email sent in the same delivery sequence.

The order confirmation is a delivery record as well as a receipt. The buyer should retain it, note the order number, and quote the order number in any support contact. If the buyer receives a payment receipt from the payment provider but no confirmation from the store, the buyer should check spam and the account first, and then contact BizSensei Digital with the order number if one was shown, or with the payment and checkout details needed to trace the order.

4. Licence key delivery in the store

Licence key delivery is the heart of store delivery for software products. The key is delivered in two places: by email to the buyer, and inside the buyer's store account. Having the key in both places is deliberate. The email is the immediate notification, and the account is the durable record that the buyer can return to at any time while the account exists.

One key is issued per licence purchased. If a buyer purchases multiple licences, multiple keys or a licence with multiple entitlements will be recorded as the purchase provides. A licence key is a credential as well as a product identifier. The buyer must keep it confidential, must not publish it, and must enter it accurately when activating the product, because activation systems distinguish between similar characters and may reject a key that has been copied incompletely.

Licence keys and download links are delivered by email within 24 hours of payment confirmation, usually within minutes, for store products. That commitment applies to the standard automated delivery of keys and links. A manual review, payment verification step or provisioning dependency may affect a particular order, and where that happens the store or support team will communicate the position rather than leaving the buyer without information.

5. Activation and domain binding

Delivery of a licence key and activation of a licence are separate events. Delivery happens when the key is sent and made available in the account. Activation happens when the buyer enters the key in the product and the licensing system accepts it and binds the licence to the domain or installation that the licence terms permit.

Activation binds the domain. A buyer should therefore activate on the correct domain, in the correct environment, after checking whether a staging or test use is permitted by the licence terms and how it is treated by the activation system. Moving a licence to a different domain, where the licence terms allow a move, follows the deactivation and reactivation or transfer process described in the licence terms or advised by support. A buyer who activates on the wrong domain by mistake should contact support promptly, explain the error, and expect identity and licence checks before any correction is made.

A failed activation is not automatically a failed delivery. The key may have been delivered correctly while activation fails for a separate reason, such as a mistyped key, a domain mismatch, a licence that is already active elsewhere, an expired licence, a server connectivity problem on the buyer's hosting, or a product version issue. Support will diagnose activation and delivery as distinct questions and resolve each on its own facts.

6. Download delivery in the store

Where a product is supplied as a downloadable file, delivery consists of making the file available through a download link or button in the delivery email, in the buyer's account, or in both places. Downloads live in the account: the downloads or licences area of the buyer's store account is the durable home for purchased downloadable products, and the buyer should return there for later downloads rather than relying only on an old email link.

Download links may expire for security reasons. Expiry of a link is not loss of the product. While the licence is active and the store account exists, the buyer can sign in to obtain a fresh link, or request re-delivery under Part A if account access itself is the problem. Links are regenerated when they expire; a regenerated link supersedes the old one.

The buyer is responsible for downloading the correct file, keeping a safe copy of the downloaded file in the buyer's own systems where the licence permits keeping such a copy, verifying that the file is complete before installation, and following the product's installation instructions. A download that is interrupted by the buyer's connection should be retried from the account. Repeated download difficulty should be reported with details of the browser, device and any error message shown, so that support can test the link and the file.

7. Invoice delivery

An invoice for a store order is delivered electronically. It is sent by email, made available inside the buyer's account for download, or both, depending on the store configuration for the order type. The invoice records the order, the buyer details supplied for billing, the product or plan purchased and the payment position as recorded by the store.

The buyer is responsible for supplying accurate billing details at checkout if the invoice must show a particular legal name, address for billing records or tax identifier. If an invoice contains an error because the details supplied at checkout were wrong, the buyer should contact BizSensei Digital promptly with the order number and the correct details. BizSensei Digital will correct invoices where correction is proper and permitted, and will explain where a correction cannot be made retrospectively because of accounting or tax rules that apply to the original document.

8. Buying as a guest and buying with an account

The store checkout may, from time to time, allow a purchase to be completed with checkout details supplied for that order, and it may also create or use a store account as part of the purchase flow. The precise behaviour is as presented at checkout. In general words, where an account is created or used, the delivered licence, downloads and invoices are attached to that account and the buyer should sign in with the same email address to see them. Where a guest style checkout is offered and used, the delivery email becomes especially important, and the buyer should retain it carefully; an account may still be created from the order details to hold the licence, as the checkout explains.

A buyer who has purchased before should use the same email address for later purchases where continuity of licences, renewals and account history matters. Using several different email addresses fragments the buyer's own records across several accounts and is a common cause of the mistaken belief that a licence was not delivered, when it was delivered to the account created with a different address.

9. OMS billing purchases through the store

Where OMS plans, renewals or add-ons are purchased or billed through the store, delivery consists of the confirmation and invoice, plus the activation or continuation of the OMS entitlement on the relevant workspace. The provisioning detail for OMS is in Part F. The store record and the OMS workspace must be linked by the account and order information, and a buyer who completes an OMS billing purchase but does not see the plan reflected in the workspace should contact support with the order number so that the link between payment and provisioning can be checked and completed.

Renewal delivery is continuity delivery: the plan continues, the workspace remains active, and the confirmation and invoice are the new documents delivered for the renewal period. A renewal that fails at the payment stage does not deliver a new period, and any grace, suspension or expiry behaviour for the workspace is governed by the OMS terms and by the communications sent about the renewal, not by this delivery policy alone.

10. Add-ons and bundled entitlements

An add-on is delivered by recording the add-on entitlement against the buyer's licence, account or workspace and, where the add-on is a downloadable component, by making that component available in the same way as other downloads. A bundle is delivered as its components: each licence, download and entitlement in the bundle is generated and recorded, and the buyer should check the account and the delivery email for the full set. If one component of a bundle appears to be missing, the buyer should report the order number and the missing component so that the bundle record can be checked as a whole rather than as unrelated orders.

11. Store delivery problems: specific remedies

For store orders, the most efficient remedy path is as follows. First, sign in to the store account with the checkout email address and look for the licence, download and invoice. Second, search the mailbox, including spam and promotions, for the confirmation and delivery emails. Third, if the items are genuinely absent, email info@bizsensei.co.in with the order number and state whether the account was checked and what was found there. Support will check the order log, payment status, licence generation record and email log, and will re-deliver, regenerate links, correct an email address after checks, or complete a provisioning link that failed, as the facts require.

A charge recorded by a payment provider is not, without a confirmed store order, proof that store delivery was due, because a payment may have failed at reconciliation, been reversed, or been taken for an order that was not completed. That is why the order number and the store record matter. BizSensei Digital will nevertheless investigate a payment that a buyer believes was taken without a corresponding order, and will address any amount genuinely due back through the refund arrangements that apply.

12. Store account closure and delivery history

Re-delivery and account based download access depend on the store account existing. If a buyer asks for an account to be closed or deleted, the buyer should first download and securely retain licence keys, invoices and files that the buyer will still need, to the extent the licence permits retaining them. After closure, BizSensei Digital may be unable to provide account based re-delivery, although order and accounting records that must be retained by law will be retained as required. Licence consequences of account closure are governed by the licence terms for the product concerned.

Part D: BizSensei Agency

Applies to: BizSensei agency services

1. Nature of agency delivery

BizSensei Digital provides agency services in areas such as performance marketing, web development, search engine optimisation, retention work, content, social and influencer related work, branding support and consulting, as described in the proposal or agreement for each engagement. Agency delivery is the handover of work product and the performance of services. It is not the shipment of goods. Every agency deliverable is transferred electronically or performed online, and this Part explains how that handover works.

Services are delivered per the timelines in the proposal or agreement. That sentence is the governing rule for agency scheduling. A website statement about a typical project, a conversation about an hoped for launch date, or an example timeline in a portfolio item does not replace the written schedule for the client's own engagement. If no specific timeline is written for a particular deliverable, BizSensei Digital will deliver it within a reasonable period, taking into account the scope of the work, the information and access the client needs to provide, and any dependencies identified during the engagement.

2. The engagement documents as the delivery map

For each agency engagement, the proposal, quotation, statement of work or written agreement is the delivery map. It identifies the deliverables, the formats, the milestones, the review process, the number or nature of revision rounds where revision rounds are included, the dependencies on the client, and the acceptance process. The client should read that document as the authoritative description of what will be delivered and when. If the client believes a deliverable discussed in conversation is missing from the written document, the client should raise it before the work begins so that the document can be corrected; delivery obligations are assessed against the written engagement record.

Changes requested after the engagement document is agreed are changes to the delivery map. A change may affect scope, timeline and cost. BizSensei Digital will confirm a material change in writing before treating it as part of the agreed delivery, so that both sides share the same understanding of what is now due and when.

3. Handover channels

Agency deliverables are handed over through the channels agreed for the engagement. The channels ordinarily used include the following, alone or in combination.

• Email for documents, reports, copy, creative files of suitable size, approvals and formal handover notices.
• Shared drive or shared folder for larger files, asset libraries, video or design source material where included, and collections of deliverables that need organised storage.
• Code repository for website, application and software development deliverables, including commits, branches, releases and deployment related code.
• Staging links for review of websites, landing pages and applications before production release, so that the client can review work in a realistic environment.
• Production deployment where the engagement includes launching the work on the client's live website, hosting, advertising account, content system or other live environment.
• Advertising, analytics and platform accounts where the deliverable is work performed inside a platform, such as a campaign structure, an optimisation change or a report drawn from the platform.
• Meetings and screen sharing for walkthroughs, training and presentation of deliverables, supported by a written handover through one of the durable channels above so that a record exists after the meeting ends.

A deliverable is handed over when it is sent, uploaded, committed, deployed or made available through the agreed channel and the client is notified or given access. The client is responsible for maintaining access to the client's own email, drive, repository organisation and platform accounts, and for telling BizSensei Digital promptly if a handover link or invitation cannot be accessed.

4. Formats of deliverables

Deliverables are supplied in the formats stated in the engagement document. Where no format is stated, BizSensei Digital will supply a format that is ordinarily suitable for the purpose of the deliverable, such as a document format for written work, common image or video formats for creative work intended for publication, and working code in a repository for development work.

Source files are supplied only where the quote includes them. For example, editable design source files, raw video project files, unflattened artwork or development source beyond the deployed work are deliverables only if the engagement document lists them or the nature of the engagement plainly includes them, such as a development engagement where the repository is the deliverable. A client who needs source files should ensure they are listed before the engagement begins. Where source files are included, they are handed over through a suitable channel at the stage stated in the engagement document, which may be on final payment or on final acceptance where the document so provides.

Third party stock assets, fonts, plugins and licensed components used inside a deliverable remain subject to their own licences. Delivery of a finished deliverable does not transfer a third party licence that BizSensei Digital does not own, and the client may need the client's own licence for certain fonts, stock material or tools if the client wishes to edit or reuse the underlying assets independently.

5. Milestones, drafts and staged delivery

Many agency engagements are delivered in stages: discovery outputs, concepts, drafts, revised versions, staging builds, campaign structures and final versions. A draft or staging version is a delivery for review purposes, not a final delivery, unless the handover message states that it is final. The client should review drafts in the context for which they were supplied and give consolidated feedback, so that revision work can proceed efficiently.

Staged delivery protects both sides. The client sees work early enough to correct direction, and BizSensei Digital receives the approvals needed to proceed. If the client does not respond to a staged delivery, later stages may be delayed, because proceeding without a required approval could waste work. Delivery timelines that depend on client feedback pause fairly while feedback is awaited, and BizSensei Digital will identify the approval that is awaited when it follows up.

6. Acceptance windows and acceptance by use

Acceptance is the point at which the client confirms, expressly or by the operation of the engagement document, that a deliverable is accepted. Acceptance windows apply per the written quote: the client reviews and requests revisions within the window stated in the quote. BizSensei Digital does not impose a single acceptance period in this policy, because the right period depends on the deliverable, and the quote for the work is the document that states it.

Where the quote so provides, silence and use of the deliverable count as acceptance. That means that if the stated window passes without a revision request or a notice of non-conformity, or if the client publishes, deploys, campaigns with or otherwise uses the deliverable as a final work product, the deliverable may be treated as accepted under the quote. A client who needs more time to review should ask before the window expires; BizSensei Digital will consider a reasonable extension request in good faith, taking into account the stage of the engagement and any launch commitments.

Acceptance does not waive a client's rights in respect of a defect that could not reasonably have been discovered during the review window and that is reported promptly after discovery. It does mean that subjective change requests, new requirements and expansions of scope raised after acceptance are treated as new work or as a change, rather than as a failure of the original delivery.

7. Revisions and re-delivery of agency work

Where revisions are included in the engagement, revised deliverables are re-delivered through the same or a similar channel as the original handover, with the changes identified in the covering message where that is practical. The engagement document states the revision scope. Revisions correct and refine the delivered work within its agreed concept and scope; they are not a mechanism for replacing the agreed concept with a new one without a change agreement.

If a deliverable is rejected as non-conforming, the client should state the respects in which it does not conform to the engagement document, with enough specificity for the problem to be fixed. BizSensei Digital will correct a genuinely non-conforming deliverable and re-deliver it. General dissatisfaction without a link to the agreed scope will be discussed in good faith, and BizSensei Digital will explain what can be corrected within the engagement and what would be a change.

8. Client dependencies and delivery pauses

Agency delivery frequently depends on the client: brand assets, product information, approvals, legal copy, access to hosting, domain, advertising, analytics and content systems, introductions to third parties, and timely feedback. The engagement document may list these dependencies expressly, and other obvious dependencies may arise during the work.

Where a dependency is awaited, the delivery schedule for the affected work pauses to the extent of the dependency, and BizSensei Digital is not in breach for delay caused by waiting for material or access that only the client can supply. BizSensei Digital will tell the client what is awaited, why it is needed, and what will happen when it arrives. When the dependency is supplied, work resumes within a reasonable period, taking into account work already scheduled for other clients in the intervening period. A client who anticipates a delay in supplying a dependency should warn BizSensei Digital early so that sequencing can be adjusted.

9. Hosting, domains and renewals: the client's duty

Unless a care plan or management arrangement expressly says otherwise, hosting and domain renewals are the client's duty. The client's website hosting, domain registrations, email hosting, premium plugin licences held in the client's own name, advertising accounts and other third party subscriptions that belong to the client must be renewed by the client, with the relevant providers, before they expire.

Expiry consequences are the client's. A lapsed domain can take a website and email offline and can, in a serious case, be registered by another person after the applicable expiry process. Lapsed hosting can remove a website from the internet and may lead to loss of files or data held only with that host. Lapsed licences can disable features. BizSensei Digital is not liable for those consequences where renewal was the client's duty.

BizSensei Digital reminders about renewals, where given, are a courtesy. A courtesy reminder does not transfer the renewal duty, does not guarantee that a reminder will be given for every asset, and does not create liability if a reminder is missed, sent to an old contact address or overlooked by the client. Where BizSensei Digital manages renewals under a care plan, the care plan document states the assets covered, and only those assets are within the managed renewal scope.

10. Care plans and ongoing services

Where a client holds a care plan, maintenance arrangement or retainer, delivery under that arrangement is ongoing performance rather than a single handover: updates applied, backups or monitoring performed as the plan describes, small tasks completed, reports issued and support provided. Each task or report under the plan is delivered through the channel stated in the plan or used in practice between the parties. The plan document governs what is included; this policy governs how delivery and handover are treated.

Ongoing marketing and optimisation services are delivered by performance inside the relevant platforms and by the reports, recommendations and communications provided under the engagement. There is no single final file for a service of that kind, and the absence of a downloadable deliverable does not mean the service was not delivered.

11. Third party platforms and approvals

Some agency deliverables depend on third party review or approval, such as advertising platform review, app or listing review, or a payment, domain or hosting provider process. BizSensei Digital will prepare and submit work properly and will respond to reasonable review queries within the engagement scope, but the timing and outcome of a third party review are outside the control of BizSensei Digital. Delivery of the prepared work to the platform is the agency delivery event; the platform's approval is a separate event, and timelines in the engagement document should be read with that distinction in mind.

12. Migration assistance

Where an engagement includes moving a website, content, data or a service from one provider, host or platform to another, or where a client leaves and requests migration assistance that BizSensei Digital agrees to provide, the scope of migration assistance is reasonable assistance. Reasonable assistance ordinarily includes providing an export or copy of the client's deliverables and data that are held by BizSensei Digital for the client, in the export formats reasonably available from the systems concerned, within a reasonable period after the request and after any amounts properly due for the work are settled as the engagement document requires.

Export formats depend on the system. Website work may be provided as files and a database export; content may be provided as documents or structured exports; reports and creative work may be provided as the files originally delivered. BizSensei Digital does not promise to convert material into every format a receiving provider might prefer, to rebuild work inside a new provider's proprietary system, to provide indefinite transition support, or to supply material that belongs to BizSensei Digital or to third parties, such as internal tools, templates owned by BizSensei Digital, licensed stock or another client's material. Those exclusions are stated so that the client can plan a migration realistically and raise any special format or transition need early, while BizSensei Digital will cooperate fairly and will not withhold the client's own deliverables or data in order to obstruct a move.

13. Delivery records for agency work

Agency delivery is evidenced by the handover emails, shared drive records, repository history, deployment logs, platform change history, meeting notes and acceptance correspondence for the engagement. Both parties should retain those records. A client who believes a deliverable was not received should say so promptly after the handover was due, so that the record can be checked and the file or link re-sent while the engagement is active and the material is readily at hand.

Part E: Blog

Applies to: blog.bizsensei.co.in

1. The blog delivers nothing for purchase

The blog at blog.bizsensei.co.in is the content hub for BizSensei Digital. It publishes articles, guides, explainers, commentary and resources for readers. Nothing is sold on the blog for delivery under this Part, and nothing is delivered on the blog in the sense of a purchased product. A reader does not place a delivery order by visiting the blog, reading an article, bookmarking a page or following a link.

Where an article discusses a product or service, describes a feature, or links to the store, the main website, the OMS portal or another property, the purchase and delivery of that product or service, if the reader chooses to buy it, happen on the destination property and are governed by the Part of this policy that applies to that property. The blog article itself is not an order confirmation and does not generate a licence, a download or a workspace.

2. Article access

Article access is immediate on the website. When an article is published, a reader with internet access and a suitable device can read it by visiting its page. There is no dispatch, no waiting period and no delivery confirmation for article access. If an article is updated, the updated version replaces the earlier version on the website, and a reader who returns to the page will ordinarily see the current version. If an article is corrected, archived or withdrawn, access to the earlier version may cease, and no delivery right in the earlier version arises from having read it.

Links inside articles are provided for convenience and for further reading. Following a link to an external website takes the reader outside the BizSensei Digital properties, and any delivery, purchase or download on an external website is a matter between the reader and that website's operator.

3. Newsletter delivery by email

The blog may offer a newsletter or email subscription for new articles, summaries, resources or updates. Newsletter delivery is by email to the address supplied by the subscriber. A subscription begins as the signup process describes, which may include a confirmation step to verify that the subscriber controls the email address and genuinely wishes to subscribe. The confirmation message, where used, is itself a delivery communication, and the subscriber should complete it promptly if subscription is wanted, because an unconfirmed address may receive no newsletters.

Newsletters are sent according to the publishing and mailing rhythm chosen by BizSensei Digital from time to time. No fixed number of newsletters in a period is promised unless a specific signup page states such a promise. A newsletter that is sent to the subscriber's address is delivered for the purposes of this policy when it is sent into the mail system addressed to that subscriber, applying the general electronic delivery principles in Part A. Spam filtering, mailbox rules and provider delays on the subscriber's side can affect whether the subscriber sees a particular issue, and a subscriber who stops seeing issues should check filtered folders and whitelist the sender before assuming that sending has stopped.

4. Unsubscribing stops delivery

Unsubscribing stops delivery of the newsletter. Every newsletter provides an unsubscribe route, and a subscriber may also write to info@bizsensei.co.in to ask for removal. When an unsubscribe is processed, future newsletters will not be sent to that address for that subscription. An unsubscribe may not recall a newsletter that is already in preparation or already in transit through mail systems at the moment the request is processed, and the subscriber may receive that one issue, but no further issues should follow for that subscription once processing is complete.

Unsubscribing from the blog newsletter affects only that newsletter subscription. It does not cancel a store account, an OMS subscription, a service engagement or transactional delivery emails for purchases, because those are separate relationships with their own communications. A person who holds several relationships with BizSensei Digital and wishes to change communications for each of them should address each relationship, or write to BizSensei Digital explaining the full position so that the request can be applied correctly.

5. Downloads and resources offered through the blog

An article may offer a checklist, template or other resource for download or by email. Where a resource is downloaded directly from the page, delivery is complete when the file is made available and the reader downloads it. Where a resource is offered by email, the reader must supply a working email address controlled by the reader, and delivery follows the same principles as other email delivery in this policy, including checking spam folders and contacting BizSensei Digital if the resource genuinely does not arrive. A free resource offered through the blog carries no charge and no ongoing update delivery promise unless the offer page expressly states one.

6. Comments, submissions and reader material

If the blog accepts comments, questions or submissions, submitting material is a sending by the reader to BizSensei Digital, not a delivery by BizSensei Digital to the reader. Moderation may delay or prevent publication of submitted material, and no reader acquires a right to have submitted material published or retained. Any response to a submission, where given, is delivered by the channel through which the response is sent, ordinarily email or publication on the blog itself.

7. No reliance on blog content as a delivered professional product

Blog content is general information and opinion for a broad readership. It is not a service deliverable prepared for a particular reader's circumstances, and it is not delivered as professional advice for a specific transaction, filing, campaign or technical implementation. A business that needs work product it can rely on for its own situation should engage BizSensei Digital under Part D or purchase the relevant product under the applicable Part, so that the deliverable, scope and timeline are defined in writing.

Part F: BizSensei OMS

Applies to: BizSensei OMS: portal, apps and marketplace

1. Two kinds of delivery inside OMS

BizSensei OMS involves two entirely different kinds of delivery, and keeping them separate is essential to understanding this Part. The first kind is electronic delivery of the OMS software itself to restaurants and businesses that subscribe to it: provisioning of a workspace, activation of a plan, invitations for staff, and ongoing access through the portal and the applications. The second kind is marketplace food delivery: a customer orders food from a restaurant through the ordering technology, and the restaurant or its delivery partner physically carries that food to the customer. BizSensei Digital performs the first kind of delivery. BizSensei Digital does not perform the second kind. BizSensei provides ordering and tracking technology and customer support only for marketplace orders.

Clauses 2 to 11 of this Part govern OMS software provisioning and ongoing software delivery. Clauses 12 onwards govern the marketplace. A restaurant reading this Part for its subscription should focus on the provisioning clauses and on the marketplace clauses that describe the restaurant's own delivery responsibilities. A marketplace customer should focus on the marketplace clauses, while remembering that BizSensei Digital's role throughout is technology and support, not cooking, carrying or handing over food.

2. What OMS is, for delivery purposes

BizSensei OMS is hosted software for restaurant and food business operations, provided through a portal, with associated applications for different roles in the business and with a customer facing ordering and marketplace experience. Because OMS is hosted, its core delivery model is provisioning and access rather than file download. The customer receives a working workspace with the purchased plan active, rather than a parcel or, for the core service, an installer package.

Ancillary OMS items may be delivered in other electronic forms described in this policy, such as confirmation emails, invoices, licences for related plugins where those are part of the purchase, and downloadable resources or applications distributed through the channels notified for them. Each ancillary item is delivered by the method described for that item in Part A or Part C, as applicable.

3. Account provisioning delivery for OMS onboarding

OMS onboarding delivery is the process by which a new OMS customer moves from a confirmed purchase or approved signup to a usable operational workspace. Account provisioning delivery includes, as applicable to the plan and purchase concerned, the following elements.

• Workspace created. A dedicated OMS workspace or restaurant account is created for the business, identified by the business details supplied during signup or billing.
• Plan activated. The purchased plan is activated on the workspace, with the features, limits and entitlements of that plan made available for use.
• Branches as purchased. Branch or outlet capacity is set up as purchased, so that the workspace reflects the number and structure of branches included in the plan or quote.
• Admin invitation. An invitation, credentials or activation link is sent to the owner or administrator nominated by the business, so that the business can sign in, set its password and take control of the workspace.
• Core configuration. The initial configuration steps that BizSensei Digital performs as part of standard onboarding are completed or opened for the business to complete inside the portal, as the onboarding guidance describes.
• Import assistance within scope. Data import assistance is provided to the scope included in the plan or quote, as further described in this Part.
• Training or walkthrough where included. A training session, walkthrough or orientation is provided where the plan or quote includes it, delivered online through the channel arranged during onboarding.

Provisioning delivery is complete when the workspace exists, the plan is active, and the administrator invitation or credentials have been sent to the nominated administrator, together with any further onboarding elements that are due at the initial stage under the plan or quote. Later configuration that the business performs itself inside the portal, such as adding the full menu, setting staff rosters or refining operational preferences, is use and setup by the business after delivery, not a condition of provisioning delivery being complete, unless the onboarding agreement expressly makes a particular item a BizSensei Digital delivery duty.

4. Provisioning timelines and dependencies

Automated provisioning may complete within minutes of payment confirmation or approved signup, where the journey is fully automated and no manual step is required. Provisioning that requires manual verification, branch structuring, data import, configuration assistance or training scheduling will take the time reasonably needed for those steps, as communicated during onboarding. If a specific provisioning time is promised in a billing page, proposal or onboarding message for a particular purchase, that promise governs that purchase.

Provisioning depends on accurate business information. The business must supply its correct legal or trading name as required by the signup, a working email address for the administrator, the branch information needed for setup, and any data files for import in a usable form. An invitation sent to a misspelled administrator address cannot be used by the business, and the remedy is correction and re-sending after checks, applying the general principles in Part A. A business that changes its nominated administrator during onboarding should notify BizSensei Digital immediately so that invitations are not left active for the wrong person.

5. Administrator credentials, staff access and security

Delivery of administrator access is a sensitive delivery. The administrator who receives the invitation or credentials is responsible for setting a strong password, for controlling further invitations to managers, staff, cashiers, kitchen users, riders and other roles inside the business, and for removing access promptly when a person leaves or changes role. BizSensei Digital delivers access to the nominated administrator; the internal distribution of access inside the business is the business's own responsibility.

Staff, branch and rider accounts created by the business inside OMS are created under the business's administration. If a staff member does not receive an invitation generated through the portal, the administrator should check the address entered, check whether the invitation was filtered, and use the portal's resend or correction tools where available, or contact support with the workspace details if the problem persists.

6. Import assistance scope

Import assistance, where included in the plan or quote, means reasonable assistance to bring the business's existing operational data, such as menu items, categories, prices as supplied by the business, branch details, tables, staff records or customer data, into OMS from files or records that the business supplies in a usable format. The scope is the scope stated in the plan or quote: the data types, the volume or branches covered, the source format expected and the stage at which import help is provided.

Import assistance has natural limits. BizSensei Digital is not responsible for the accuracy of the business's source data. Prices, item names, tax treatments, opening hours and other business facts contained in source files remain the business's facts, and the business must review the imported result before using it operationally. Assistance does not include reconstructing data the business does not have, cleaning large volumes of inconsistent records beyond the agreed scope, obtaining data from a previous provider that will not release it, or guaranteeing that a proprietary format from another system can be converted without loss where the format is undocumented. Any such extended work, if agreed, is a separate scope with its own timeline.

The business must verify imported records before live use. Operational use of unverified imported data, for example taking orders against a menu whose prices were never checked after import, is a risk the business controls through its review. BizSensei Digital will correct import errors that it introduced and that are reported promptly, in accordance with the support arrangements for the plan.

7. Training and walkthrough delivery

Where a plan or quote includes training or a walkthrough, that training is delivered online at a scheduled time through a meeting or screen sharing channel, or through guided material supplied for the business to work through, as the plan or onboarding arrangement describes. Delivery of training is complete when the scheduled session is held or the guided material is supplied, as applicable. If the business does not attend a scheduled session without rearranging it in advance, BizSensei Digital will try to reschedule fairly, but repeated non-attendance may exhaust the training included in the plan, and additional sessions may be chargeable where the plan or quote so provides.

Training teaches use of OMS. It does not transfer responsibility for the business's operations to BizSensei Digital. Menu decisions, pricing, staffing, food safety, licensing of the food business and service to the business's own customers remain the business's responsibilities at all times.

8. Applications delivery

OMS related applications for owners, staff, customers and riders are distributed through the channels notified for each application, such as a download page, a direct application package provided by BizSensei Digital, or an application store where an application is listed. Delivery of an application consists of making the current release available through the notified channel for devices that meet the stated requirements. Installation on the user's device, granting of device permissions such as location or notifications, and maintaining a compatible operating system version are the user's responsibilities.

An application is a client for the hosted service. Delivering an application does not by itself deliver a subscription; the workspace, plan and account determine what the application can access. A rider or customer application connected to a restaurant or workspace will show the information that the relevant business and orders provide through the service.

9. Service updates, maintenance and availability

OMS is hosted software, and updates arrive as service updates. BizSensei Digital deploys fixes, improvements and features to the hosted service, and they become available to workspaces as part of the service, without a separate download delivery for the core portal. Where an application update is required to use a new service feature, the update will be made available through the application channel and the need for it will be communicated in the application, by email or through support.

Maintenance windows, incidents and provider outages can affect access to OMS and can pause dependent delivery processes, applying Part A. For a live restaurant operation, BizSensei Digital understands that availability matters acutely during service hours and works to restore incidents promptly. Availability commitments, if any specific commitment applies to a plan, are as stated in the plan or service terms for OMS; this delivery policy does not create an availability percentage promise where the plan does not state one.

10. Plan changes, renewals and expiry

A plan upgrade is delivered by activating the higher plan entitlements on the workspace and confirming the change to the business. A plan downgrade takes effect as the billing terms for the change provide, and delivery consists of adjusting the entitlements from that effective point. A renewal is delivered by continuing the plan for the new period and issuing the confirmation and invoice for that period. If a subscription expires or is suspended under its terms because payment is not made, loss or restriction of access following that process is not a delivery failure; it is the operation of the subscription terms. Reactivation after a payment is completed is a provisioning delivery and will be completed promptly after confirmation, with the workspace data position as described in the OMS terms and in any reactivation communications.

11. Leaving OMS and export

Where a business leaves OMS, data export and transition are handled under the OMS terms and, in delivery terms, by reasonable assistance of the kind described for migration in Part D: exports or copies of the business's data in the formats reasonably available from OMS, provided within a reasonable period and subject to the account being in the state required by those terms. The business should request exports before access ends, download them promptly, and verify that the exported files open correctly. After the retention period stated in the OMS terms or communicated on closure, workspace data may be deleted, and re-delivery of exports may no longer be possible.

12. Marketplace: roles and the central rule

The OMS marketplace and ordering experience allows customers to browse restaurants, view menus, place orders, pay where online payment is offered for the order, and track order progress. The central rule of marketplace delivery is simple and is repeated here so that no customer can reasonably misunderstand it: delivery on the marketplace is by the restaurant or its delivery partners, never by BizSensei. The restaurant prepares the food, the restaurant or its chosen delivery partner carries it, and the handover at the customer's door or collection point is performed by the restaurant side, not by BizSensei Digital.

BizSensei Digital is not a restaurant, not a food delivery fleet and not a courier company. It does not employ or supply the riders who carry marketplace orders unless a specific restaurant arrangement states a different operational fact outside this policy, and even then the customer facing delivery responsibility described at checkout and in the order flow is the governing description for that order. A customer must not attend any BizSensei Digital address, and no such address is published for order collection, because there is no BizSensei Digital collection point for marketplace food.

13. Marketplace order flow, step by step

A marketplace order moves through a defined flow, and each stage is time stamped in the system so that the customer, the restaurant and support can see what happened and when. The stages are as follows.

1. Order placed. The customer submits the order with the items, the fulfilment choice, the delivery address where delivery is chosen, contact details and any instructions the ordering interface accepts.
2. Confirmed. The restaurant confirms that it accepts the order. Until confirmation, the order is a request that the restaurant may accept or decline, for example because an item is unavailable or the kitchen cannot take the order. The confirmation event is time stamped.
3. Preparing. The restaurant prepares the order. The system records the move into preparation, and any preparation estimate is updated as the restaurant provides information or as the system's rules estimate progress.
4. Ready. The order is prepared and packed and is ready for dispatch with a rider or for collection, according to the fulfilment choice. The ready event is time stamped.
5. Dispatched. For delivery orders, the order leaves the restaurant with the restaurant's rider or delivery partner for the journey to the customer. The dispatch event is time stamped, and tracking, where available for the order, follows the order from this stage.
6. Delivered. The order is handed over to the customer or to the person receiving it at the delivery address, or the delivery is otherwise completed in accordance with the delivery instructions and any delivery code process for the order. The delivered event is time stamped and ordinarily closes the delivery flow.

Additional or intermediate statuses may be shown for particular restaurants, areas or order types, such as a rider assigned stage or an out for delivery label that corresponds to dispatch. The substance is the same: each meaningful transition is recorded with a time, and support will use those records, together with the restaurant's account of events, if a delivery question or dispute arises. A time stamp records when a status was entered in the system; where a restaurant updates a status late, support will consider all available evidence fairly rather than treating a single time stamp as the whole story.

14. Delivery areas

Delivery areas are set by each restaurant. A restaurant decides the localities, zones, distance or addresses it serves, the fulfilment choices it offers for each area, and any order conditions that apply within its area configuration. An address that is deliverable for one restaurant may not be deliverable for another, because each restaurant sets its own area according to its location, kitchen capacity and rider arrangements.

The ordering interface will ordinarily indicate, before payment, whether the customer's address is within the selected restaurant's delivery area for the chosen order. A customer should use an accurate, complete delivery address, including locality, landmark or building details where the interface allows them, and a reachable phone number. An order placed for an address outside the restaurant's area, using an inaccurate pin or an incomplete address, may be declined, delayed or impossible to complete, and the restaurant and support will address the consequences fairly on the facts, applying the refund arrangements that govern the order.

15. Delivery estimates

Delivery estimates are good faith predictions, not guarantees, shown before payment. An estimate is generated from the information available at the time, such as the restaurant's preparation pattern, distance, rider availability, current order load and ordinary travel conditions. It is shown before payment so that the customer can decide, with that information, whether to place the order on that basis.

Because an estimate is a prediction, the actual delivery time may be earlier or later. A difference between the estimate and the actual time is not, without more, a breach by the restaurant or by BizSensei Digital. Where delays become significant, the order tracking and status updates are the customer's source of current information, and support can be contacted if tracking appears stalled or if the restaurant needs to be reached about the order. Estimates may update during the life of the order as conditions change, as described in this Part.

16. Delivery code and handover

A delivery code may be used at handover. Where the order uses a delivery code, the customer will receive or be shown a code for the order through the ordering experience, and the customer must provide that code to the rider at handover so that completion can be verified. The customer must keep the code confidential until handover and must give it only to the rider who arrives with the order. Providing the code is treated as confirmation that handover to the person providing the code was authorised, so a customer should not share the code in advance by message to any person who asks for it before arrival.

Where no delivery code is used for an order, completion may be recorded by the rider or restaurant through the application or system, by customer confirmation in the ordering experience, or by another completion step shown for the order. The customer or the receiving person should check, at handover and in the presence of the rider where practical, that the order received corresponds to the order placed, and should report any missing or incorrect item promptly through support so that the restaurant can remedy it in accordance with the arrangements governing the order.

17. Food safety and quality in transit

Food safety in transit is the restaurant's responsibility. The restaurant is responsible for preparing food hygienically, packing it suitably for transport, maintaining appropriate handling before dispatch, choosing suitable delivery arrangements, and complying with the food safety and licensing laws that apply to the restaurant's own business. BizSensei Digital does not prepare, pack, inspect or carry the food and therefore does not assume the restaurant's food safety duties.

A customer with an allergy, dietary requirement or food safety concern should read the menu information carefully, use any allergy or instruction facility provided in the ordering experience, and contact the restaurant or support before ordering if the information available is insufficient for a safe decision. Menu descriptions are provided by restaurants, and a customer who needs certainty about an ingredient should obtain it from the restaurant rather than relying on a general description.

18. Delays: weather, traffic, festivals and kitchen load

Delays happen in physical food delivery in a way they do not happen in electronic delivery. Weather that makes roads slow or unsafe, traffic congestion, road closures, festivals and processions that change movement in an area, public events, and heavy kitchen load at peak times can all extend preparation and travel beyond the original estimate. These are ordinary realities of local food delivery, and both restaurants and customers should read estimates with them in mind.

When a delay factor becomes apparent, estimates update. The restaurant may update preparation information, dispatch may occur later than first predicted, and tracking may show a revised expectation. BizSensei Digital's technology displays the best current information provided through the system; it cannot create a rider, clear traffic or reduce a kitchen queue. Support will communicate honestly about a delayed order, will contact or facilitate contact with the restaurant where needed, and will apply the cancellation and refund arrangements that govern the order where a delay becomes so extensive that those arrangements are engaged. A customer who no longer wishes to wait should contact support promptly rather than refusing handover without notice, so that the order's status and any refund position can be handled correctly.

19. Takeaway, dine-in and platform delivery are distinct

Takeaway and dine-in are distinct from platform delivery. A takeaway or collection order is prepared by the restaurant and collected by the customer at the restaurant; no rider journey is involved, the ready status is the key signal, and the customer should attend the restaurant at or after the indicated readiness time with the order details. A dine-in experience takes place at the restaurant under the restaurant's own arrangements; technology may assist with ordering or billing at the table where the restaurant uses those features, but there is no delivery journey at all. Platform delivery, by contrast, involves dispatch and a rider journey to the customer's address and ends with handover at that address. The customer's duties, the applicable charges or conditions shown at checkout, and the way problems are remedied differ between these fulfilment types, and the customer should select the type that matches what the customer actually wants for that order.

20. Customer duties for marketplace delivery

For marketplace delivery to succeed, the customer must provide an accurate delivery address within the restaurant's area, a reachable phone number, and any access instructions needed for the rider to reach the handover point, such as building, gate or floor information that the interface accepts. The customer must be available at the address during the delivery window suggested by the estimate and tracking, must respond to reasonable rider calls or messages about locating the address, and must provide the delivery code where one is used for the order.

If the customer is not available at the address, does not respond to reasonable contact attempts, or provided an address that the rider cannot locate after reasonable efforts, the restaurant's delivery attempt may fail. The consequences, including whether a further attempt is made and how the order is charged or refunded, are governed by the arrangements for the order and will be assessed fairly on the evidence, including the time stamped flow, contact attempts and address information supplied. A customer who realises that an address or phone detail is wrong after placing an order should contact support immediately; a correction may be possible before dispatch and may be impossible after the rider has travelled to the wrong location.

21. Restaurant duties for marketplace delivery

A restaurant using the marketplace must keep its menu, availability, opening hours, delivery areas and preparation information reasonably current in the system, must confirm or decline orders promptly and honestly, must prepare confirmed orders within a reasonable time, must pack orders securely and safely, must dispatch through its own riders or delivery partners with accurate handover to them, and must cooperate with support when a delivery question arises. A restaurant that repeatedly fails to meet these duties may face consequences under its OMS and marketplace arrangements, because reliable restaurant performance is what makes the marketplace trustworthy for customers.

Riders engaged by a restaurant or by its delivery partner are the responsibility of the restaurant or partner that engages them, including their conduct, their compliance with traffic and safety law and their handling of the order in transit. A customer who experiences a serious rider conduct problem should report it to support with the order number and a factual account, so that it can be raised with the restaurant or partner concerned.

22. What BizSensei Digital does for marketplace orders

For marketplace orders, BizSensei Digital provides ordering and tracking technology and customer support only. In practical terms, BizSensei Digital operates the systems that present restaurants and menus, take and transmit orders, process or facilitate payment where that facility is used, record the order flow with time stamps, display tracking information provided through the system, and provide a support channel through which customers and restaurants can raise delivery problems and seek resolution.

That role is important but limited. BizSensei Digital does not set a restaurant's menu prices as a seller of the food, does not prepare the food, does not guarantee a restaurant's delivery time as the carrier, and does not hold itself out as the deliverer. Support will nevertheless take delivery problems seriously: it will examine the order record, contact the restaurant where needed, explain the position honestly, and pursue the remedy that the governing arrangements provide, which may include the restaurant re-making an item, completing a failed handover, or processing a refund where the order qualifies for one.

23. Marketplace cancellations, failed delivery and refunds in delivery terms

The delivery aspects of cancellation are as follows. Before restaurant confirmation, an order may be capable of cancellation with the least friction because preparation has not begun. After confirmation and preparation, cancellation becomes a matter for the governing order arrangements and for the restaurant's position, because food prepared for a particular order often cannot be sold to another customer. After dispatch, cancellation in the ordinary sense is generally no longer possible because the delivery journey is under way. This policy states those delivery realities; the financial consequences of a cancellation or a failed delivery are determined by the refund policy and order terms that apply to the marketplace, read together with the customer's statutory rights.

Where delivery fails because the restaurant or its partner did not perform, where an order is confirmed but never dispatched, or where the wrong order is delivered and cannot be corrected, the customer should report the facts to support promptly with the order number. Support will use the time stamped record and the restaurant's account to establish what happened and will pursue the remedy provided by the governing arrangements without requiring the customer to prove matters that the system records already establish.

24. Marketplace delivery records

Marketplace delivery records include the order record, the time stamped status history, payment record where online payment was used, delivery address and contact details as supplied for the order, delivery code verification where used, rider or partner dispatch information recorded in the system, and support communications about the order. These records are the shared factual basis for resolving delivery questions and are retained and handled in accordance with the privacy and OMS arrangements that apply.

Part G: Qiaomed

Applies to: qiaomed.space

1. Pre-launch status: nothing is delivered yet

Qiaomed, at qiaomed.space, is in a pre-launch phase at the date of this version of this policy. That status has a clear delivery consequence: nothing is delivered yet. No practice account is provisioned, no subscription is active, no patient or practice service is live, and no person should treat a waitlist signup, an expression of interest, a demonstration conversation or any pre-launch communication as the delivery of a working Qiaomed service. Qiaomed is presented before launch so that interested practitioners and practices can learn about what is being built and can register interest; the service itself will be delivered only when BizSensei Digital announces its launch and completes provisioning for a customer under the launch terms.

Any date, season or expectation mentioned in pre-launch material about when Qiaomed might launch is an expectation, not a delivery commitment, unless BizSensei Digital makes a written launch commitment to a particular customer that expressly states otherwise. A person who needs a working system for a practice by a particular date should not rely on a pre-launch expectation as though it were a provisioning schedule.

2. Waitlist delivery

The only delivery that happens in the pre-launch phase is waitlist communication. When a person joins the Qiaomed waitlist or registers interest through qiaomed.space, waitlist confirmation is sent by email to the address supplied. That confirmation records that the interest has been registered. It is not an account, it carries no login to a live clinical system, and it does not reserve any particular launch price, plan or onboarding slot unless the confirmation expressly states such a reservation.

Waitlist delivery follows the general email principles in Part A. The person registering must supply a working email address that the person controls, should check spam and promotions folders for the confirmation, and should write to info@bizsensei.co.in if the confirmation genuinely does not arrive after those checks, so that the registration can be verified and the confirmation re-sent. Further pre-launch updates, where sent, are delivered by email to waitlist subscribers in a similar way. A waitlist subscriber may unsubscribe or ask for removal at any time by using the unsubscribe route in an update email or by writing to info@bizsensei.co.in; removal stops further waitlist delivery.

3. What will count as delivery at launch

When Qiaomed launches, delivery of the service to a practice will be electronic provisioning, applying the general principles of this policy with the practice specific elements described in this Part. Although the detailed launch terms will govern each customer's onboarding when they are issued, this policy records in advance what provisioning means for Qiaomed, so that prospective customers can understand the model before they commit.

At launch, provisioning means the following elements, as applicable to the plan or onboarding agreement for the practice concerned.

• Practice account creation. A Qiaomed practice account is created for the clinic, practice or organisation, identified by the practice details supplied and verified during onboarding.
• Plan or access activation. The access level, plan or trial entitlement agreed for the practice is activated on the practice account from its agreed start point.
• Practitioner invitations. Invitations or credentials are issued for the principal practitioner or account administrator and for the practitioner users included in the onboarding scope, so that each practitioner can activate personal access securely.
• Staff invitations. Invitations are issued for reception, administrative, assistant and other staff roles included in the scope, with the role based access appropriate to each invitation as configured during onboarding.
• Pharmacy onboarding. Where the practice uses pharmacy related features within the Qiaomed scope, pharmacy onboarding is completed to the extent included in the plan or agreement, including the setup of the practice's pharmacy related structure and the invitations or configuration needed for the persons who will operate those features for the practice.
• Data import assistance. Import assistance is provided to the scope described in this Part and in the onboarding agreement, for the practice data that the practice supplies for import.
• Orientation. Orientation or walkthrough material or sessions are provided where the plan or onboarding agreement includes them, so that practitioners and staff understand the core workflows before clinical use begins.

Provisioning delivery will be complete when the practice account exists, the agreed access is active, and the initial practitioner or administrator invitation has been sent, together with any further elements expressly due at the initial stage under the onboarding agreement. Configuration that the practice performs inside the service after that point, and import stages that are scheduled as later onboarding steps, are subsequent stages whose timing will be as the onboarding agreement states.

4. Practitioner and staff invitations

Qiaomed access is personal and role based. An invitation is addressed to an identified individual at an email address supplied by the practice for that individual. The practice is responsible for supplying correct names, roles and email addresses for its practitioners and staff, and for telling BizSensei Digital or using the account administration tools, as applicable at launch, when a person leaves the practice or changes role so that access can be adjusted. An invitation delivered to the address supplied by the practice is delivered for provisioning purposes even if the practice later decides that a different person should hold the role; the correction route is revocation and reissue under the account administration arrangements, not a claim that the original delivery never happened.

Each invited person is responsible for activating access promptly within any expiry period stated in the invitation, for setting secure credentials, and for keeping those credentials personal. Clinical and practice systems depend on individual accountability, and sharing a single login among several practitioners or staff would undermine both security and the audit value of the system's records. Expired invitations will be reissued to the verified individual on request by the practice administrator, applying the identity principles in Part A.

5. Pharmacy onboarding in delivery terms

Pharmacy onboarding, where included, is a setup and configuration delivery, not a delivery of medicines or physical stock. BizSensei Digital will configure the practice's pharmacy related workspace structure, categories or records as included in the scope, and will provide the access and orientation needed for the practice's authorised persons to operate those features. Qiaomed does not supply medicines, does not hold pharmacy stock for a practice, and does not ship any physical pharmaceutical goods under any circumstances. The practice's own procurement, storage, dispensing and compliance in respect of actual medicines remain entirely the practice's responsibilities under the laws that govern its pharmacy activity.

Data entered or imported for pharmacy related features, such as item names, strengths, batch or stock information supplied by the practice, remains the practice's data in substance. The practice must verify it before relying on it operationally, in accordance with the verification duty in this Part.

6. Data import assistance scope

At launch, data import assistance for Qiaomed will cover reasonable assistance, within the scope stated in the plan or onboarding agreement, to bring the practice's existing records that are within the agreed import scope, such as practice, practitioner, patient index, appointment history or inventory related records as applicable, from files or exports that the practice supplies in a usable format into the practice account. The onboarding agreement will state the record types, the source formats expected, the volume or period covered and the review process, because health related records require particular care and cannot responsibly be imported on vague instructions.

The limits on import assistance mirror the general limits in this policy and carry added weight in a health context. BizSensei Digital does not create source records the practice does not have, does not warrant the clinical accuracy of the practice's historical records, does not obtain records from another provider that has not made them available to the practice, and does not promise lossless conversion of undocumented proprietary formats. Where a format or record set cannot be imported safely or completely, BizSensei Digital will say so before or promptly after discovering the problem, will explain the options, and will not silently import partial data as though it were complete.

7. The practitioner's duty to verify imported records

The practitioner has a non-delegable duty to verify imported records before clinical use. After any import, and before the practice relies on the imported data for the care of any patient, the responsible practitioner or a suitably authorised and competent person within the practice must review the imported records, check them against the source records on a reasonable sampling or fuller basis proportionate to the risk, and confirm that they are complete and accurate enough for the use the practice intends to make of them.

This duty exists because imported data can contain errors from many sources: incomplete source exports, mismatched fields, duplicated patients, outdated information and conversion problems that only a person who knows the practice and its patients can spot. Software assistance does not replace clinical judgement about the practice's own records. A practice must not use imported records for clinical decisions until its verification is done, must correct or report discrepancies promptly, and must keep its source records available during the transition period so that verification and correction remain possible. BizSensei Digital will correct import processing errors that it introduced and that are reported with sufficient detail, but responsibility for deciding that records are fit for clinical use rests with the practitioner.

8. No physical delivery and no medical service by BizSensei Digital

For the avoidance of doubt, Qiaomed involves no physical delivery by BizSensei Digital at any stage. No equipment, medicine, document pack or device is shipped as part of Qiaomed provisioning unless a future written agreement expressly adds a physical item, in which case that agreement will state its own delivery arrangements and this Part will be updated accordingly. Qiaomed is a software and service offering. BizSensei Digital does not provide medical care, does not employ the practitioners who use the service in their practices, and does not deliver any clinical outcome. Delivery under this Part is delivery of software access and onboarding services only.

9. Launch communications and changes to this Part

When Qiaomed moves from pre-launch to launch, BizSensei Digital will update this Part to record the live delivery arrangements, including any provisioning timelines that apply to launch plans, and will notify waitlist subscribers and early customers of the launch through the email addresses held for them. The updated policy version will apply from its stated date. A waitlist registration made before launch does not lock the pre-launch version of this Part as the permanent delivery terms for a future subscription; the launch terms and the then current policy will govern the subscription when it begins, and they will be presented for acceptance during signup.

Closing provisions

1. Reading this policy with other documents

This Shipping and Delivery Policy is one of the legal documents for the BizSensei Digital ecosystem. It should be read together with the terms of service, the privacy policy, the refund policy, the licence terms for the product concerned, and any proposal, agreement, order confirmation or plan document that applies to a particular purchase or engagement. This policy answers delivery questions. It does not replace the refund policy on whether money is returned, the licence terms on what a buyer may do with software, or the service terms on the parties' wider rights and duties. If documents appear to conflict, the reader should contact BizSensei Digital for clarification, and any formal interpretation will give effect to a consumer's statutory rights and to the more specific document that was agreed for the transaction concerned.

2. Delivery estimates and commitments, restated fairly

Across this policy, a distinction has been maintained between estimates and commitments, and it is restated here because it is the key to reading every timeline in the document honestly. An estimate is a good faith prediction made from the information available at the time; delivery may occur earlier or later without the estimate having been dishonest or breached. A commitment is a stated outer limit or a specific promise made for a particular product, order or engagement. The standard commitment for digital product delivery is that licence keys and download links are delivered by email within 24 hours of payment confirmation, usually within minutes. Service commitments are those written in the proposal or agreement. Marketplace food estimates are predictions shown before payment and are not guarantees, because the physical journey depends on the restaurant, its partners and conditions on the day.

3. Fair dealing and re-delivery, restated

BizSensei Digital's delivery approach is built on fair dealing. Records are kept so that facts can be checked. Buyers must provide accurate delivery information and must look in the obvious places, including the account and the spam folder, before concluding that delivery failed. In return, BizSensei Digital investigates promptly, explains what the records show, regenerates expired links, corrects address errors after identity checks, re-delivers to the account holder, and always re-delivers a digital product that genuinely never arrived. No clause in this policy should be read as an attempt to keep a buyer's money while withholding the digital product the buyer paid for, and no clause excludes liability for fraud or wilful misconduct.

4. Statutory rights

Nothing in this policy excludes, restricts or modifies any right or remedy that a consumer has under the Consumer Protection Act, 2019, the Information Technology Act, 2000 or any other applicable law of India, where such exclusion, restriction or modification would be unlawful. If any provision of this policy is held to be invalid or unenforceable, that provision will be read down to the extent necessary to make it valid, or severed if it cannot be read down, and the remaining provisions will continue in full effect. Delivery obligations that arise by operation of law apply in addition to the obligations described in this policy.

5. Governing law and place

This policy and any dispute about delivery under it are governed by the laws of India. The parties will first try to resolve a delivery dispute in good faith through the support contact in this policy, using the delivery records for the order or engagement. Many delivery disputes are misunderstandings about accounts, email filtering or fulfilment roles, and they resolve quickly once the records are shared. If a dispute cannot be resolved that way, it will be handled in accordance with the dispute provisions of the terms that govern the relevant product or service.

6. Changes to this policy

BizSensei Digital may update this policy when its products, properties, delivery systems or legal obligations change. Each version will carry a version identifier and a last updated date in the introduction. A change to this policy does not undo a delivery that was completed under an earlier version, and does not reduce a specific delivery commitment that was made to a customer for a purchase already completed. Material changes that affect how existing customers receive licences, downloads, updates or provisioning will be communicated through the relevant property or by email where communication is appropriate. Continued purchase or use after an updated version takes effect will be treated in accordance with the acceptance provisions of the governing terms.

7. Contact for delivery matters

All delivery questions, failure reports, re-delivery requests, accessibility requests and marketplace delivery support requests may be sent to BizSensei Digital by email at info@bizsensei.co.in, and urgent matters may also be raised by phone at +91 93726 65745. Include the order number wherever there is one. For agency matters, include the proposal or project reference. For OMS subscription matters, include the workspace or restaurant name and the administrator email address. For marketplace orders, include the marketplace order number and the restaurant name. For Qiaomed waitlist matters, include the email address used to register. Clear references allow BizSensei Digital to find the delivery record quickly and to help without unnecessary delay.

8. Final statement

BizSensei Digital sells digital products and services only, and it delivers them electronically with care, records and a genuine re-delivery commitment. The only physical carrying in the ecosystem is food carried by restaurants and their partners on the OMS marketplace, under Part F. If anything in this policy is unclear to a reader, BizSensei Digital invites the reader to ask before purchasing, by writing to info@bizsensei.co.in, so that the delivery method for the item concerned can be confirmed in plain words in advance.

End of the Shipping and Delivery Policy of BizSensei Digital, Version 2026-10-23, last updated 23 October 2026. For questions about this document, contact info@bizsensei.co.in or +91 93726 65745.