Telephone Orders

[burt]

That said, it's still valuable to know what shopowners are looking for.
We have some good coders in the eco-system, you never know if they are looking for a project.

[Xpajun]

It's easier to do it on the front end than recode - the amount of people phoning up to oder is very low (although it may be frowned up on by payment gateways)

I don't know what "very low" is.
Steve says 5 a week in the previous post.
Yours is similar?

Some type of admin side system might take (rough guess) 60 hours coding and testing, fixing, recoding, retesting, alpha testing, collating test results, recoding, beta test etc. 60 hours of a developers time is a lot of dough.

Put into a "time is money" context, that Queued Emails thing I made is, more or less, roughly equivalent in terms of code and time. I'm at a net loss of low 5 figures GBP (that's low 5 without a decimal point ) on that

My point is, I think;

Does "very low" usage tally with the somewhat large cost of creation of a MOTO system.

Mine is a lot less than 5 a week - 5 a month woud be a bit high

It was just a suggestion really I thought the numbers may be higher - I do know some payments gateways frown on putting an order through on the front end although I'm not quite sure what the difference is as for remembering the customers card details - there's no chance of that with me.... what we talking about???

[Xpajun]

It's easier to do it on the front end than recode - the amount of people phoning up to oder is very low (although it may be frowned up on by payment gateways)

I don't know what "very low" is.
Steve says 5 a week in the previous post.
Yours is similar?

Some type of admin side system might take (rough guess) 60 hours coding and testing, fixing, recoding, retesting, alpha testing, collating test results, recoding, beta test etc. 60 hours of a developers time is a lot of dough.

Put into a "time is money" context, that Queued Emails thing I made is, more or less, roughly equivalent in terms of code and time. I'm at a net loss of low 5 figures GBP (that's low 5 without a decimal point ) on that

My point is, I think;

Does "very low" usage tally with the somewhat large cost of creation of a MOTO system.

@BrockleyJohn was the updater of the last one I used - pretty certain that he never updated it again or for Phoenix but he would be the one to ask about how popular it was by the number of download it got

[BrockleyJohn]

It's easier to do it on the front end than recode - the amount of people phoning up to oder is very low (although it may be frowned up on by payment gateways)

I don't know what "very low" is.
Steve says 5 a week in the previous post.
Yours is similar?

Some type of admin side system might take (rough guess) 60 hours coding and testing, fixing, recoding, retesting, alpha testing, collating test results, recoding, beta test etc. 60 hours of a developers time is a lot of dough.

Put into a "time is money" context, that Queued Emails thing I made is, more or less, roughly equivalent in terms of code and time. I'm at a net loss of low 5 figures GBP (that's low 5 without a decimal point ) on that

My point is, I think;

Does "very low" usage tally with the somewhat large cost of creation of a MOTO system.

@BrockleyJohn was the updater of the last one I used - pretty certain that he never updated it again or for Phoenix but he would be the one to ask about how popular it was by the number of download it got

I assume you mean the order editor; I'm afraid that as it was a free addon I've no idea now many downloads there were but the support thread was quite busy. @zipurman already did a paid one for phoenix (though I don't know if you can create customers/orders with it).
All you need to use the front end for MOTO is an (e.g. ip-filtered) payment method that admin can choose to record offline payments which is way cheaper than an admin-side screen. Some sites already have a pay-afterwards-by-bank-transfer method which already does that.
I am convinced (with no evidence to back it up) that there's far higher usage for editing orders than creating them, so a MOTO screen would need to be an extension of that; less incremental work than a standalone.

There are a bunch of admin addons I'm intending to revisit as the backend settles down - will have to see which get done.

[zipurman]

Order Editor does allow for creation of new orders.

It does not allow for digital payments (PayPal, Credit Card, etc). You can simply create an order and reference a payment type, but it wont actually collect the payment. I would never add payment processing to the order editor as it would have to tie into the Pheonix front-end payment processing addons, and that can be tricky in the admin framework. Payments could be taken over the phone, processed manually and then new order created with chosen payment type.

It also does not allow for customer creation. This could be added easily enough to the Order Editor if I had enough user interest.

[LeeFoster]

I work for an online retailer and we just stopped taking payments over the phone, we take the order and then send the customer a link to make a payment.

Something similar could work here, create the order in admin but then have the customer complete the payment themselves from the front end.

[CDNYYC]

I work for an online retailer and we just stopped taking payments over the phone, we take the order and then send the customer a link to make a payment.

Something similar could work here, create the order in admin but then have the customer complete the payment themselves from the front end.

We use Zipurman's Master Password addon. We can access the customers account or create a new account, edit their order or create a new order(with a temp PW). Notify the customer that the order is ready for payment, include the temp PW (strong recommendation included to change PW). Customer can then complete payment. Works well, we average 1 to 3 orders a month, so it is fairly easy to work with.

[14Steve14]

Most of our phone orders come from replies we get to Recover cart emails. We notice that customers have tried to make a payment, and that payment fails for some reason. Once we check in the payment processor we can see why the payment failed and an email sent to the customer explains why the payment failed. It advises to try again correcting the wrong info they entered or to give us a ring.

Most choose to give us a ring as the usual reason is that 3DSecure failed. This may just be our particular customers, but it does go to show, that with a correctly worded recover carts email, or payment failed email you can get the sale back on track. We finalise the payment for the customer through their account using a master password. We did speak to the payment processor first and they don't mind it being done this way but you have to be secure with the card details and must send an email from the payment processor after the sale, as well as the store emails.

If you are wanting that type of email look at Gary's @burt queued email addon app.php/addons/paid_addon/scheduler_cart_reminder/. It could save you the cost within a few sales.

[burt]

app.php/addons/free_addon/advanced_orde ... %28aom%29/
from @Mort_Lemur