We’re launching a public feature-voting board today. The goal: stop guessing about what merchants want and start measuring.
Where: hub.axnify.com → “Feature requests” category (now visible in the sidebar).
How it works:
- Anyone with an Axnify account can post a feature request or vote on existing ones.
- Everyone gets votes — vote weights you spread across requests you care about.
- Top-voted requests get reviewed monthly by product team. We respond publicly with status: “planned,” “in progress,” “shipped,” “won’t do” (with reasoning).
- We’re transparent: even “won’t do” decisions get a public reason. You may disagree, but you’ll know why.
What’s already on there: we seeded the board with the top 30 requests from support tickets and forum threads. So there’s existing content to vote on while you think about what to add.
Realistic expectations:
- Voting doesn’t guarantee a feature gets built — high votes signal demand but commercial / technical viability also factor in.
- Small UX improvements: typical 1-2 day turnaround once we commit.
- Big features: typical 1-2 weeks from “planned” to “shipped.”
- Some highly-voted features compete with strategic platform direction; we’ll explain when that happens.
Action: visit the Feature Requests category, vote on what matters to you, post new requests if you don’t see what you want.
Looking forward to seeing what rises to the top.
The adjacent “Advanced behaviour” toggle you noticed: it’s an escape hatch for merchants who need to override the default heuristics with explicit logic. Most merchants leave it off; the default behaviour is what we recommend for ~95% of cases. The reason it’s there at all is for the 5% with unusual setups where the default makes assumptions that don’t fit.
Concretely, flipping it on changes how feature voting resolves ambiguity when two rules could apply. Default = our opinion. Advanced = your opinion (you specify the precedence). Not dangerous to flip if you’re curious, but you’ll need to set the precedence rules afterward for it to do anything useful. The tooltip is admittedly vague — I’ve passed that on to the docs team.
For your specific question: leave it alone unless you have an active reason to override the defaults.
Coming at this from a slightly different angle: I’m a developer building tooling around the API for my brand, and the answer above implies the same behaviour applies to API consumers as it does to admin-UI users. Can someone confirm that’s the case? Specifically, if I make a change via PUT /api/whatever, do I see the same 60s eventual-consistency window before reads return the updated value, or does the API skip the cache layer?
Asking because my testing scripts assume immediate consistency, and if there’s actually a 60s gap I need to add a sleep or a retry-until-consistent loop.
Just voted. The ‘cross-shop customer aggregation view’ has been my top request for months — happy to put 3 votes on it. The transparent ‘won’t do with reason’ commitment is the part that builds trust; most platforms ghost feature requests.
Final question and then I’ll let this thread rest: is there a way to subscribe to updates specifically about feature voting for future changes? If you ship an improvement or change the default behaviour, I’d like to know. The general changelog is a lot to read; a tag-based filter on the changelog would be ideal.
Either way, thank you to everyone in the thread. Resolving this took me from “guess and check” to “confident I understand the model,” which is the whole point of community support.