OFN supports users being in credit on their accounts. Users are able to see this from the Accounts page. Hub managers are able to credit users accounts if they wish manually. However users are currently not able to spend this credit.
This is problematic for a number of reasons:
Hub managers often have to process small transfers to customers to refund them when goods are damaged or not delivered. This is very common in pre-ordering systems and so creates substantial tasks for the hubs. For some hub managers this means that they do not use the payments systems in OFN at all, taking payments through external accounting software.
Some hubs want their members to put money on their account/wallet before they can buy anything in a shop and use that āwalletā to pay their order. They want that in order to reduce non-payment risks and reduce fees they pay on payments (usually there is a fixed fee per payment in any payment gateway). For that they need the users to be able to pay with those credits on the first hand.
In short, customers need to be able to pay with their account credit at checkout. This might be a partial payment or full payment.
Questions : shall hub manager be able to enable / disable that behavior ?
Lynne: For the UK this will be important as some hubs have complicated work-arounds to this problem by using external accounting systems and they wont want to change their systems because of this feature.
Who does it impact
Any hub that has to process refunds for undelivered goods.
Mary/Shannon who work today with advance payments models. In France for instance Alterconso.
What is the current impact of this problem
Hub managers spend much extra time processing tiny refunds.
Hub managers use external OFN software to take payments, which significantly devalues OFN to them
Prevent use of OFN: hubs that works like that canāt use OFN today, even if they would like to.
What is the benefit in focusing on this
This is a basic ecommerce expected feature
Causes significant customer pain when they dont have the correct OFN credit, meaning hubs lose customers
Hub manager have to deal with angry customers and many small refunds to keep their business operating.
Get new OFN users.
Potential solutions that will solve this problem
Option 1: if credit, automatically deduced from bill when on checkout page by adding a new line on the summary, on the right side of the page āCredit = (xā¬)ā and so amount to pay is adapted, credits are deduced automatically.
Option 2: add a checkbox for shoppers to be able to choose to use their credit on this order. Probably not a great solution.
Option 3: when there is a credit for a given order, a voucher code is generated automatically for the amount of the credit, and can be used as a discount in a next order. This gives the shopper flexibility and simultaneously solves another user need. It would also be more compatible with some user systems that use accounting software as a workaround to this issue. However it is not the most intuitive solution.
Option 4: Enabling 2 payment methods at checkout (overkill).
Discovery reflections
With current OFN checkout,you can only checkout with one method. UX suggestion = if customer has credit, whatever method is chosen, credit is used first and only the difference remain as balance due and needs to be paid, either by card at checkout, or other payment method.
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.
T-shirt size of the selected feature candidate
TBD
Metrics to measure if need is well satisfied after feature has been implemented
TBD
Feature owners :
Product:
Tech:
Epic and/or project board where you can follow implementation
This problem is the same as the problem that comes up for any customer with a credit due to unsupplied stock.
For example, a customer orders bananas and oranges and only the bananas are delivered. Currently (thanks to this work) the customer will actually have a credit in a shop, and see the credit in OFN Accounts section, but cant actually USE the credit in the shop.
This results in hub managers having to spend annoying time refunding customers. For many UK users it means that they just donāt use OFN to manage customer accounts at all, and instead manually put things into an accounting package.
@MyriamBoure Would you mind if I change this wishlist item to include the use case I describe? I really do not think they are separate issuesā¦ OFN already letās a user have a positive credit as you describe. They just canāt use it at checkout. It is exactly the same issue.
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@NickWeir@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?
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
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.
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.
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
@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.
I donāt understand it either so feel free to remove it. I certainly have no need for it.