RFC-4: Request a demo feature [Resolved]

RFCs are a way for Atlassian to share what we’re working on with our valued developer community. Please respect our community guidelines: keep it welcoming and safe by commenting on the idea not the people (especially the author); keep it tidy by keeping on topic; empower the community by keeping comments constructive. Thanks!

Summary of Project:

Currently, Marketplace Partners cannot connect with actual users of their app. They can connect with Technical contact (usually the admin) and billing contact (usually the finance contact) who are often not the users of the app.

Request a demo” is a feature that will allow Partners to directly connect with the potential users of the app. This can help them to identify high-intent customers, improve evaluations, receive 1:1 feedback, and plan better for future iterations.

  • Author: 9 Feb 2023
  • Publish: 9 Feb 2023
  • Discuss: 27 Feb 2023
  • Resolve: 9 March 2023


As a business owner, our Marketplace partners like have a close connection to their customers - to onboard them better, to increase awareness of new features of the apps, to gather feedback, to offer special discounts for customer loyalty, and always remedy an unpleasant experience when someone is churning. Customers feel more connected to partners that offer either direct one-on-one interaction, especially during trial or who show them that they know their customers better

Proposed Solution

The first phase of solving this problem is to enable customers to request a demo from partners. This will enable partners to converts potentials leads to evaluators. This will help them to onboard customers better, increase awareness of new features of the apps, and will be a great enabler to gather feedback from customers.

During partner connect sessions conducted with about 6 partners, we found that most partners aligned with this and looked forward to having a way to pitch and connect with customers directly. Some partners expressed concerns regarding scaling their team to handle the requests, which is why we will be operating it through an opt-in manner where Partners can choose to opt-in per app.

Customers will be able to request a demo of apps of partners who have opted-in to provide this capability.

[Please note that these are sample screens, subject to change.]

  • Touchpoint
    • Partners who choose to opt-in for this (the decision will be done at an app level) will have a touchpoint on their app listing page, which will be visible to all users visiting. Partners can choose the specific apps for which they want to run this feature. They can also set a limit for the number of incoming demos per day for each app. During the initial launch, partners will be able to opt-in via high-touch mechanisms like signing up a google form etc.
    • We will be providing an introductory spotlight for this feature so that customers get versed with where the touchpoint is located.

  • Experience for Customers
    • Who can request a demo? Customers with a Marketplace account can choose to request a demo by providing minimal, necessary information. The aim of collecting this is to allow Partners to be able to directly reach out to the requesting personnel and have enough background to prepare a demo.
    • What is the information collected? Currently, we are focusing on getting their basic personal information, and organizational needs. We are open to your feedback regarding what information would help you better evaluate high-intent customers. In the first iteration, there will be no meeting scheduler integrated into the experience. However, based on the usage, it is on our roadmap.

  • Experience for Partners
    • All the information collected will be shared with both the partners and the customers (the same copy is shared with both parties). For partners, this will be sent to the email ID provided during the opt-in stage or to the support email, by default.
    • You can get in touch with the customers to find a common slot that works for both parties and set up a demo over any channel that works for you.

  • Feedback
    • Customers will receive an email 1 month after their request date to quantify their experience in the demo.


  • Do you think introducing a ‘Request-a-demo’ feature on your app listing could help drive better results in terms of evaluations and direct customer outreach?
  • What features or additions to this would make it easier for you to manage, schedule, track, and follow up with customers for demos?
  • If the feature were to be introduced, is your organization currently capable of meeting up with the additional requirements of conducting 1:1 with users?
  • If you are interested in a follow-up 1:1 with our team to share or know more, please leave a comment on this post and we will get back

@MalathiVangalapati thanks for the proposal!

This sounds useful for highly priced apps and/or customers in higher user tiers, however we would not consider it for lower-priced apps or small customers (e.g. <= 100-1000 users).

This would then lead to most demo requests being denied by us, which is probably not a good experience for customers.

What we could offer to all customers instead is a webinar where customers can register using this button. It would not be a “1:1 demo” as is advertised on the mockup, so we couldn’t use it for that. Maybe it could be enhanced so we’re able to adjust the text that is shown to customers? We could imagine to adjust it as follows:

  • Request a demo → Sign up for our webinar
  • Get a 1:1 demo for your team → Learn about live on Feb 20 (insert date/time here)

For automation purposes it would also be helpful if we could fetch the customer data via an API instead of receiving an email that we need to parse etc. That would allow us to automatically send them the Zoom invitation to the webinar, for example.

Thanks a lot for sharing this proposal at an early stage and allowing us to submit feedback :slight_smile:


This sounds like a fantastic idea, but I agree with Ben that if the request flow is creating a live event on someone’s calendar it could be difficult to try and scale (especially for lower priced Apps). One question/request/suggestion(?) I would ask would be if there could be an option for an intermediate step that would offer the client more “demo like” recorded content (so something more specific than just the general details currently available in the Marketplace listing). This could help to pre-qualify some of these, and if after consuming the recorded content the client is still interested in digging deeper, an option to connect with us directly would be available.


It’s an interesting idea - but I’m going to second @BenRomberg 's concern. Not sure how this will scale especially since there are a lot of folks that will ask for demos before even looking at any of the documentation or trialing the app.

It would be awesome to be able to point to a page where we can have white papers, know-before-you-try documentation etc - and from there we can lead the leads to the appropriate forms (let it be a group webinar or 1:1 sales meetings etc).



I agree with the sentiment voiced by others.

It would be great if we can have a “quick start” section in which we can list video’s, tutorials, white papers, etc to help people get started. We currently have this on our documentation pages, but it would be even better if this can even be embedded into the listing page in an Atlassian defined structured way.

Even better would be if we can provide Atlassian with “templates”, much like AWS Quick Start, which would allow users to create a test instance with the app already installed with pre-defined project setup & app configuration with the click of a button.

If you do plan to continue with this feature, I do have one request: please make it possible to integrate with Jira Service Management. We do not want to receive yet another email template from Atlassian that we will need to parse. All our demo requests currently go through our support portal, and being able to communicate with customers through this way would really make it a lot easier for us to respond.

I understand that adding JSM integration complicates the feature, but I think you will see more adoption of this feature if you allow us to centralise our customer communication. I’m pretty sure we will not opt-in unless we can have this integration, as there is no gain for us apart from the existing process.


Agree with the other replies here, we would like to put learning resources/videos in front of the customer first, we also run customer webinars every 6 weeks with live Q&A.

If those resources are not sufficient, customer should be able to request a demo.


I was a bit too quick with my reply because I focussed on what others were saying and jumped on the bandwagon. Having taken the time to read the full proposal I do have some other issues.

As a business owner, our Marketplace partners like have a close connection to their customers - to onboard them better, to increase awareness of new features of the apps, to gather feedback, to offer special discounts for customer loyalty, and always remedy an unpleasant experience when someone is churning.Customers feel more connected to partners that offer either direct one-on-one interaction, especially during trial or who show them that they know their customers better

To be honest, I cannot agree more with this problem description and I fully support Atlassian in solving this.

However, I think the proposed solution completely, utterly and monumentally fails to address this problem. The ability to request a demo does not in any way, shape or form solve:

  • have a close connection to their customers
  • increase awareness of new features of the apps
  • gather feedback
  • offer special discounts for customer loyalty
  • remedy an unpleasant experience when someone is churning

A customer demo is pre-sales. They aren’t a customer yet(!). The Atlassian Marketplace team is literally proposing a solution that does not solve the problem statement.

In addition, the team has also not included any alternative solutions that were considered that actually address these points and why they were rejected.

If the problem definition would have been created from the customer perspective as a quick means to determine product fit for their use case, I would have understood this proposed solution. Basically the last sentence:

Customers feel more connected to partners that offer either direct one-on-one interaction, especially during trial or who show them that they know their customers better

But from a Marketplace Partner perspective, the proposed solution does not in any way solve the stated problem.


Considering RFC-4 (this one) is such an early attempt to engage the community, I’m feeling good that RFCs can help with early engagement. The comments here so far seem to be pointing at a “serious flaw” in the connection between problem and solution. So most of all, I want to thank @MalathiVangalapati as our first author (other than me) to try out this process.

From the commenter perspective, thanks @remie for pointing the critical disconnect between problem and statement. I think it offers a strong explanation for why @BenRomberg, @simon (by the way, welcome to the Atlassian developer community!), @danielwester, and @rlander (and even @remie before he gave the RFC a serious read) share similar feedback about doubts that this is the right solution.

In the interest to facilitate to a better problem/solution fit, I want to try to expand on @remie’s line of reasoning as a way to both “nudge” the conversation toward even more constructive conversation, and to try to help @MalathiVangalapati, as author, understand these reactions and what she could do about them. For those who have already commented, please correct me where I diverge from your intent.

Like @remie, I find the problem statement directionally correct. But unlike @remie, I think I disagree with it on the basis that it’s too broad. For one dimension of overly-broad, I think “customer” needs refinement. Are we talking about the users who want to buy an app, the admins who install it, or maybe a buyer persona who may not be either one? For another dimension of overly-broad, I think the “compound problem” sets up too much for a solution that wants to be a “thin slice” kind of solution. Even more specifically, I think it’s important to separate the concern of sales, as a (usually) one-time transaction, from the (usually) on-going needs for onboarding. In short, I think the problem statement is short on “who” and “when”.

From my experience (some with Marketplace but much more with SaaS vendors), I see a problem with “for all end-users of an app” and “while onboarding (regardless of before or after the sale)”. For that problem, even the attempt to mitigate risk of this feature by having per app “opt in” constitutes a serious flaw because it sets the exact wrong precedent. It goes against the advice we provide to others about how to leverage “the flywheel effect” (see “Lesson 3: Treat human interaction as a bug”) and our own behavior. The only public demos Atlassian provides are “mass produced”.

For the problem refinement I’ve just asserted, there are a number of serious flaws with the proposed solution. The first is, “Why do we need a feature at all?” As far as I can tell, Marketplace vendors already have sufficient control over content that they could already add this to their page. The next problem is that introducing specialized but generic UI also increases friction, relative to the existing “DIY” option. Across Marketplace vendors and SaaS partners, many developers have already resorted to “off-Atlassian funnels”, where they already have the option to target the right action to the right person. We need a solution that better addresses the whole range of vendors. The third problem is the proposed “first phase” is so “API poor” for an audience of developers, with a poor cost/benefit ratio. I don’t know the internal engineering effort, but the proposed solution introduces many new “interfaces” (the customer’s new “button” in Marketplace, a form, some emails) while doing less than developers can already do themselves on their own sites. And our “low tech” approach with email immediately translates into more work as vendors try to parse email texts without a well-defined interface and integrate into their existing sales automation.

Despite the flaws, I can imagine an MVP that is potentially both more “minimal” and more “viable”: “app onboarding” as a feature of the app platform. The starting point could take a page from the Apple design pattern that every app has an “about”, not just for admins to read, but for all users. And, in the context of current app frameworks, it would be trivial for vendors to construct a “pre-sales” vs “post-sales”, if not even “pre-segmented” (based on underlying product usage, for example). That would allow vendors to render different kinds of onboarding flows as appropriate to prospect scale/stage and to end-user role.

I think this line of reasoning and alternate proposed solution fit well with:


I also agree that it is far to broad, and to be honest will set the Atlassian Marketplace team and the vendors up for failure. The inability to have direct relations with actual end-users is a problem that has existed since the inception of the Atlassian Marketplace. The only RFC that will end this will come from the Atlassian legal department and will address A) the Atlassian Marketplace Partner Agreement which disallows Marketplace Partners from any in-product marketing / customer engagement and B) the privacy restriction which prevent partners from accessing customer contact details.

Any other RFC that tries to resolve this “problem” will never be able to come up with a proper solution that isn’t a disconnect.

So yeah, I definitely agree with @ibuchanan that this problem statement is too broad. Like I mentioned before, I think the author can easily fix this RFC by simply rewriting it from a customer perspective and only address the customer problem of not being able to quickly book a demo session in a more uniform experience within the context of the Atlassian Marketplace.


Hi y’all,

Just to add our own perspective here: We would like having a “Book a demo” link on a marketplace listing. In fact, we liked the idea so much, that we use such a link on every listing of ours, with the sole exception of Dogecoin for JSM. It has to be noted though, that this is a small marketplace partner speaking; so far, we have been able to take on every single demo requested and look forward to doing more.

Having said that, I don’t think the feature as described here would help us very much. We currently use a Calendly link that allows a prospective customer to pick their favorite time on our calendar directly. As described above, the new feature would introduce friction in this process rather than reduce it, at least from our perspective.

Hope that helps,


Thanks for the feedback @BenRomberg @danielwester @simon @rlander .

This resonates with what we have heard from a few other partners as well.

We want to start with a light weight feature to gauge the intent from customers.

We could either do a pilot with a subset of partners and apps who are willing to provide high touch demos or we could change the copy to something more inclusive of demos without specifically calling out " 1:1" demos.That would give us room to accommodate for both 1:1. demos and pre-recorded demos/Webinars and written content like white papers and blogs.

We will keep the group posted as we decide on the approach.

Agreed, we will eventually start sharing details via APIs but unlikely that it is part of MVP


Why is Atlassian owning the whole experience?

Let me provide a link that takes them to my Calendly or whatever which is configured to capture the info I need into the CRM I control and schedules the way I want it.


It would be useful just for the marketplace team to offer a place for vendors to put more links of any kind so we can decide if they are for booking a demo, getting started with guides, or something entirely different. Let’s start there and see how people use it, and then you can decide what can be made easier for a large majority.


Thanks for all the honest feedback @remie, appreciate it . I agreed that the problem statement is too broad and I’ve used the word “customers” to loosely indicate the existing and potential customers.

As called out in the RFC, this feature is a first step towards addressing the broader goal of enabling partners to better connect with the customers (both potential and existing).

We’ve been exploring options to introduce touchpoints across the user journey (intent → Install & onboard -->Usage & feedback -->Churn) to share their details and seek more enablement (demos, webinars,whitepapers etc ) from partners

Want to validate the efficacy of request a demo for new/potential users /customers with a light weight feature set before building additional capabilities.

Great point @boris ,

We surely don’t want to own the whole experience but at the same time want to have a mechanism to close the loop and evaluate the efficacy of the feature. TBH, haven’t fully fleshed out the scheduler feature yet, as we want to get feedback on the initial concepts before we start adding more features.

Yes, we will be enabling partners to add links to - calendly, webinars, documentation etc in the next iterations.

Agreed @JuliaWester , we will offer a place for partners to add more links as you see fit in the next iterations.

As I understand it, the RFC process is designed for Atlassian’s ideas to be adjusted before they’re implemented. In this thread you have taken the feedback from multiple people and responded that you’re planning to do what you wanted anyways, and later on you may implement our suggestions.

It’s fine if this is the approach Atlassian wants to take, but then it’s not an RFC, and dressing it up as one sets incorrect expectations on our side.

@ibuchanan am I misunderstanding the intent of the process? or possibly incorrectly expecting Atlassian to do anything with the comment portion of an RFC?


I have to agree with Boris here.

Please accept the following “serious flaw” to this RFC: the proposed solution not only does not address the stated problem, it also does not resonate with the community.

1 Like

Do you mean you want to validate it with the community? Or with the customers?

Can you also please share the definition of the Atlassian Marketplace team with regard to customer? Because to be honest, it often feel like with “Customer” you mean end-user.

Given that we have entered into a Reseller contract with Atlassian, I would like to argue that the Atlassian Marketplace team should consider the Marketplace Partners as the customer of MPAC, and not the end-users. OUR revenue share is paying for MPAC. If Atlassian wishes to develop features, they should do that on our behalf, not of that of the end-user.

Luckily, Atlassian and Marketplace Partners share the same goal with MPAC: sell apps (for which Atlassian gets both a revenue share and shareholder recognition, as well as added appeal of their own products because they can be extended).

Please Atlassian, do not get confused who the “customer” of MPAC and the Atlassian Marketplace team is.

1 Like

I agree with @BenRomberg and the others in saying a webinar would probably be more useful. With about a dozen apps having 1 on 1 demos for all could be overwhelming.

I think a must-have feature is the ability to turn this off (also off by default). If the vendor isn’t ready/able to do demos/webinars then the marketplace shouldn’t be offering it

1 Like