RFCs are a way for Atlassian to share what we’re working on with our valued developer community.
It’s a document for building shared understanding of a topic. It expresses a technical solution, but can also communicate how it should be built or even document standards. The most important aspect of an RFC is that a written specification facilitates feedback and drives consensus. It is not a tool for approving or committing to ideas, but more so a collaborative practice to shape an idea and to find serious flaws early.
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
Thank you for the comments and ideas around the RFC-4 Request a demo feature and proposed solution! Recognizing the significant flaws, we have revisited our approach and undertaken iterations to refine the solution. Our current problem remains -being able to build a bridge between Partners and the direct users (including potential users) of the app.
- Author: 10 Jun 2023
- Publish: 12 Jun 2023
- Discuss: 20 Jul 2023
- Resolve: 15 Aug 2023
What did we learn from previous RFC?
- Some partners, especially those which primarily target larger organizations, do want the option to enable requests for a demo directly through their marketplace listing.
- Though many partners identified serious flaws in this solution. In particular, we heard concerns that:
- This solution, as proposed, could quickly overwhelm teams with too many or unqualified leads, which would be a poor experience for partners and customers alike (denied demo requests)
- The majority of partners would seem to prefer additional or alternative forms of educating and qualifying leads. Such as:
- Resources for live and recorded webinars
- Resources for additional documentation
- Integrations with familiar lead capture and scheduling tools
- Desire for sandbox-type trial environments
The scope:
Given the serious flaws, we went back to the drawing board and iterated on the solution. Our current problem remains - being able to build a bridge between Partners and the direct users of the app. For this purpose, we are introducing several new touchpoints along the funnel.
In this RFC, we are going to detail out the 1st touchpoint (top of the funnel) that allows Partners to provide more resources to customers, and in return get direct contact information from them.
However it is only one of the many such initiatives under this umbrella. In the future, we want to add more touchpoints for collecting user information, such as:
- Customers to share contact details to get access to additional demo content
- Customers to share contact details for demos during requesting an app from admin
- Customers to share contact details while installing an app
- Customers to share contact details while reviewing an app
- Customers to share contact details while churning an app
All of these touchpoints will allow users to send their own information to Partners which the latter can use to directly get in touch with them.
What did we change?
We have scrapped the initial “Request a demo” feature and are now approaching a more broader feature that can provide more reousces. Here’s what’s changed:
-
What we heard: Redirecting users to pre-recorded demos, webinars or content before taking them up for 1:1 demos.
What we can do: We are now expanding the feature to be a bridge that allows Partners to guide users to either documentation or pre-recorded sessions or demos as per their choice. Partners will have the space to offer 3 different links (to the above templates) to direct customers where they want, and conduct the session as they see fit.
-
What we heard: Requirement of scheduling integration to reduce back and forth
What we can do: While offering a standard scheduling integration from Atlassian is not something we can take up with this rollout, we are offering a space for partners to add scheduling links of their own. However, based on the demand and usage of the feature, we will consider further enhancements as needed.
-
What we heard: Ability to switch feature ON/OFF
What we can do: As this feature will be opt-in only, it will be OFF for all marketplace listings, except those who have explicitly opted-in. Partners will not have the control to switch it ON/ OFF. For the 1st iteration, we cannot offer a choice as we will be running this for a particular period of time for the selected partners and want to evaluate certain metrics. Toggling between the choices can throw off our understanding of its effectiveness.
-
What we heard: Being able to give demos only to high-intent customers (eg: >1000 users).
What we can do: In the first round, Partners will themselves have to select customers they want and do not want to offer demos to, and communicate with them accordingly. However, as we scale, we will keep this point in mind and allow selected display of this feature to high-intent customers only.
-
What we heard: Other methods such as getting customer data through an API, logging demos via JSM, etc.
What we can do: For the 1st iteration, we want to validate the need through an email-led process. We will be working on a more streamlined way in the future as the feature gains popularity.
Here’s how we are bringing about these changes:
Touchpoint:
All visitors will be able to see a CTA on the app listing page of selected apps. Only logged-in users will be able to access to modal that pops up next.
[Please note that the screens and the copies are not final, and being improved upon.]
Customer flow:
Logged-in users are directed toward a modal where we ask for the following mandatory information:
- Name and email address (these are auto-captured from their profile and not explicitly asked)
- The organization they work at (auto-captured if available)
- Their designation (auto-captured if available)
- Their team size (customer must enter)
- Additional comment for help
On completing the form, customers will now get access to the resources that partners have provided. As of now, we want to provide a space for 3 types of resources:
- Link to documentation/ written tutorials or content
- Link to pre-recorded videos they can look at
- Link to schedule live demo sessions
For the 1st iteration, we will request all selected/ interested partners to provide at least 1 of the 3 types of experiences available (eg: you may choose to provide only demo sessions, only documentation, or documentation + pre-recorded session links, etc).
The action button for each will then redirect the user to whatever link you have provided us with. Hence, all 3 are outbound links that you can use to direct the user to your Calendly, Youtube, website, etc.
We will send a copy of the available links to the customers as an email. Partners will receive an email containing the details of the customer who requested access to these resources.
Email partners will receive. You can also provide feedback on the process through a survey form.
Email customers receive after filling in the form containing the same resource links.
Partners are free to contact the customers using their details for the sole purpose of conducting a demo or providing app information. As of now, we will do this on an opt-in basis with links collected manually, however, we will work on making it an automated section that partners can manage independently once we can gauge the user traffic.
What is coming next?
As we continue to shape this work, we will keep you posted. We are also open to expanding this feature and changing the flow (and taking up the other, more persistent and long-term solutions), based on the response we receive once it is live. Currently, we want to release the feature with the aim of gauging the collective response from customers , partners and understanding how we should shape the feature based off that.
Thanks again for all of your comments to help improve this solution!
