Share your ideas with us

Some customers enter +1 before their phone number when requesting a return or exchange. This causes the shipping label to fail to generate and creates frustration for the customer and extra work for me. I would like the system to correct the phone number to allow successful label generation.

Hi there,    We’re planning to fully transition to your warranty return platform and would like to see the following improvements: * Dynamic Reference Lines on Return Shipping Labels: We’d like the option to add customizable reference lines on shipping labels. While there are default placeholders available, we need a more flexible solution to include internal notes that will help us organize returns efficiently. * Delayed Replacement Order Processing: We’d prefer the ability to process a replacement order without sending it to Shopify until the carrier marks the warranty return as “en route.” * Regex Validation for Warranty Intake Form: Adding regex validation would help us ensure inputs follow specific formats, such as order numbers or serial numbers, for better accuracy.

Expose an REST API for creating Warranty Claims.

Most major carriers already provide an estimated delivery date/time as part of their tracking data, but this isn't currently surfaced in the app. Context: Customers tracking a shipment want to know when it will arrive, not just its current status. Right now they have to infer this themselves or check the carrier's own site separately. Issue to address: Add a field that displays the carrier's estimated delivery date (and time window, where the carrier provides one) on the tracking/order page. This would reduce "where is my order" support inquiries and improve the post-purchase experience. Suggestion: Pull the estimated delivery data from carriers that already expose it via their APIs, and display it prominently near the shipment status.

We want to refer to the customer's username when packing the order. Right now, to do this, we need to download the tiktok orders, connect them to the shopify order number via the tiktok order in the notes field and then connect that to the order number in shipbob.   If we had the username in shopify, we could eliminate the step where we have to connect tiktok to shopify.

Background: * At the moment, a user with a specific domain can easily create a new organization when creating an account in AfterShip * We don’t indicate to this use that an existing organization is already linked to the same domain This can create confusion when member are trying to get access to an organization proactively (without being added by the current owner) * Hence we end up with support tickets from member not able to get access to their main org. Expectation: * Alert message during new inscription if we identify that the email domain is already used. * Eventually an option to send a request to the owner of the main org. * Possibility to delete the new account to avoid unnecessary org and member creations for our clients. * Could be active only for ENT client if we want to reduce the scope

Add the option to pay online ~ $2 at checkout for free returns and extended warranty later.    Add tags to people / allow different RMA flow for those who optin to this. 

Perhaps with Aftership Reviews, we could set a custom rule where if the transit time is exceeds X days, the platform won't initiate reviews.

1. What is the context?  * We are currently a Premium plan subscriber operating a high-volume merchant shipping 68% of our Canadian orders via GLS Canada. We are looking to utilize the Enhanced MPS Visibility feature to improve our customer experience.   * Currently, your documentation lists carriers like FedEx, UPS, and DHL as supported for MPS, but GLS Canada is excluded. When we contacted support, we were told this is due to "carrier limitations.   2. What issue do you want to address? We believe the "carrier limitation" rationale may be outdated or incorrect because AfterShip is already successfully pulling data for GLS child packages. * Evidence: On GLS Canada tracking number P97186751, AfterShip retrieves events for both Package 1 (Delivered Nov 21) and Package 2 (Delivered Nov 19). * The Problem: Because GLS Canada is not on your "Supported Carriers" list for MPS logic, your system aggregates these distinct events into a single "scrambled" timeline instead of separating them into tabs. * The Gap: The data exists in your system; the parsing logic to separate "Master" vs. "Child" is simply missing for this specific carrier. 3. What outcome do you expect? * We request that the product team add GLS Canada to the Enhanced MPS Visibility supported carrier list * We need the system to recognize the child packages it is already detecting and display them in separate tabs (Piece 1, Piece 2), just as it does for FedEx or UPS.   4. Who will benefit from your idea? * Merchants: This allows Canadian merchants to use your Enterprise MPS features for their dominant carrier, reducing support tickets regarding "confusing" status updates. * AfterShip: It improves the value of your Enterprise plan for the Canadian market by supporting the region's major logistics provider.

Goal: To make it easier for customers to accurately select the correct item for return when using the return portal. Preconditions: The customer has placed an order containing multiple items, some of which may have similar or identical titles, colors, or sizes. The SKU numbers for the items exist in the system but are not currently displayed in the return portal. Trigger: The customer initiates a return and accesses the return portal to select the item(s) they wish to return. Basic Flow: The customer logs into the return portal. The portal displays the items from their order, including details such as title, color, size, and now the SKU number for each item. The customer uses the SKU number to cross-reference their order confirmation or invoice, ensuring they select the correct item for return. The customer completes the return process with confidence that the correct item has been selected. Postconditions: The customer successfully returns the correct item without confusion. The support team receives fewer inquiries about mismatched returns. Benefits: For Customers: Improved user experience by reducing confusion when selecting items for return. Greater confidence in completing returns independently. For the Business: Reduced customer support requests related to returns. Increased efficiency in processing returns, minimizing errors caused by incorrect item selection. Priority: Medium – This enhancement has a high potential to improve customer satisfaction with a relatively low implementation effort. Technical Requirements: Modify the front-end display of the return portal to include SKU numbers as part of the product details. Ensure the SKU numbers are fetched and displayed consistently across all customer orders. This use case focuses on enhancing the clarity of the return process for customers while streamlining operational efficiency for the business.