Publishing guidance

Use a structured framework to decide between a SaaS offer, Azure application, container, or virtual machine offer for your solution. The choice depends on how you deliver and deploy your product:

Available offers

• SaaS offer: Ideal when you, the publisher, host the solution centrally as a service that all customers access (multitenant cloud service). Example: an AI document-processing web application that all users log into on your cloud environment. Here, the marketplace transaction just grants them access to your online service
• Azure application offer: Chosen when the solution (often a set of Azure resources) gets deployed into the customer's Azure tenant. This can be a Solution template or a managed application that might span multiple VMs, storage, etc., set up via an ARM template. Example: a packaged AI model deployment that installs a couple of VMs, a database, and functions into the customer's Azure subscription for them to run
• Container offer: Suitable if you deliver your solution as container images that the customer runs; for instance, in Azure Kubernetes Service or Container Instances in their environment. Example: an AI inference service provided as a Docker image that customers deploy in their own cluster to keep data on their side
• Virtual machine (VM) offer: Appropriate for simpler deployments that only require a single VM image. Example: a specialized AI software pre-configured on a VM (like an Ubuntu VM with your AI service running) that the customer can launch in their Azure subscription. (If your solution needs multiple coordinated VMs, that typically falls under Azure Application offer instead.)

Choosing correctly is important because each offer type has different publishing steps and customer experiences. If in doubt, err towards SaaS for cloud services or Azure apps/container for on-premises style deployments where data residency is key. Microsoft's documentation and your Software Development Company (SDC) can help if you're unsure - getting this right at the start prevents rerouting later.

SaaS for central hosting

As a rule of thumb, use SaaS if you can centrally host the agent with multitenant access. SaaS offers give the easiest customer experience (they just sign up and get access) and support both Azure Marketplace and AppSource listings. Our guide and samples primarily assume SaaS, since SaaS is common for AI services. Unless customers must run the software themselves due to compliance, SaaS is usually recommended - it offloads infrastructure management from the customer to you, the expert. It also simplifies things like updates (you update your service, all customers benefit). Keep in mind, SaaS offers require the fulfillment APIs integration we covered earlier, so ensure you're willing to do that work. The marketplace handles billing, and you handle provisioning. If multitenant SaaS fits your scenario (which it often does for AI solutions that don't need to live in the customer's network), it's likely the best path.

Azure app/container for in-tenant

Use an Azure application or container offer if the customer needs an in-tenant deployment. This is often due to data sovereignty, security policies, or network requirements. For example, a bank might require that the AI runs inside their Azure for regulatory reasons. In this case:

• An Azure application (solution template) can deploy a combination of resources (VMs, storage, AI services) into the customer's subscription through an automated template. This is good if the deployment is complex but can be templatized
• A managed application variant allows you to have some management capabilities post-deployment, but still in customer's tenant
• A container offer is more appropriate if you have containerized workloads; you supply container registry info and deployment instructions, and the customer deploys it, for instance to Azure Kubernetes Service (AKS)

These offers don't require implementing the SaaS fulfillment APIs, but they do require providing deployment assets (ARM templates, or container images + instructions). Also note: if in-tenant, marketplace can still handle the billing (with the customer's Azure subscription being charged), which is convenient. Make sure to highlight in your documentation why this model is chosen (for example, "Your data stays within your control; deploy our AI in your own cloud environment"). The marketplace listing also indicates the deployment method (for example, "Azure Kubernetes Cluster required" or similar).

Consider billing model early

Match the offer type with your intended billing model. Consider if you need license-based pricing, usage-based billing, free trials, private deals, or Cloud Solution Provider (CSP) distribution. These factors can influence offer type:

• Both SaaS and Azure app offer: Support license-based (flat rate per user or per unit), and usage-based models (via metering for SaaS, or usage scope for VMs/containers)
• Trials: SaaS and many offer types let you provide a free trial period or a free tier plan. Plan for how you'll implement trial conversions (will the service automatically downgrade or prompt the user when trial ends?)
• Private offers: The marketplace allows you to create special pricing that's only visible to specific customers (by their Azure tenant ID). If you anticipate enterprise deals with custom pricing, plan on using private offers. It means you might have a "Standard plan - $X" publicly, and a hidden plan like "Standard for Contoso - $Y" that only Contoso's tenant can see
• CSP (Cloud Solution Provider) channel: Decide if you want to enable CSP resellers to resell your solution. If yes, you need to enable the "allow Azure plan reselling" option for your plans. Be prepared to handle scenarios where a CSP manages the subscription on behalf of the customer (support interactions might be indirect)

Align these with offer type: for example, Azure VM offers might not support trials the same way SaaS does (since the cost is usage of a VM). SaaS offers are very flexible with trials and private plans. So, plot out the business needs now and ensure your offer type supports them. It's painful to realize later that a certain model isn't supported and have to fudge it.

Align to customer purchasing preferences

Ensure your business model (pricing structure and terms) meets customer expectations - monthly vs annual commitments, consumption vs fixed. For instance, many enterprise customers prefer annual subscriptions (often with a discount for committing annually) because it simplifies procurement. If your SaaS is only month-to-month, some large clients might hesitate. Conversely, smaller customers might demand monthly flexibility. You can potentially offer both (via separate plans: monthly plan vs annual plan). Consider offering volume discounts for large quantities (marketplace can handle tiered pricing to an extent, or you handle via private offers).

Also think about overages vs hard limits: If usage exceeds what's in the plan, do you charge extra (and how, via meter) or cap the usage? Make sure that's clear to the customer. All these details should be reflected in how you configure plans in Partner Center

Ultimately, designing the offer with customer expectations in mind makes your solution more attractive and reduce friction in the sales process. Engage any early adopters or friendly customers for feedback on pricing structure - ensuring it aligns with their budgeting norms can help you win deals.

Next step

• Learn about Implementation requirements