Sure @lin_d_hop I definitely agree add it ! I’ll make the post a wiki in case you can’t edit.
I"ve voted for this - but frustrating that I had reached my vote limit - so I had to withdraw a vote from a wishlist item I previously voted for. I think we should consider tweaking our process - it would make more sense to me at least, if I had all the wishlists, in a given time period, in front of me so I can compare them - rather than having to go back and pull votes from earlier items. Sorry - I’m just not getting the wishlist voting.
I know @tschumilas but that’s the game, we won’t prevent that new wishlist open all the times, so we might change our mind depending on things that comes. You can check your votes on your profile “my vote” so it makes it easier to see what are your 5 priorities and check that they really are. We try and we will see after some time and iterate, we are just starting now ! And have still quite a lot in the pipe, but with Rachel we will start in the coming weeks to move on inception work the most voted item to start specifying clearly and prepare for the dev pipeline, but we will announce to make sure all votes are done.
@sstead @nick @Kirsten @danielle @MyriamBoure @Rachel @sauloperez @Matt-Yorkley
I’ve updated the above wishlist item to make it about Customers being able to use their credit for undelivered goods etc inside OFN. I suspect this might be useful to users in many places. If you have spare votes and know your hubs would appreciate this basic feature how about swinging this an upvote?
I understand this - so once I see something has moved to inception - then I’m able to re-allocate those votes - am I right? Or do the votes at inception matter?
Great @lin_d_hop !
One slight comment:
- Hubs also need to set up a limit under which a member won’t be able to buy (ex: -100€ then they can’t buy if they don’t top-up)
I don’t understand the need. For me the need is more for the hub to ensure the customer can pay if he pays only with credit. I would rephrase “hub can decide if a user can pay only with credit or with other methods as well. If only credits is used, order should be blocked if credit is not sufficient to pay.” If I didn’t understand well the need behind that, please explain.
About partial payment, I agree but I wonder how this would happen with current OFN checkout, as you can only checkout with one method. Maybe hub can set up a rule like “if customer has credit, use it first and only mark as balance due the difference”, and then we need to adapt the UX so that if the customer has a credit, when she clicks on “checkout” she is notified that as she had X remaining on her balance, she would owe X / or X€ only have been charged on the credit card. Something like that. It will come at discovery/inception stage for sure…
Also, maybe we should split this feature in:
- v1 = if customer has credit on her account, it is automatically used first whatever the payment method she uses. So adapt UX as a consequence and enable hub manager to enable/disable that behavior (to check, lots of hubs never capture payment so lots of customers have huuuuge balance due, not sure there is an impact…). If some hubs want to propose customers to top up their account, they can already start with selling “vouchers” type of product, they then need to make an adjustment corresponding to the voucher so that a credit appear in the account, so user can use it. It is a bit hacky, we don’t cover topping up credits on v1, but if some hubs want they can use that workaround.
We release that, test and learn.
- then v2 = we add the possibility to top-up their account for a customer (need to investigate various options) and we add some other rules, like the possibility for the hub manager to decide if customer can pay only with credits, or not, etc.
What do you think about “phasing” it ? We should learn from the past, trying to release asap small first bits that already impove the situation. That’s why I propose to split and prioritize already v1, learn, and then prioritize v2 (maybe straight, maybe we’ll want to prioritize something else in the middle).
@tschumilas I would say, until it is in the pipe, your vote still count. For instance even if we have done the inception on this one and feature is ready to be implemented, you might want to tell that something more priority has come up and you reallocate your vote to prioritize something else before that. I would suggest to start doing it that way, and try and learn
@MyriamBoure You wrote that need. I don’t understand it either so feel free to remove it. I certainly have no need for it.
Also, top ups are possible already in OFN. Just difficult. You can process a payment that is larger than the amount of the order - which is the same as a top up but must be tied to an order.
So I would say this epic has 2 key features:
Enable payment from credit at checkout. This could be a checkbox that shows when someone has credit, or even a voucher code they generate to give a discount off the order equal to their credit (I dont think that solution is a good one, just a brainstorm). It might be enabling 2 payment methods at checkout (overkill).
Enabling a payment to be made that is not attached to an order, such that top ups can be made.
For me 2) has a workaround so is a lower priority. I would agree to starting with part 1 then adding part two after.
But we are getting ahead of ourselves
I didn’t remember, you know
Why do you say @lin_d_hop “we are getting ahead of ourselves”?
The idea of wishlist is to curate and split things that can be prioritize also, we do all that work here to be able to move things forward. So I’m straight away going to split that wishlist into to, get out the top up thing out of here in another wishlist, so we only start priroitizing part one.
Let’s avoid the “epic” and just talk about two features, we want to prioritize only one first. Now that it’s becoming clearer we can start listing potential solutions as you just proposed. I’ll open it now, as a wiki so you can add other ideas you may have.
Cool. Nice one @MyriamBoure
I see a complication here with the voting system. In this case I think it is ok as the votes hold for this feature (I think) but when these discussions change in scope it changes the voting process. I remember experiencing this before, on the OFN Map topic for example.
This isn’t a criticism, just an observation for future process development. And this is why I thought we were getting ahead of ourselves… because by breaking it down at that point we were messing with the voting system and that step might be better done after. But I do agree that this is better as two different topics.
@lin_d_hop check if I captured the need ok and listed ok the potential solutions, and add others if needed. I wonder if hub manager should be able to enable/disable some behavior here? Don’t think so, just asking.
I agree with you about messing up voting, but somethimes people open wishlist with 10 ideas in it, we need to curate, clean and split a bit before it can be voted. So I wonder if we shouldn’t point any new wishlist to some “in curation” stage, and when we have done this job we are doing here, we move the cleaned items to wishlist and there they can be voted.
In our present case, this need should obviously be done first, so it’s logical the vote stays on this one. Or maybe if we split a wishlist we should close and ask people who voted for it to revote on one of the new wishlist?
People need to be clear what they vote for… what do you think of those two options @lin_d_hop ? Curation step vs closing and opening others (with linking to keep track of reasoning) so votes have to be reallocated ?
I think I prefer the ‘In Curation’ option as a pre-step. 0-WishlistCuration 1-VotingCandidates
I prefer this because most people that work on OFN really will never keep up with all the changes. It is luxury for most people to be able to engage once or twice a week in the community forum as we’re all so busy. If you vote then it is deleted and then you need to vote again I, for one, would often lose track during busy times.
This will also make it easier for anyone to be able to post wishlist items, even if they have little experience with the ins and outs of OFN. WishlistCuration items can be posted to invite more discussion from seasoned OFNers to turn into something realistic, useful, applicable etc.
Whats the process to change process? Does it come up in a global hangout?
I agree with you @lin_d_hop We are still “scrabbling about” / “fumbling” / “tweaking” the process to make it usable, so for now we discuss every x week with other active train drivers to test and adapt quickly. I think I’ll create already the category and move some things here and there to see how it would look like and see if it’s better. And we will plan another iteration to discuss this new valuable input that you made So we experiment in small loops outside of global hangouts and then share improvements and experiments in global hangouts so involve the community in those “fumbling”
Love the feature suggestion. Highly needed for our CSA in Belgium. Would likely enable to use payment installments quite transparently.
Suggested option 1 to implement it as default payment method provided positive (or above threshold) balance seems intuitive enough.
… and voting system is intuive enough for a newbie like me. But then again I may experience similar problems when I need to make up my mind between more topics in a few weeks
Thanks for the great work !
… and (pretty) please add the current balance to the customers report.
@danielle @Rachel @MyriamBoure - so this is an interesting one. I’d be inclined to argue that @berteh’s little addition here “add current balance to the customers report” would fall into ‘make what we have great’ whereas paying with credits is new feature . .
I am currently asking UK users how much time this would save them.
I think this comes under - Remove the pain points that make users want to walk away
Missing this feature means that hubs have to spend hours a month sending little bank transfers and updating external accounting systems.
One Food Hub reported back that currently they manually either update a spreadsheet with credits, or make cash refunds or make tiny bank transfers. They report that this process takes ~2 hours a week.
These are exactly the kinds of tasks that make users want to walk away from OFN. I would make a strong case for this feature being part of:
Goal 3 - Enterprise admin UX pain points that suck our users’ will to continue.
Totally agree - at some point these things aren’t just stopping new enterprises from joining - they are also damaging our reputation out there.
More than reputation and onboarding - this goes against our mission - to help values-driven food enterprises to be viable and efficient.