Developing An Award-Winning Onboarding Process (Case Study)

 This article is a case study of how the platformOS team has researched, developed, and iteratively adjusted their onboarding processes over more than three years to eventually create the multiple award winning developer experience they provide today.

The notion of onboarding is all about helping users quickly and easily find value in your offering. Speed and ease of use are equally important because users might lose interest if going through an onboarding takes more time or is more complicated than what they expected. Speed and ease of use are also relative to a person’s point of view: a salesperson can have vastly different expectations for an onboarding than a developer.

A well-constructed onboarding process boosts engagement, improves product adoption, increases conversion rates, and educates users about a product. Optimizing the onboarding experience is a journey. You should have a plan but be agile, utilizing processes and tools to garner feedback from target users in a bid to constantly improve.

In this article, we will walk you through how we developed the onboarding processes for platformOS from the very beginning. You will be able to follow how we carried out user experience research, how our onboarding has changed over time, what assumptions we made, and how we adjusted them. We will talk about all the tools we used as examples, but the same processes can be implemented with a wide variety of other tools. You will get practical examples and a complete overview of how we built our onboarding, with insights into UX research and the specifics of working with different audience segments.

Our audience has always combined technical people with various levels of programming skills, and non-technical people who come to our docs to evaluate if platformOS would be a good fit for their projects like Project Owners, Business Analysts, and Project Managers. Because our main target audience is divided into different segments, you will also get a glimpse of the processes we developed for our documentation, developer education, and developer relations.

Challenge: Onboarding For Different Target Audiences

platformOS is a model-based application development platform aimed at front-end developers and site builders automating infrastructure provisioning and DevOps.

DevOps is a combination of development methodologies, practices, and tools that enable teams to evolve and improve products at a faster pace to better serve their customers and compete more effectively in the market. Under a DevOps model, development and operations teams are merged into a single team where the engineers work across the entire application lifecycle, from development and test to deployment to operations.

Our main target audience is developers, and the foundation for their onboarding, education, and support is our developer portal — but our onboarding has to cater to other target audience segments as well.

Defining Our Target Audience Segments

We defined our target audience during the discovery phase of the Design Thinking process that we used to plan our developer portal. Since then, we have frequently revalidated the results to see if we are on the right track because we want to be sure that we understand the people who will be using our product, and what motivates them. We also know that in the lifecycle of a product this audience can change as a result of product positioning, and how well we can address their needs.

Our target audience currently has four segments:

• Experienced developers,
• Junior developers,
• Agency Owner, Sales/Marketing,
• PM, Business Analyst.

User Base Shifts

We created the first target audience map when we started planning our developer portal. In the discovery phase, we mapped out four proto-personas that covered the following segments: Experienced Developers, Junior Developers, Site Builders, and Marketplace Owners.

We revalidated these results a year later, and we realized that our audience had shifted a bit.

• The Experienced Developers and the Junior Developers stayed as the main target audiences. However, we collected new knowledge related to the needs of the junior devs. They needed more detail to be able to understand and start working with the product. This new information helped us specify their user journey.
• At this point, the Site Builders were the smallest group. We identified we needed to address the needs of the developers group first, creating a strong foundation to support site builders in the platform.
• The non-technical segment shifted on the way. The Marketplace Owners segment was divided into two separate audiences: the Agency Owners, who have a sales and marketing background, and the Business Analysts, who have an enterprise background in business management or transformation — a new audience who started to show interest in our product.

Along the way, we were able to specify the needs of these audiences in more detail. These details helped with the prioritization of the onboarding tasks and kept our focus on the needs of the audience.

Defining Entry Points For Target Audience Segments

Getting to know the needs of the target audience segments provided guidance for identifying the entry points to the product.

• The Agency Owners’ key goal is to work on multiple web projects that they host and manage on the platform. They won’t work on the platform themselves, but they would like to know the status and the progress of the platform without worrying about DevOps. They need to see the business perspective, the security, and that they are part of a reliable ecosystem with a helpful community around without diving deep into the technical part of the product.
• The Business Analysts’ goal is to identify solution providers for their specific business problems. They need to find a long-term solution that fits with their use case, is scalable, and gives them the possibility for easy evaluation that shows the key business values in action.
• The Junior Developers’ goal is to learn the basics without much hassle, under the guidance of experienced community members. They need clear technical communication on how to set up a dev environment and how to troubleshoot common errors.
• The Experienced Developers’ goal is to find a solution that is reliable and flexible enough for all their project needs and at the same time provides good performance. They need to be able to evaluate quickly if it’s a good fit, then see how their project could work on the platform. They also need to see that the platform has a future with a solid community behind it.

All segments needed an actionable onboarding where they can interact with the product (and engage with the community) based on their level of technical knowledge.

• In the non-technical journey, users can go from the 1-click route that takes them through registering on the Partner Portal to creating a demo site and installing the blog module by clicking through a setup wizard.
• In the semi-technical journey, users can create a sandbox in which they can experiment by cloning a demo site from our GitHub repository, and they also have the option to go through our “Hello, World!” guide.
• In the technical journey, users can follow a more complex tutorial that walks them through the steps of creating an app on platformOS from setting up their development environment to deploying and testing their finished app. It explains basic concepts, the main building blocks, and the logic behind platformOS, while also giving some recommendations on the workflow.

How We Approached The Challenge: Methods And Tools

We followed various methods to tackle different aspects of the main challenge. We selected a Design process to follow, used many different user research methods to collect insights and feedback from our users, chose a framework for our editorial workflow and technical implementation that could work well for our Agile, iterative process and our target audience, and went with an approach for content production that allowed community members to contribute early on.

Design Thinking

Because of the strategic role our developer portal plays in the adoption and use of our product, we wanted to use a creative design process that solves traditional business problems with an open mindset.

Our goal was to:

• help our community to be able to use our documentation site for their needs as early as possible;
• measure user needs and iterate the product based on the feedback;
• keep the long-term user and business goals in mind and take a step closer with each iteration.

We found the Design Thinking framework a perfect fit because it is a user-centric approach that focuses on problem-solving while fostering innovation.

We followed the stages of the design thinking process:

• Empathize
  In the beginning, we explored our audience, our documentation needs, and existing and missing content through in-depth interviews and workshops.
• Define
  Then, we defined personas and our Content Inventory.
• Ideate
  We shared our ideas for content and features through a Card Sorting exercise.
• Prototype
  Based on our findings, we created a sitemap and prioritized content needs, and created layouts and wireframes. Content production started based on the results of our discovery phase.
• Test
  We followed an iterative, Docs as Code approach: at each stage, we work with quick feedback rounds, deploy often, and improve features and content based on feedback from real users.

User Research

In the life of a product, each development stage has a fitting UX research method that we can use, depending on the business plans, time constraints, stage of product/feature, and the current concerns.

In the last three years we used the following methods:

• Interviews
  We met with users, sales, and support persons to discuss in-depth what the participant experienced about various topics.
• Remote Usability Testing
  We asked potential or current users of the product to complete a set of tasks during this process, and we observed their behavior to define the usability of the product. We used two types of remote usability testing:
  • Moderated: We conducted the research remotely via screen-sharing software, and the participants joined in from their usual work environment. This approach is advantageous when analyzing complex tasks — where real-time interaction and questioning with participants are essential.
  • Unmoderated: We sent tasks for users to complete in their own time. As moderators are not present, we measured less complex tasks and focused on the overall level of satisfaction they experienced when interfacing with the product.
• Card Sorting
  A quantitative or qualitative method, where we ask users to organize items into groups and assign categories to each group. This process makes it possible to reflect the users’ mental model on the architecture.
• Tree tests
  We used tree tests to validate the logic of the used information architecture. We gave users a task to find certain elements in the navigation structure and asked them to talk about where they would go next to accomplish the task.
• Surveys, Questionnaires
  We used questionnaires and surveys to gather a large amount of information about a topic. This quantitative data can help us have a better understanding of specific topics that we can further research to understand what motivates users.
• Analytics review
  We used site analytics to gather quantitative data about usage patterns and identify possible flow breaks. Based on the data we either fixed the problem or if needed, we further tested with usability research.

Docs As Code And CI/CD

We engaged our users in an Agile and iterative process right from the beginning discovery phase. This ensured that we were able to test and validate all of our assumptions, and quickly make modifications if needed. As our internal team members and our community participants are distributed, we needed a workflow that made it possible to collaborate on changes, large or small, remotely. Consequently, we needed a robust approach to version control accommodating authors, reviewers, and editors all working on content concurrently. As we wanted to encourage developers to contribute, we needed a framework that they’re familiar with. We also wanted to make our documentation open-source, so that anyone could duplicate and reuse it for their own projects. Based on these requirements, we decided to follow the Docs as Code approach.

Documentation as Code or Docs as Code refers to a philosophy of writing documentation with the same tools as software coding. This means following the same workflows as development teams, including being integrated into the product team. It enables a culture where writers and developers both feel they have ownership of the documentation and work together to aim for the best possible outcome. In our case, we didn’t only have writers and developers working on our onboarding but also UX researchers, account and project managers, and of course, a range of users in varying roles.

Our documentation is in a separate repository on GitHub. We have a central branch, and we work locally in a dedicated branch, then we send pull requests for review to be merged into the main branch. To preview docs, we use our own staging site which is an exact copy of the live documentation site.

Once we accept changes, we take steps to push them live almost immediately. To maintain the integrity of the site during this process, we follow the practice of continuous integration and continuous deployment (CI/CD). We run test scripts automatically and deploy the codebase to staging. If a test fails, an error report is generated. Alternatively, if everything goes well, our CI/CD of choice — GitHub Actions — deploys the codebase to production and sends us a notification. We release updates continuously, at times merging multiple changes in a single day, at other times only once or twice a week.

Editorial Workflow

Docs as Code provides the foundation for our processes, but for the various users to work efficiently together, we needed to define a clear editorial workflow that worked for all participants (internal and external writer, developer, contributor, and so on) and for all stages of the process (writing, reviewing, editing); but that was also simple enough to involve new contributors. Following Docs as Code, each stage of our workflow is in git, including project management (contributors can also add tickets to report issues or requests).

These are the steps of our editorial workflow:

1. Write new content in Markdown using the templates. You can use any editor that can produce Github Flavored Markdown.
2. Submit the new topic as a pull request on GitHub.
3. Review. We have a peer-review system in place for code and docs alike. Topics are reviewed by both technical reviewers (developers) and writers.
4. Edit as needed. Repeat steps 3-4 until approved.
5. Merge approved pull request.
6. Deploy to staging, then to production.

Our editorial workflow ensures that contribution works the same way for everyone, and we support our contributors with guidelines and ready-to-use templates.

Content Production And Contribution

When we started developing our onboarding and documentation, we followed the Content First approach. We planned to develop some initial content that we could work with, but even before that, we decided what types of content we would need and outlined the structure of each content type. These outlines became templates that ensure consistency and encourage contribution.

We were inspired by topic-based authoring and DITA, in the sense that we decided to have three main content types for our documentation, tutorials that describe how to accomplish a task, concepts that provide background information and context, and references like our API Reference. Our onboarding consists of tutorials that link to concepts and references when needed.

DITA, short for Darwin Information Typing Architecture, is an XML standard, an architectural approach, and a topic-based writing methodology where content is authored in topics rather than in larger documents or publications. A DITA topic must make sense in its own right.

Involving our users from the beginning ensured that we could test and validate all of our assumptions, and quickly modify anything if needed. This proved to be a time and cost-efficient approach: although we edit and rewrite our content, and change things on our documentation site all the time, we don’t run the risk of creating large chunks of work that have to be thrown away because they don’t correspond to the needs of our users.

Constant collaboration also builds trust: as our process is completely transparent, our community continuously knows what we’re working on and how our docs evolve, and community members can be sure that their opinions are heard and acted upon.

Involving the community from an early stage means that our users saw lots of stuff that was partially done, missing, or ended up totally rewritten. So, for all of this to work, our users had to be mature enough to give feedback on half-done content, and we had to be level-headed enough to utilize sometimes passionate criticism.

Encouraging Contribution

We wanted to make it very easy to get involved for all segments of our target audience, so we offer several ways to contribute, taking into consideration the time contributors have available, and their skill level. We describe ways for our community members to get involved in our Contributor Guide. For some quick editing, like fixing typos or adding links, contributors can edit the content easily on the GitHub UI. For heavy editing, adding new content, or for developers who prefer to use git, we provide a complete Docs as Code workflow. This approach proved to be extremely valuable for our onboarding. We got direct feedback on where users struggled with a step or had too little or too much information, and we could immediately make adjustments and verify that we have fixed the issue.

To help contributors write larger chunks of text or complete topics, we provide guidelines and templates to start from:

• Style Guide
  Our style guide contains guidelines for writing technical content (e.g. language, tone, etc.) and each content type in our documentation (e.g. tutorials, concept topics, etc.).

• Templates
  Our site uses Liquid pages, but to make editing easier for contributors, we write documentation content in Markdown and use a Markdown converter to turn it into Liquid. Our templates include all non-changeable content and placeholders with explanations for the parts that are editable. Placeholders provide information on the recommended format (e.g. title) and any requirements or limitations (e.g. maximum number of characters).

Communication

Our team and community members are scattered across different time zones. Similarly to how we communicate among team members, we use mostly asynchronous and sometimes real-time communication tools to communicate with our community. We even leverage real-time communication tools, like a video conference, to become somewhat asynchronous. For example, video conferences and webinars are recorded, and community members can discuss them on various channels.

• pOS Community site
  One of our main communication channels is our community site, where you can ask, answer, upvote, and downvote questions, and get to know other members of the platformOS Community. More features coming soon!
• Slack support
  One of our main communication channels is dedicated Slack channels, where community members ask questions, share ideas, and get to know our team members and each other. Based on their feedback, community members have confirmed how helpful it is to be able to communicate directly with us and each other: they can share what they’ve learned, plan their module development in sync with our roadmap and each other’s projects, and allocate their resources according to what’s going on in the business and the wider community. This communication seeds the documentation site with the most sought-after topics.
• Video conference
  We regularly have video conferences over Zoom called Town Halls, where community members and the platformOS team share news, demo features, and modules and have the opportunity to engage in real-time, face-to-face conversation. Our team and community members are distributed over different continents, so we try to accommodate participants in different time zones by rotating the time of this event so that everyone has the chance to participate. We also share the recording of each session.
• User experience research
  Besides getting constant feedback from the community through the channels described above, we plan regular checkpoints in our process to facilitate testing and course correction. During development, we tie these checkpoints to development phases. At the end of each larger release, we conduct user interviews and compile and share a short survey for community members to fill out. This helps us clarify the roadmap for the next development phase.

We make sure to keep community members informed about what’s happening through different channels:

• Status reports
  We regularly share status reports on our blog to keep our community updated on what we’ve achieved, what we are working on, and what we are planning for the near future. Our status reports also include calls for contribution and research participation and the results and analysis of UX research. Subscribers can also choose to receive the status reports via email newsletter.
• Release notes
  We share updates regarding new features, improvements, and fixes in our release notes.
• Blog
  We regularly share articles about best practices and general news on our blog.

Accessibility And Inclusiveness #

We address accessibility right from the design phase, where we use Figma’s Able accessibility plugin. We regularly test for accessibility with various tools and ensure that the site complies with all accessibility requirements.

From a technical writing perspective, we support Accessibility and Usability by providing well-structured, clear, concise, and easy-to-understand copy. All of our documentation topics follow a predefined structure (predefined headings, steps, sections, link collections, and so on) applicable to that topic type (tasks, concepts, references), inspired by the principles of topic-based authoring.

Semantic HTML is important for Accessibility, and we make sure not to style text any other way than through Markdown which is then translated into HTML. This way, screen readers can properly navigate through the content, and it also helps overall consistency when, for example, we want to do a design update.

We also review all content to ensure accessible and inclusive language as specified in our style guide.

How We Developed Our Onboarding: Rounds And Lessons Learned

Developing Our Onboarding Using Continuous Iteration Rounds

At the beginning of the project, we started with a focused effort around discovery to identify the main business goals and user needs. As a result of this research, we were able to articulate the big picture. After we had all the user journeys and a sitemap for the big picture plan, we were able to break it down to identify the first iteration that would become the first working MVP version of the site.

Moving forward, we continue to follow an iterative approach, moving fast with an agile mindset. Steps: gather user feedback, identify areas of improvement and possible new directions, define the solution based on resources, business goals, and user needs, and implement it. This circle repeats indefinitely. So, we have an overarching plan outlined for our documentation that we keep in mind, but we always focus on the next couple of action steps we’d like to take.

We can highlight five distinctive rounds that had a great impact on the development of our developer portal.

1. For our onboarding process, we started with exploring the requirements following the Design Thinking approach. Through a Card Sorting session, we explored the areas of interest for each target audience and that helped us define the topics that concern them the most. This worked as a persona-based content prioritization for the documentation site.
2. We wanted to guide our users with actionable items that they can try out on our site as a next step. At this point, we were already aware that our target audience shifted. The interviews and the support feedback helped us understand their needs that pointed in two main directions. We needed an easy journey for non-technicals and another one for technicals who like to understand the logic of the platform. In this stage, we planned, tested, and developed the first version of the 1-click journey and the sandbox.
3. We already had experienced platform users who we wanted to see in action. Using remote field studies, we discovered how they use the tools, the documentation site, and the partner portal we provide. At the same time, we started to conduct continuous onboarding interviews with partners who joined the platform. The two research directions helped us to realize how users with a varying degrees of experience interpret the platform.
4. By this point, our content grew a lot on the developer portal, and we wanted to discover if we needed a structural and content reorganization based on the user research.
5. In this latest round, we wanted to dedicate some time to fine-tuning and adjustments, and to double down on the developer portal’s accessibility and inclusiveness.

Round 1: Identifying The Target Audience Segments, Defining Proto-Personas, Base Discovery #

With the Design Thinking workshops, we first focused on understanding our users. Based on the user research results, we defined the proto-personas and created a detailed description of each to show their needs and expectations and help us identify who we were designing for. It provided a good foundation for guiding the ideation process and prioritizing features based on how well they address the needs of one or more personas.

On our documentation site, we are working with a large amount of data that we need to present clearly to all users. To define a Content Inventory:

• we created a list of our proto-personas’ needs based on the problems they needed to solve with the platform;
• we created a detailed list of content from our previous documentation site and identified missing, reusable, and non-reusable content for our future site;
• we analyzed the competitor sites to create a list of inspirations.

We ideated with the workshop participant using a Card Sorting exercise. The task was to map out the Content Inventory elements and define connections between them. The result showed us the connected areas and the proto-persona’s preference through color coding.

Based on the Content Inventory and the results of the Card Sorting sessions, we outlined the Information Architecture by creating a sitemap and the navigation for our future site. This plan included all the needs that were discovered and offered a roadmap to keep track of site improvements, content needs, and project phases.

During the Card Sorting sessions, we explored areas of interest for each user persona and, on the sitemaps, we highlighted these as user journeys. We also validated the importance of these areas to assign higher priorities to the ones that need more attention. This process kept our focus on the most important needs of the personas.

The most important sections for the four segments:

• Experienced Developers: Quickstart guide, How to guide, API docs;
• Junior Developers: Quickstart guide, Tutorials, Conceptual documentation;
• Site Builders: Quickstart guide, Tutorials, FAQ, Forum;
• Marketplace Owners: About platformOS, Blog.

This concluded our Information Architecture phase. We have discovered and organized all the information we needed to continue to the next phase, where we started creating templates for content types, building the wireframes for each page, producing content, and making Design decisions.

Round 2: Onboarding Strategy And Testing Of The Onboarding Process

Strategy

Before we jumped into planning an onboarding strategy, we did a revalidation on proto-personas. At that point, we discovered that our audience shifted to Experienced developers, Junior developers, Agency Owner, Sales/Marketing, PM and Business Analyst, and we realized that we needed to cover a broader spectrum of needs than previously identified.

We interviewed 20 platformOS users. We identified how long they have been using the system, how they use the platform, what the key ‘aha’ moments were, what struggles they faced, and how they solved them. Their needs pointed in two main directions: we needed an easy journey for non-technicals and another one for technicals, covering those with less experience as well as those more capable developers who wished to understand the deeper logic and nuances of platformOS.

Our main goals with the new onboarding strategy were:

• to connect our systems (developer portal — partner portal — platform), so our users can go through their discovery experience in one flow during their first visit;
• to provide an actionable stepped process that the users can walk through;
• allow users/personas to quickly identify the most fitting journey.

Usability Test

We conducted remote Usability Test sessions in three rounds to validate the platformOS onboarding process.

The onboarding section connects the Documentation site and the Partner Portal where users can select one of three journeys based on their programming experience. The goal was to learn how users with different levels of technical knowledge reacted to the three journeys. Are they able to quickly identify what is included in each journey? If yes, how do they engage from that time forward? Did they follow the pathway most appropriate for them?

During the Usability study, we asked users to do several short tasks using a prototype of the planned features built with Figma. We used both moderated and unmoderated remote usability testing techniques and conducted extra tests with platformOS team members to verify the represented business, technical, and content goals.

We conducted six moderated remote Usability Tests in two rounds and set up three unmoderated remote Usability Tests. These tests were separated into three rounds, and after each round, we updated the prototype with the test results.

Based on the test results, we decided that instead of showing three options to the users, we show the two quickest options: 1-click install and Build a basic ‘Hello world’ app. This helps them to quickly decide which is the best fit for them, and at the same time they can immediately try out the platformOS basics. Then, if they want to, they can check out our third journey — the Get Started guide that explains how to build a to-do app.

We redesigned the Instance welcome screen to help users identify the next steps. Based on the results, we had to optimize the UI copy to make it comfortable for non-technical users as well.

As the flow connects two sites and shows the product, the main goal was to show that the user is on the right track and still on the selected journey. We achieved it by showing the steps of the journey upfront, using consistent wording, and allowing the user to step back and forth.

Round 3: Remote Field Study And Onboarding Interviews

In this round, the goal was to examine the overall journey of the experienced and prospective pOS users, focusing on both successes and challenges they are facing. We conducted an interview with a remote field study to get a better understanding of how they work and what processes they are using.

We focused on four main topics:

1. Development with pOS (workflows, preferences on version control, tools),
2. Community and collaboration (support, discussions),
3. Developer Portal (overall experience, obstacles, suggestions for improvements),
4. Partner Portal (usage, dashboard preferences).

Key insights from the user research results:

• The development with platformOS has a flexible and limitless offering which is a great strength of the system, but it also means that learning the workings of the platform, especially in the very beginning, takes more effort and patience from developers.
  Solution: Templates might provide aid during the learning process.

• As platformOS is new in the market, there’s not much information on Google or StackOverflow yet. On the positive side, the pOS team always provides great support via Slack and introduces new solutions in Town Hall meetings, status reports, and release notes.
  Solution: To further strengthen the community, a separate Community Site can be an efficient and quick platform for peer-to-peer support by having a search function, and users can follow useful topics.

• Related to the Developer Portal, we saw that the user easily gets to the documentation and finds the solution for most of their use cases. However, the search results were not precise enough in some cases, and the naming of the tutorials caused uncertainty about where to find items.
  Solution: Run a content reorganization session for the tutorials and fix the search function.

• We discovered that the Partner Portal was used mostly at the beginning of the projects by experienced devs. Junior developers preferred that they can find helping instructions on the instances page that supported their work on the new instances. Agency Owners/Business Analyst preferred to use the site to see the payments related information and the analytics of the instance use. We saw that they generally had problems handling the permissions related to the instances and identifying the hierarchy between their instances.
  Solution: Partner Portal design update with new information structure of the instances and permissions.

Round 4: Structural And Content Reorganization, User Testing, Implementation

Structural And Content Reorganization

In this round, we renamed the Tutorials section to Developer Guide. This was in line with our plan to extend our tutorials in this section with more concept topics, as requested. We planned to have a comprehensive Get Started section for beginners with the “Hello, World!” tutorial and the Build a To-do List App series, and the Developer Guide for everyone working with platformOS — from users who have just finished the Get Started guides to experienced platformOS developers. This separated and highlighted the onboarding area of the site, and this is when the current structure of our Get Started section came to be: a separate tutorial for when you start your journey with platformOS, that you can use as a first step to go through the more advanced onboarding tutorials.

Card Sorting #

At this point, we had 136+ topics in our Tutorials section organized into 27 groups, and we knew that we wanted to add more. Based on user feedback, we could improve the usability of the Tutorials section by organizing the topics better. Our goal was to identify a structure that best fits users’ expectations. We used a Card Sorting exercise to reach our goal.

We have analyzed the inputs, and based on the results, we concluded that seven categories can cover our 27 topics: Data management, Schema, Templates, Modules and Module examples, Partner Portal, Third-Party Systems, and Best Practices. We used the similarity matrix and the category namings to identify which topics are connected and what names users suggested for them.

With this research, we managed to restructure the Tutorials section to become in line with the mental models of the users.

Round 5: Fine-Tuning, Content Production

In the latest round, we added the possibility, on our onboarding, to start from a template. Based on our discovery, the marketplace template is a good option for site builders who would like to have a marketplace up and running fast and don’t want to explore the development in detail.

The pOS marketplace template is a fully functional marketplace built on platformOS with features like user onboarding, ad listings and ads, purchase and checkout process, and online payment. Following the tutorial we added, users can deploy this code within minutes to have a list of working features and start customizing the back- and front-end code.

We also keep fine-tuning our content for clarity, brevity, readability, accessibility, and inclusive language. We have regular accessibility reviews where we pay attention to aspects, such as terminology, technical language, gender-neutral pronouns, and informative link text while avoiding ableist language, metaphors, and colloquialisms. We summarized our experience with fine-tuning accessibility in the article “Code and Content for Accessibility on the platformOS Developer Portal” which includes examples of what we changed and how.

Future Plans

The platformOS Developer Portal was very positively received and even won a few peer-reviewed awards. We are honored and grateful that our efforts have yielded such great recognition. We will keep revalidating and improving our onboarding just like we have been doing since the beginning. We are also working on a developer education program for our soon-to-be-launched community site that includes various learning pathways that will try to accommodate users’ different learning styles and also offer ways for them to get more involved with our developer community.

Conclusions

So, after years of working on our onboarding, what are our key takeaways?

• Don’t feel pressured to get everything right the first time around. Instead, become comfortable with change and consider each adjustment progress.
• Get to know your target audience and be ready to revalidate and shift target audience segments based on your findings.
• Get familiar with different user research methods to know when to use which approach. Carry out extensive user research and, in turn, listen to your users. To support feedback, allow users multiple different channels to give you feedback.
• Choose a flexible workflow, so that the editorial process does not become an obstacle to continuous change. We love Docs as Code.
• A product is never ready. Shaping and updating an already done flow is perfectly fine.
• Iteration and prioritization are your best friends when it comes to delivering large amounts of work.

We hope that this case study helps and encourages you as you build an onboarding experience for your product.

Forged Documents: Fast-Track to a Permanent Block of Your Amazon Seller Account

 

No matter who tells you to “spiff up” those invoices, just say NO to forged documents.

As happens all-too-often at Riverbend, recently I was assigned a ticket for a new client who was suspended for forged documents.

During our call to discuss his account, he assured me that he had done nothing wrong.

“Did you ever edit an invoice?” I asked.

“Well, yes, but it was OK to do,” he answered.

I didn’t follow his reasoning and pushed for more details.

“I have an account manager at Amazon,” he explained. “They told me to edit the documents to fix the dates and quantities, so it should have been fine.”

This is pretty common in forged documents cases. Our clients feel justified in manipulating invoices because they believe they are somehow presenting the “spirit” of what actually occurred in their business. But Amazon doesn’t want an approximation. They want actual, true invoices.

Other circumstances where we’ve seen forged documents include:

• The seller has multiple accounts and ordered merchandise under one company name, while selling it under another company name.
• The seller bought items from a “friend,” rather than from a distributor, wholesaler or manufacturer.
• The seller failed to obtain proper invoices – ever – from their supplier.
• The seller sold more items than they have invoices to cover. This could be because they first conducted test buys or obtained samples.
• The seller is worried about their invoices being from more than 365 days ago.
• The seller is buying shady goods.
• The seller created a false invoice to get ungated because they didn’t want to buy the minimum for new inventory they may not be able to sell.

In any of these circumstances, do not give in to temptation and submit a faked invoice. Just don’t do it.  You are much more likely to be successful with Amazon by explaining the circumstances of your less-than-ideal invoices.

On the other hand, if you forge invoices, it’s extremely difficult to convince Amazon to give you another chance. They will simply not trust you again. And for good reason.

How To Test A Design Concept For Effectiveness

Most of us are reasonably comfortable with the idea of carrying out usability testing on a website or prototype. We don’t always get the opportunity, but most people accept that it is a good idea.
However, when it comes to a design concept, opinion is more divided. Some designers feel it undermines their role, a view that seems to be somewhat backed up by the famous “Forty Shades of Blue” episode, where Google tested which one of forty shades of blue to use for link color.

It is a position I can sympathize with, and testing certainly doesn’t tell us everything. For example, it cannot come up with the right solution, only judge a design that already exists. Neither is the kind of obsessional testing demonstrated by Google healthy for morale, or most companies bottom line.
That said, in this post, I want to explore some of the advantages testing design concepts can provide to us as designers, and demonstrate that we can do it cheaply and without slowing down the delivery of the overall project.
Let’s begin by asking why a designer might favor testing of their design concepts.

Why You Should Embrace Testing Design Concepts

Every designer has stories of being caught in revision hell. Endlessly tweaking colors and adjusting layout in the hopes of finally getting sign off from the client.
It’s not always like that, but every project is a gamble. Will the client, sign off immediately, or will you end up with a design concept named “Final-Version-21.sketch”? And that is the problem; you just do not know, which makes project planning and budgeting extremely difficult.

Testing Makes the Design Process Predictable

People tend to consider testing a design as a luxury that a project cannot afford. They see it as too time-consuming and expensive. However, in truth, it brings some much-needed predictability to a project that can, in many cases, make things quicker and cheaper.
Yes, if everything goes smoothly with design sign-off, design testing can slow things down and cost a little money. But, that rarely happens. Usually, a design goes through at least a few rounds of iteration, and occasionally it has to be thrown out entirely.
Rarely is this because the design is terrible. Instead, it is because stakeholders are unhappy with it.
By contrast, testing creates a framework for deciding whether a design is right, that is not based on personal preference. Some quick testing could approve a design without the need for further iteration or at worse would lead to some relatively minor amendments if the designer has done their job.
In most cases, this proves faster and less expensive than an endless discussion over the direction. However, even when it does not, it is more predictable, which improves product planning.
Testing also has another related advantage. It changes the basis upon which we assess the design.

Testing Encourages the Right Focus and Avoids Conflict

The design has a job to do. In most cases, it has to connect with a user emotionally, while also enabling them to use the website as efficiently as possible. Unfortunately, most design is not assessed on this basis.
Instead, we often evaluate a design on the simple criteria of whether or not the client likes it. It is this conflict between the role of a design and how it is evaluated that causes disagreements.
By carrying out testing on a design, you refocus the stakeholders on what matters because you build the test around those criteria instead.
That has another advantage as well. It helps avoid a lot of the disagreement over the design direction. That is especially true when many people are inputting on the design.
Because design is subjective, the more people who look at it, the more disagreement there will be. The way this is typically resolved is through a compromise that produces a design that pleases nobody and is often not fit for purpose.
Testing provides an alternative to that. It leads to less conflict between stakeholders and also ensures the integrity of the design, which ultimately leads to a better product.

Testing Improves Results

By using testing to avoid design by committee and focus stakeholders on the right assessment criteria, it almost guarantees a better design in the end.
However, there is another factor that ensures testing produces better design; that is the fact that we, as designers are not infallible.
Sometimes we misjudge the tone of the design or the mental model of the user. Sometimes we fail to spot how an image undermines the call to action or that the font is too small for an elderly audience. Testing helps us identify these issues early, while they are still easy to fix. Updating a mockup in Sketch or Figma is a lot easier than on a working website.
So hopefully now you see that design testing is a good idea for all parties concerned. The next question then becomes; how do we carry out design testing?

How to Implement Design Testing

Before you can test how well a design concept is working, you first need to be clear about what you are testing. Earlier I said that a design had two jobs. It had to connect with users emotionally and enable people to use the site as efficiently as possible.
With that in mind, we want to test two things:

• The brand and personality of the design, which is what dictates whether a design connects with the user emotionally.
• The usability and visual hierarchy, which enables people to use the site more efficiently.

It is important to note as well that for the sake of this article, I am presuming all we have is a static mockup of the design, with no interactivity.
So, let’s start by looking at how we test brand and personality.

Test Brand and Personality

Before somebody is willing to act on a website, they have to trust that website. Users have to form a positive first impression.
In a study published in the Journal of Behaviour and Information Technology, they found that the brain makes decisions in just a 20th of a second of viewing a webpage. What is more, these decisions have a lasting impact.

In that length of time, the user is judging the website purely on aesthetics, and so we need to ensure those aesthetics communicate the right things.
We have three ways we can test this, but let’s begin with my personal favorite.

Semantic Differential Survey

A semantic differential survey is a fancy name for a simple idea. Before you begin designing, first agree on a list of keywords that you want the design to signal to the end-user. These might be terms like trustworthy, fun or approachable.
Once you have created the design, you can now test whether it communicates these impressions in the user by running a semantic differential survey.
Simply show the user the design and ask them to rate the design against each of your keywords.

The great thing is that if the design rates well against all of the agreed words, not only do you know it is doing its job, it is also hard for stakeholders to reject the design because they don’t like some aspect of it.
You can use this method to ascertain the most effective approach from multiple designs. However, there is a much simpler test you can also adopt when you have more than one design concept.

Preference Tests

A preference test is what it sounds like. You simply show several design concepts to users and ask them to select which approach they prefer.
However, instead of just asking users to select which design they like most, ask them to select a design based on your keywords. You can ask users to select which design they feel best conveys the keywords you chose.
You can also apply the same principle of comparison to your competition.

Competition Testing

You can run precisely the same kind of preference test as above, but instead, compare your design concept against competitors' websites. That will help you understand whether your design does a better job of communicating the desired keywords compared to the competition.

The advantage of both types of preference testing is that it discourages stakeholders from adopting a pick-and-mix approach to design. In other words, it encourages them to compare designs in their entirety, rather than selecting different design elements from the competition or different versions, and asking you to combine them into a Frankenstein approach.
By combining both semantic differential surveys and preference testing, you can build up a clear picture of whether a design’s aesthetics are communicating the right impression. However, we still need to ensure it is usable and that people can find the information or features they need.

Test Usability and Visual Hierarchy

A website can look great and give the user the right feel, but if it is hard to use it will have still failed to do its job.
Once you have a fully built website or even a prototype, testing for usability is easy by combining A/B testing (quantitive) with usability testing (qualitative).



However, when all you have is a static mockup of the design, it can appear harder to test. Fortunately, that impression is incorrect. What is more, it is worth testing at this early stage, because things will be much easier to fix.
We have two tests we can do to ascertain usability. The first focuses on navigation and the second on visual hierarchy.

First-Click Tests

An influential study into usability, by Bob Bailey and Cari Wolfson, demonstrated the importance of ensuring that the user makes an excellent first choice when navigating your website. They proved that if users got their first click right, they had an 87% chance of completing their task correctly; however, if they got it wrong that dropped to just 46%.
Fortunately, we can test whether users will make the right first click using an imaginatively named “first click test”.
In the first click, test users are given a task (e.g. “Where would you click to contact the website owners?”), and then they are shown the design concept.
The user then clicks the appropriate place on the concept that they believe is correct, and the results are recorded. It is that simple.

The advantage of running a first-click test from the designers perspective is that it can resolve disagreements about information architecture by demonstrating whether users understand labeling and the site’s overall structure.
However, usability isn’t all about clicking. It is also essential that users spot critical content and calls to action. To test for that, you need a 5-second test.

5-Second Tests

Research seems to indicate that on average, you have about 8 seconds to grab a users attention and that many leave a website within 10 to 20 seconds. That means our interfaces have to present information we want users to see in the most obvious way possible. Put another way; we need to distinguish between the most important and less important information.
Testing this kind of visual hierarchy can be achieved using a 5-second test.
Usability Hub describe a five-second test in this way:

“A five-second test is run by showing an image to a participant for just five seconds, after which the participant answers questions based on their memory and impression of the design.”

It is important to note not only whether users remembered seeing critical screen elements, but also how quickly they recalled those elements. If users mention less essential elements first, this might indicate they have too much prominence.
The great thing about a 5-second test is that it can reassure clients concerns that a user might overlook an interface element. Hopefully, that will reduce the number of “make my logo bigger” requests you receive.
As you can see, testing can help both improve your designs and make design sign off less painful. However, it may be that you have concerns about implementing these tests. Fortunately, it is more straightforward than you think.

Who and How to Test?

The good news is that there are some great tools out there to help you run the tests I have outlined in this post. In fact Usability Hub offers all five tests we have covered and more.

You simply create your test and then share the website address they give you with users.
Of course, finding those users can be challenging, so let’s talk about that.
When it comes to testing usability, we do not need many users. The Nielsen Norman Group suggests you only need to test with five people because beyond that you see diminishing returns.



These users can be quickly recruited either from your existing customer base or via friends and family. However, if you want to be a bit pickier about your demographics, services like Usability Hub will recruit participants for as little as a dollar per person.
Testing aesthetics is trickier because as we have already established design is subjective. That means we need more people to remove any statistical anomalies.
Once again, the Nielsen Norman Group suggest a number. They say when you want statistically significant results, you should look for at least 20 people.
It is also worth noting that in the case of aesthetics, you should test with demographically accurate individuals, something that your testing platform should be able to help you recruit.
Although that will cost a small amount of money, it will be insignificant compared to the person-hours that would go into debating the best design approach.
There is also often a concern that it will take a long time. However, in my experience, you can typically get 20 responses in an hour or less. When was the last time you got design approval in under an hour?

Worth a Try

Testing a design concept will not solve all your designer woes. However, it will lead to better designs and has the potential to help with the management of stakeholders significantly. And when you consider the minimal investment in making it happen, it makes little sense not to try it on at least one project.

When to know you are being hooked by a phisher and how you can get free.

 

Not-so-Fresh Phish: How to Avoid Seller Scams

In this digital age, account hacking and information phishing are regular concerns and annoyances like robot calls.

But this doesn’t mean they are always obvious to spot.

Here’s some tips on what to look for and what actions to take with Amazon related phishing.

The Phishing For Account Info Scams

Phishing is a term used when a scammer sends fake email ID posing as Amazon and tries to acquire the personal details from you.

First, they send an email containing links to the seller and when clicked the links will redirect to a whole new space which will ask for your account credentials and credit card information.

Recently Amazon has introduced a two-step verification code to circumvent the increase of phishing scams.

Amazon will never send you an unsolicited message that asks you to provide sensitive personal information like your social security number, tax ID, bank account number, credit card information, ID questions like your mother’s maiden name or your password.

Amazon will never ask you to make a payment outside of the website and will never ask you for remote access to your device.

How to Keep Your Account Safe

Keep Your Selling Account Credentials Safe:

It may seem obvious, but NEVER share your bank or seller account information with anyone.

Even if someone allegedly calls you telling that they are an Amazon representative and asks you to log in with the code they provide, NEVER do it.

While Amazon may reach out via phone for some issues, they will never request this kind of information.

Turn On 2-Step Verification:

This is the best way to protect your account and the process is simple too.

A seller can sign into their account only via a two-step verification code which will be a random six-digit number. This code is usually sent from Google Authenticator to your smartphones, Amazon’s registered phone number and Amazon’s registered mail ID.

If you have not enabled it yet, do it now.

Always check the URLs and email IDs:

It is very essential that you understand the difference between a genuine and fake email ID.

Emails you receive from Amazon will always end with @amazon.com. Don’t believe any other email IDs.

Some of the fake email IDs used as follows:

• amazon-security@hotmail.com
• sellers-performance@payment-amazon.com
• amazon-seller-payments@msn.com

Stay Sharp to Save Time and Money:

If you stay proactive and take proper steps to protect your banking information, account details and your products, then you might not even face such situations. But still, if you are targeted, you know what to do (and what not to).

Consider changing the e-mail address associated with your seller account so that phishers can’t use this e-mail address to contact you.

For example, if your seller account uses myinfo@myisp.com, consider using a new or different e-mail, such as changedinfo@myisp.com, for your contact information.

Do not use the same e-mail address as your sign in as you do for your customer contacts.

For example, if you use myname@myisp.com as your sign in account, consider using an e-mail address such as info@myisp.com for your notification or contact e-mail address.

Identifying false (spoofed) e-mails:

You might receive emails from Amazon, such as Sold, Ship Now emails or Technical Notification emails. However, sometimes you might receive emails that are not really from Amazon, even if at first glance they may appear to be. Instead, such emails are falsified and attempt to convince you to reveal sensitive account information.

• Review the email for grammatical or typographical errors: Watch for poor grammar or typographical errors. Many phishing emails are translated from other languages or are sent without being proof-read.
• Check the return address: Genuine emails from Amazon always will come from an address ending in “@amazon.com.” Check the email’s header information. If the “received from,” “reply to,” or “return path” for the email does not come from “@amazon.com,” it is not from Amazon. Most email programs let you examine the source of the email. The method you use to check the header information varies depending upon the email program you use.  The following are some examples of fraudulent return addresses:
  • • seller-performance@payments-amazon.com
    • amazon-security@hotmail.com
    • amazon-payments@msn.com
• Check the website address: Some phishers set up spoofed websites that contain the word “amazon” somewhere in the URL. Genuine Amazon websites always end with “.amazon.com”, “amazonsellerservices.com” or “sellercentral.amazon.com.” We will never use a combination such as “security-amazon.com” or “amazon.com.biz.”

If you are unsure, go directly to Amazon or the Seller Central website:

Some phishing emails include a link that looks as though it will take you to your Amazon account, but it is really a shortened link to a completely different website. If you hover over the link with your mouse when viewing the message in your email client, you often can see the underlying false website address, either as a pop-up or as information in the browser status bar.

Note: The hover technique can be fooled. If you do click on a link, always look at the URL in your browser when the page opens.

The best way to ensure that you do not respond to a phishing email is to always go directly to your seller account to review or make any changes to the account.

When in doubt, do not click on a link in an email.

Do not unsubscribe:

Never follow instructions contained in a forged email that claim to provide a method for unsubscribing.

Many spammers use these unsubscribe processes to create a list of valid, working email addresses.

Help stop phishers and spoofers:

You can make a difference.

Amazon has filed several lawsuits against phishers and spoofers. These lawsuits began with sellers alerting Amazon to suspicious emails. As part of their ongoing commitment to stop spoofing, you can help them investigate spoofed emails. Send them the original spoofed email, with the complete header information, using their report phishing form.

To locate the header information, configure your email program to show All Headers. (This varies, depending on the email program you use.)

The headers we need are well labeled and will look similar to this example:

• X-Sender: someone@domain.com
• X-Sender-IP: [10.1.2.3]
• X-Date: Tue, 08 Apr 2003 21:02:08 +0000 (UTC)
• X-Recipient: you@domain.com
• X-OUID: 1

To report a phishing or spoofed email or webpage:

Open a new email and attach the email you suspect is fake. For suspicious webpages, copy & paste the link into the email body.

If you can’t send the email as an attachment, forward it. Send the email to stop-spoofing@amazon.com

Note: Sending the suspicious email as an attachment is the best way for Amazon to track it.

Note: Amazon can’t respond personally when you report a suspicious correspondence to stop-spoofing@amazon.com, but you may receive an automatic confirmation. If you have security concerns about your account, please contact Amazon.

Suspicious Phone Calls or Text Messages

Report any suspicious phone call or text message to the Federal Trade Commission (FTC). To report a phone call or text message visit ftc.gov/complaint and follow the onscreen assistant.

When do you need to create a POA for Amazon?

 

Reactive vs. Proactive

By: Lauren Barbera

Humans, are fallible, and the systems we build are also fallible. It is inevitable that a blip in our operations or policy adherence will happen because we are human.

When this blip happens, it can feel like Amazon engages in a parental-style finger-wag of shame as they ask sellers to create a POA for Amazon. This stings, especially when it feels like the error was caused by something out of our control. Writing these POA’s can also be stressful and time consuming, which can be an added frustration when you feel this time could be better spent running other aspects of your business.

I can hear you thinking “But we fixed the blip as fast as the blip could be fixed! How could I have known there was an imminent blip?!”

Is Amazon asking for us to divine the future before it happens?

The answer is both yes and no.

Amazon fully understands that problems will occasionally arise that impact operations. The recent AWS outage is a great example.

However, if it is any consolation, Amazon forces its own internal teams to provide Plans of Action when they’re responsible for a problem impacting operations.  They call them “Post-Mortem COE” (Correction of Errors). They hold their own feet to the fire as much as they do so with sellers.

The long and short of it is

Amazon knows, down to an approximate dollar amount, how much service and policy failures cost them in terms of current and future buyer behavior. Buyers don’t know you’ve fixed the blip, and they don’t care. All they are concerned with is that the widget they ordered did not arrive, was late, different than expected, in a lesser condition than expected, or they suspect the widget is inauthentic.

Amazon has been able to quantify all of those experiences in terms of dollars spent after the ‘Widget blip event’.

So, Amazon has decided they do not want buyers to HAVE ‘widget blip events’. Amazon wants the buyer to receive the widget they ordered on time, exactly matching the product detail page, and in the condition advertised.

THIS is why Plans of Action are required. Amazon KNOWS people are fallible. They want to know what, to the best of your abilities, you can do to give yourself the most robust safety nets possible to avoid future WBE altogether. Can people avoid car accidents that are entirely all together not their fault? Unlikely. However, if that accident was the cause of your not being able to get packages out the door on time, Amazon wants to know that you have a backup plan for when things happen that are genuinely outside of your control. Simply crying, “but the widgets were shipped eventually!” doesn’t tell Amazon what you will do to prevent future late orders in the event of emergency.

Resolving the root of the widget blip that caused Amazon’s enforcement is only step 1. To be fully proactive, Amazon also wants to know that you have already done the work to prevent a poor buyer experience caused by future blips even before they ask for a Plan of Action.

In short

An ounce of blip prevention (so as not to repeat the same events in the future) is worth a pound of POA avoidance going forward.

What is the Amazon Captive Team?

 

When Seller Central isn’t helping, there is another option.

Working through issues in Amazon Seller Central can be exhausting.

It is not uncommon to run into issues in Seller Central. From inventory issues, technical errors, or listing problems that only Amazon Employees can fix. You can  find yourself in an endless loop of phone calls, emails  and unanswered questions. The Amazon Captive Team is exactly what you need to get over this hurdle.

The Amazon Captive Team?

Amazon Seller Support Captive Team is a team of internal Amazon employees that have access to tools and knowledge that not all front line or partner associates have. There is a common misconception that all Captive associates are North American based. This is not true as a large majority of Captive Amazon Seller Support Agents are internationally based in India, Costa Rica, North America and the UK.

Escalating Cases

If you continue to have issues, even after working with a member of the Captive team, never be shy to “escalate” an issue.

Escalating the issue can do two things:

1. It will bring it to the attention of the direct manager (or advisor, they will refer to themselves as a member of the ‘Amazon Leadership Team’) who will hopefully be more knowledgeable and retain the case until it is resolved.
2. It can eventually be transferred, if necessary, to the Amazon Escalations Team. This escalations team is a highly trained, typically North American Captive Team, who will resolve the issue at hand or bring it to the attention of the appropriate internal team. Escalation associates are specifically trained to handle aged and more complicated issues that have fallen through the cracks of the front-line agents

How do I contact the Captive Team?

You can open an email case with Amazon Seller Support here.

However, please note that this is one of the slowest ways to receive support, especially during the COVID-19 pandemic. Once your case is created, request that it be transferred to the Captive team. This may take a few attempts. Another, faster option is to request phone support.

What is the Seller Support phone number?

Unfortunately, there is no direct phone number for Seller Support. The best way to contact Seller Support by phone is through your seller account and requesting a contact.

To do this, follow the instructions given below:

Step 1: Open the Contact us page of Seller Central at this link.

Step 2: At this page, it is important to first choose what your problem is associated to. You will normally see two options:

Selling on Amazon – Select this option if you have queries related to selling or listing on Amazon.com.

Advertising & Stores – Select this option if you have questions related to sponsored brands, stores or sponsored products.

Step 3: The next page will be a list of common issues and questions. Choose your concern from this list, or select ‘Other Issue.’

Step 4: This is where you can create either an email, phone, or chat-based case. For these purposes, select ‘Phone.’

Step 5: Enter your phone number, select whether this issue is urgent, and then include a short description of your issue. Whenever you contact seller support, it is important to address each concern separately and clearly. This will ensure the fastest resolution and the least amount of pushback and confusion.

Step 6: Select the ‘Call Me Now’ button. You will be in the queue for a phone call right away. Be prepared to be on the phone. Have your Seller Central account open, your account details and billing information handy as the associate on the other end of the phone may ask you for it.

Step 7: Request to be transferred to the Captive Team.

Why your veteran amazon sellers may get verified

 

Certain actions – or even no action at all – can get older accounts flagged. Even veteran amazon sellers may get verified.

“Papers, please.” That’s the surprising request veteran Amazon sellers are receiving. Yes, your veteran Amazon seller account may get “verified.” You need to know why.

It’s verification. It is common for new Amazon sellers. When a seller signs up for a new account, they are asked to provide documentation proving their identity. Typically, this is a driver’s license or passport, plus a utility bill in their name.

But now, Amazon is asking holders of old accounts to prove their identities as well.

Why veteran amazon sellers may get verified.

Believe it or not, Amazon does not verify accounts because they have nothing better to do. It’s not even a Medieval torture device for sellers. Rather, Amazon is required by law to gather certain information and ensure it is accurate.

Certainly this is to protect Amazon – and to protect buyers. They must prevent money laundering. In addition, they must make sure that sanctioned sellers are not on the platform. Whether this is related to an entire country sanctioned by the U.S. government or an individual known to engage in criminal activity.

Many veteran account holders never went through verification. So no documents of any kind were required when they signed up to sell on Amazon long ago. Oftentimes, it is actions inside of these older seller accounts that kick off a fresh verification review. For example, the seller may have changed their contraction information. This includes banking information, credit card, tax ID number or address. If these are slowly changed over time, it is less likely to kick off a verification review. A verification review is almost inevitable if all these fields are edited within a day or two.

What if they don’t accept my documents?

In most cases, Amazon is able to verify accounts quickly and easily. They match your name and address on a government-issued ID (passport or driver’s license). As well as on a utility bill from the last 90 days. Therefore, it is critical that your name and address match on your Amazon account and your documents. Mismatches are the most common reasons for suspensions related to verification.

Finally, if Amazon does not accept your documents, don’t despair. Try the following:

1. Ensure that everything matches on your documents.
2. Double-check the document quality. Sometimes, a bad scan can lead to rejection.
3. Explain any relationships between yourself and your company name.

Still running into trouble? Give us a call. Your situation may require professional help. Because the front-line investigators in Seller Performance rarely feel empowered to overrule a rejected verification. We find that escalations to executives are usually needed for success. We are here for you and your business!

Take responsibility for your Amazon account

 

Don’t ignore those pesky notifications from Amazon. Take responsibility for your Amazon account!

Amazon loves sending performance notifications. Sellers dread them and can easily assume Amazon is out to get them, but this is not the case! The dreaded performance notifications and flagged ASINs are a way Amazon has the seller take control and responsibility for their account. First and foremost, when you receive a Performance Notification, do not ignore it! Especially if a plan of action is being asked of you. If you ignore these notifications you put your account at risk of being suspended which could be detrimental to you, especially if your Seller Account is your sole source of income. Take responsibility for your Amazon account.

Here are 3 ways to start taking responsibility for your Amazon account:

Stop Blaming:

I’ve heard numerous times, “The customer just wants their way”. Of course they do. They are the customer. Have you ever gone shopping whether it be in person or online and have a level of expectation of how your experience should be? So do your customers, and Amazon is 100% about the customer’s buying experience from clicking on “Buy” to receiving their purchase. It is your job as the seller to provide good buying experience, even though it is seemingly behind the scenes.

Stop Complaining:

Amazon isn’t out to get you. Competitors more than likely aren’t scanning the vastness of Amazon perusing the pages looking to make life difficult for you. While we do technically live in a dog eat dog world, when you receive a performance notification from Amazon, either they have found an issue that needs to be addressed, or a customer’s buying experience expectations weren’t met and there was a complaint. Yes, some customers want to complain for the sake of complaining, but Amazon doesn’t want you to complain in response. Instead, do a little bit of research. Did the performance notification ask you for a plan of action? Look at the complaint, have you received any previous complaints on the same item? Are they similar to the new one? Is there a bigger issue that needs to be addressed with your item? Take a look at the bigger picture of the complaint. Amazon wants to know you’re taking accountability for the items you offer to sell on their marketplace. This is why they ask you about the root cause of what caused the complaint, you are in charge of your items and your account at all times.

Don’t Take It Personally:

Remember, Amazon really wants to know the root cause of a complaint, what you’ve done to address it, and what you’re going to do to prevent future complaints of that nature. If you write a plan of action, and it gets approved, Amazon expects you to follow that plan of action. Words are fleeting, action is proof. Again, Amazon is not out to get you. Understandably, getting denial after denial can be frustrating and can feel personal, it is not a personal affront to you as the seller. Take the time to really look into your supplier, your inventory, past and present complaints (if applicable), and ways you can make your seller account really stand out.

Why the Great Giveback is good business

 

The mission is to own the market, beat competitors and generate revenue.

Nothing wrong with that. Shareholders, business owners and employees are the benefactors. But there’s another asset of “business life,” which may be ignored or forgotten. It’s really just as valuable as sales orders and revenue. It’s giving back to customers and community.

The buzzword is corporate social responsibility (CSR). I like to call it The Great Giveback. CSR sounds sterile; it feels like a duty not a conviction. Helping others comes from the heart, not a corporate edict.

The Great Giveback comes in many forms. Amazon frequently gives back. It recently distributed 1.5 million diapers and 1.5 million wipes to needy families. It provides funding for American war veterans, schoolchildren and global relief organizations (Note, we won’t talk about the disappointing demise of the Amazon Smile program.)

Amazon sellers are givers as well. An April 2023 report says third-party sellers donated nearly 100 million products in 2022 through Amazon’s FBA Donations program. That’s a small fraction of what sellers give and do for various communities and causes. For example,  we give time and money to A Wish With Wings™, a 40-year-old wish-granting agency that helps Texas children fight life-threatening medical conditions.

Why the Great Giveback is good business

Engaging in the giveback of time, talent and money

Cynics will say corporate “community service” is little more than a societal “must do” to keep the peace, or that it’s nothing more than a tax write-off. Giving back does have corporate benefits. The most common ones are tax write-offs, the value in recruiting top community-conscious talent, improved brand loyalty, and even increased sales.

Giving time, talent and money means much more. Here’s proof:

• Three children, all under the age of 10, find themselves orphaned. A tragic car accident kills the parents. One older sibling, age 23, is now “mom and dad.” A team of employees from a small local company learned what happened and rallied to support the children. Food, clothes, school supplies – -and having the kids play with their kids, go swimming, have BBQs and more. The team helped the new family move into a larger, permanent residence.
• A 10-year-old girl fights for her life. Cancer. One company executive commits to an organization, then rallies others, including employees, to serve the circle of people that help these children, from physicians and nurses to parents and siblings of the child struck with terminal illness.
• The founder and CEO of a $100 million financial advisory firm shuts down the office one day every month. Employees have bought into “charity day.” They spend hours building and repairing homes for the elderly and poor. The CEO is smack in the middle with his cowboy hat and overalls, and tools in hand. Such service has continued since the mid-1980s.

These stories alone make me wonder.

Whose lives are changing the most: those being served or those giving and serving? I know the answer.

Getting started with the company giveback

• Start small
• Know what you want to accomplish
• Get executive commitment and buy-in
• Appoint a primary “organizer.”
• Make it informal (at the start anyway)
• Ask employees. They are “feet on the street” who know the pulse of the community and what’s important to them. Ask and communicate.
• Assess giving opportunities, their types, the organizations, their leadership and their commitments. For example, are you looking for a small, community commitment or working with a national or international organization?
• Carefully choose a nonprofit. How does it fit into your company’s mission, values and culture? Will it perpetuate excitement and engagement, or drive division?
• Be smart and know the people and purpose of a nonprofit. Make sure it is legitimate. DonorBox shares valuable insights on how to check a nonprofit.
• Assess and reassess company participation, employee engagement and results of the give-back. Did employees participate? Was there excitement, enthusiasm and commitment? Did your company make a difference? And yes, ask employees what did and did work and how to improve. Finally, ask those you served. What difference did you make?

Is it time?

Of course it is. Read the headlines. Walk the aisles of your grocery store or drive through “downtown.”

The needs are overwhelming. Community and caring from people to people is the cure. Whether efforts are big or small, corporate or individual, isn’t all that relevant. Getting started and getting involved–one person at a time–is a great beginning.

For me, it’s about re-discovering my heart. My mission. My ability to step out of myself to help others and reach out. To care and be part of a team. It’s time.

What Sellers Need To Know About Amazon FBA Reimbursement in 2022

Imagine working on your laptop, perfecting your Amazon FBA reimbursement listing, talking to suppliers, and participating in an Amazon FBA webinar, while blissfully thinking about how well things are going in the world of Amazon selling.

Suddenly you peer into your inventory dashboard to refresh the tab and notice that a large chunk of inventory isn’t checked into fulfillment centers.

You start thinking about dates, times, and POAs, and it hits you. By all accounts, your inventory is missing in action.

You immediately rush to investigate while trying to stuff the overwhelming urge to panic.

Unfortunately, this sinking feeling is probably a little familiar if you’re an Amazon seller.

But don’t panic; there are ways you can recoup your hard-earned dollars if your inventory is lost or damaged.

Surprisingly recouping these funds through Amazon FBA reimbursements is an entirely normal part of doing business on the world’s largest online marketplace.

When selling on Amazon, FBA reimbursements are a must, not a maybe.

In this article, we’ll explore what Amazon FBA reimbursements entail, how to file them, and how to maximize your reimbursements on an ongoing basis.

What is Amazon FBA Reimbursement?

Let’s begin by unpacking Amazon’s logistical system. Amazon ships about 1.6 million packages every day and roughly 66,000 orders per hour.

When we understand the sheer volume of orders Amazon processes every single day, we gain a clearer picture as to why reimbursements are a necessary evil of doing business on the platform.
With a logistics system that extensive, mistakes are bound to happen.

The case of the missing inventory example in the introduction now seems less murky while not a fun part of doing business as a third-party seller.

Nevertheless, with extensive infrastructure and many packages funneling in and out of warehouses and fulfillment centers, it’s easier to understand how inventory can fall off the beaten path.

Amazon FBA reimbursements are monies owed you by Amazon for inventory that is lost, damaged, unreceived, returned and not credited, overcharged in FBA fees, and more.

Examples of Qualifying Reimbursement Claims

Examples of instances that may qualify for reimbursement include:

1. When a carrier accidentally damages inventory while on route to the customer, or an entire inventory order is lost en route to fulfillment centers.
2. If you’ve been selling on the platd but not sent back, these returns may qualify for FBA reimbursement.
3. A customer can be refunded more than they were charged and beyond the 30-day window. In which case, you’ll once again qualify for reimbursement.
4. Seller fees can be incorrectly chaform for some time, you know that Amazon has a higher-than-average return rate. When returns are processerged for the incorrect dimension and weight of your products. These accounting discrepancies are examples of qualifying FBA reimbursement.

Sellers must perform audits and file particular reimbursement claims with Amazon to recoup funds for lost or affected inventory.

Amazon is generous in its recovery time window and allows sellers to go back 18 months to file reimbursements, for some reimbursement types.

Performing routine audits is your best defense to maximizing the recovery of your funds.

How Much Does Amazon Reimburse?

Another positive aspect of filing FBA reimbursement claims is that Amazon reimburses
the retail value or the median value up to $5000 CAD or USD depending on the marketplace.

That means that Amazon will review your pricing history to determine the estimated retail value for reimbursement.

Each type of reimbursement is calculated slightly differently. See the figure below to understand how Amazon determines each calculation.

Why Doesn’t Amazon Automatically Reimburse Amazon Sellers?

The short answer is that Amazon does reimburse sellers automatically, but only if they capture the error themselves. If Amazon finds a discrepancy, you will see a claim amount processed in your Seller Central Account.

As mentioned in the previous section, the volume of inventory Amazon navigates is extensive, and the workforce and technology cannot always detect discrepancies on its own.

The final decision to reimburse is Amazon’s discretion.
At times, claims can be denied if sellers aren’t abreast of requirements or specific verbiage required in each claim.

You’re probably wondering how you can file for FBA reimbursement?

There are a few ways to file claims, and one of them entails downloading the discrepancies and filing each claim yourself.

Log into your Amazon Seller Central Account. Go to Reports – Fulfillment – Inventory Adjustments. You can download the list of your lost and damaged inventory and subsequently file each claim.

Often, sellers and brand owners have large catalogs of products on Amazon, so filing reimbursements manually can be arduous and time-consuming.

Some brands hire virtual assistants to get the job done, but claims can be denied or refused without proper knowledge in Amazon or well-rounded experience handling reimbursement claims.

What About Hiring an Agency To File Amazon Reimbursements?

To maximize your FBA reimbursement, it’s best to hire an agency like Riverbend to alleviate the burden and get the job done right.

Riverbend’s entire business model lies in account compliance. We don’t jeopardize your account with automated systems because we know how unfavorable these systems are in the eyes of Amazon.

Our dedicated team of reimbursement experts performs a deep dive into your account, leaving no reimbursement unturned.

We handle communication with Amazon on your behalf, so you don’t need to worry about scrambling to understand their requirements or communication style.

Knowing how vital cash flow is to your FBA business, Riverbend doesn’t accept payment until we fully recover your funds.

Summary

As costs appear to surge post-global pandemic, Amazon sellers looking for ways to maximize their cash flow should pay keen attention to FBA reimbursement and stay on top of reimbursement audits.

While Amazon provides the 18-month window for review, the longer you wait to file a claim, the more complex your claim can become as you may face other challenges such as lost paperwork and POA’s.

It’s vital to ensure the agency or Amazon seller consultant you onboard performs due diligence to maximize your reimbursements and prioritize your account health. Your Amazon account is crucial to your business operation and growth.

Never roll the dice when it comes to the health and safety of your Amazon account. Work with agencies and providers you’ve personally vetted and trust.

Do you have questions about Amazon FBA reimbursement? Drop them below!