Share your ideas with us

Brand noted they’d like to be able to clearly communicate why certain Products are on the Blocklist - instead of the general text we have in place, without specifically making the customer review the Policy as a whole. Asking if we could define the error at the Blocklist Product Tag entry level. If the value is left blank, use default content.   Current state: After end consumer logs in with Order, non returnable items are greyed and out and we show at the line level a message that states "Does not comply with our return policy."   Desired State: After end consumer logs in with Order, non returnable items are greyed and out and we show at the line level a message from a configurable setting within RC where we can pass SKU or Product Category specific messages that state why an item is nt returnable like "Digital Goods are not returnable" or "Bundled Item cannot be returned" or "Last years models are not returnable but warranty available".   We'd like to be able to configure our own blocklist message for order item display when the end consumer logs into RC.

Hello, We would like to identify the parcels that were delivered by secured delivery methods, and which ones. For example, was the parcel delivered with a Pin Code? With a QR Code? With a signature? This would allow to better measure Exceptions per delivery method, and size the opportunity of such services, on which we are completely blind today.

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.

Would like to be able to filter the shipping exceptions so I only receive ones for damages. Especially after a club run, we can receive many notices for delivery exceptions which can include delays, intercepts, etc. However, the ones we would primarily like to receive are for damages. we would like to catch these before the customer reaches out to let us know or from the return report.

It would be great if you could automate sending out the shipment tracking dashboard, and allow filters for that report, lijke the analysis report.  This enbales us to send the report to customers and others in our team as a live snapshot of their shipments. It consolidates all their shipments into one view so they don't have to track them individually each day. 

I am utilizing Smile to develop the Reward program for our business. This year, I aim to motivate members to increase their reviews by integrating Reviews into the reward system as bonus incentives. This will allow our members to accumulate extra points by sharing feedback for their purchases.

I would find it very useful if I could pull the SMS communication metadata using an API. Currently it is only available as a download from the portal which makes automation impossible.

It would be useful to have a Sku column amognst the list when editing the returns dashboard. The image of the item is useful but often the item is enclosed in a boxed which is marked with the sku. Therefore at first glance, the sku is seen before the physical item.

Would love to see carrier support added for MyPost Business by Australia Post.  This is already an integration in ShipStation, Starshipit and Shopify - it would be a valuable addition to Aftership Shipping and Aftership Returns.

Currently, AfterShip's webhook outgoing IP list is only available on an HTML documentation page (https://www.aftership.com/docs/tracking/webhook/webhook-outgoing-ips). This makes it impossible to automate IP allowlist management in infrastructure-as-code (IaC) workflows.   Problem: Teams that use IP-based firewalls to secure their webhook endpoints must manually monitor the documentation page for any IP changes and update their firewall rules accordingly. If a change is missed, it can cause webhook delivery failures and broken integrations.   Request: Please publish the webhook outgoing IP list as a dedicated plain-text endpoint — similar to how Cloudflare publishes theirs at https://www.cloudflare.com/ips-v4 — where each IP is returned on a separate line.   This would allow teams to: * Fetch the IP list programmatically as part of their CI/CD or IaC pipelines * Keep firewall allowlists automatically in sync without manual intervention * Avoid service disruptions caused by missed IP changes This is a standard practice among major API providers and would significantly improve the developer experience for customers who manage network security programmatically.