Publishing a cloud offer is a sequence of identity, product and operational checks. A polished description helps, but it cannot compensate for an incomplete seller account or a product that does not behave as advertised. For a small UK vendor, the useful starting point is a consistent evidence pack: the legal company record, a business domain, a working application, a support contact and an explanation of what the customer will receive.
Digital Qazaqstan Ltd publishes Enterprise AI Assistant on Microsoft Marketplace. This guide explains the documented publishing route and the checks a founder should prepare. It does not present reconstructed account screens as original screenshots, or turn an individual approval into a guaranteed turnaround. The screen names below refer to Partner Center; the exact layout can change as Microsoft updates the service.
Screen 1: account settings and legal information
Start by separating the company from the individual using its account. A UK company has a legal name and registration record. A founder has an identity, a job relationship and a business email address. These are related pieces of evidence, but one does not replace the others. Create a short checklist with the company name, registered address, company number, domain and primary contact. Compare each entry with the documents you intend to submit before starting another verification attempt.
Microsoft describes independent checks for email, identity, employment and business verification. In Partner Center, use Account settings and Legal info to review the business record, then Verification Summary to inspect progress. Its verification guidance says business names and addresses should match official registration records. A different spelling, an old address or inconsistent abbreviations can create avoidable questions. A founder living abroad should distinguish a personal residential address from the company’s registered details, and supply the particular address requested by each field.
Screen 2: identity verification and evidence requests
Follow the identity-verification flow shown for the account. A verified credential may be part of that process; it is not a universal substitute for company verification. Use the named person’s current identity documents, review the requested information and record the outcome. Keep identity documents in the verification process rather than embedding them in a public article, repository or marketing presentation. A successful company listing should expose the product and publisher, not the founder’s private verification documents.
When a request for further evidence arrives, answer the actual request. Maintain a small event log containing the date, workspace, requested document, action taken and resulting status. This is more useful than repeatedly changing several account fields at once. Microsoft gives typical account-verification times in its documentation, but those figures describe that process, not every offer’s certification. Our published card is an observable outcome; it does not establish a standard review duration for another vendor.
Screen 3: choose the offer and acquisition route
A public software listing and a paid professional-services engagement solve different buyer problems. A software card explains a product. A services offer describes a scoped engagement, deliverables and commercial terms. Before opening the offer editor, write a sentence stating what the customer acquires and who bills them. That sentence should remain consistent across the title, description, landing page and support material. Do not choose an offer type simply because another company’s card looks attractive.
Microsoft’s SaaS creation guide and SaaS planning guide distinguish listing options and their technical requirements. A contact-oriented listing should not imply that Marketplace already provisions and charges for a subscription. A transactable application needs the applicable acquisition, authentication and fulfilment behaviour. Use the documentation for the option you actually selected, and test the customer’s path rather than relying on the presence of a public card.
Screen 4: professional-services properties
For professional services, make the supported software explicit. Microsoft documents services sold through private offers and particular requirements for seller markets, delivery and supported products. Its professional-service planning guide explains when a link to an associated software listing is required. Services supporting first-party Microsoft software follow a different selection and qualification path. Read those conditions before promising a customer that a services card will behave like a publicly purchasable SaaS subscription.
Write deliverables in terms a procurement team can inspect: a configuration assessment, a deployment plan, an implemented environment, a demonstration or a handover document. Identify customer prerequisites and ownership of the deployment. For an AI assistant, useful questions include where documents reside, whose cloud subscription runs the service, who controls access and what ongoing support covers. Product and service descriptions should agree about those boundaries.
Screen 5: listing details, testing and publication
Prepare the title, summary, description, support details and required assets before submission. Show the customer outcome early. Use original product images or appropriately attributed documentation images; label illustrations clearly. A diagram explaining your deployment is useful, but it must not pretend to be a screenshot of a certification screen. Review spelling, broken links and the consistency of the publisher’s public identity, especially when several brands share a founder.
The test-and-publish guide describes submission, preview and the transition to live publication. Build a test record around the selected offer type: follow the preview link, check the landing page, verify sign-in where applicable, and reproduce the documented customer outcome. Include clear certification notes when the process asks for them. Fix one concrete failure at a time and keep a dated version of the instructions supplied to the reviewer.
After the card is live
Publication creates a destination for evidence-based customer conversations. Link directly to the product card from relevant educational content, then explain what the offer actually provides. Keep support and product information current. Treat the marketplace as one part of your distribution system: readers still need useful guidance, a clear learning route and a way to decide whether the product fits their organisation. Start with our professional learning catalogue and use practical exercises to build that understanding.