Community Close
Login to Plimus Community
Not a Community member yet?
Get a Profile to:
- Raise Your Visibility
- Find Partners to Sell Your Products
- Find Partner Products to Sell
- Have Your Say in Blogs & Forums
Add Your Wish List
What features and solutions would you like to see added to the Ecommerce system that you are using at present? Tell fellow members of the community why such features are so important to you and why they would make such a difference.
Italiana... Why not set up a Buy Now link for the product and then send that to your client(s) via email or through the newsletter system? Sounds to me that this would achieve your objectives unless I misunderstand you.
Derek
I really would like the to see the REQUEST REFUND button removed completely from the customer order page, considering I just got 2 chargeback of sales 3 months old, I don't see how it can be useful.
I recently removed plimus as secondary vendor from my website only for that reason, since I was getting record refunds requests, and I know I'm not the only one.
I, too, have had several refunds/chargebacks requested by the customer, and in nearly every case that I can remember, it was due to the customer not recognizing the charge. Unfortunately, in one case, it was due to a bug in the Plimus system that used the *default* vendor name on the credit card bill instead of the *product* vendor name that it should have used for that product. And in that case, the customer charged back three months worth of subscription fees. They were about to cancel their subscription anyway so I had no way to re-charge them for the fees. The customer later admitted that they would have accepted the charges but didn't recognize the name.
If this option were simply a *request* refund option that simply sent a "dispute message" first allowing the vendor to research it with Plimus and the customer before refunding the money, it would resolve almost every chargeback I've ever had. And I'm sure these chargebacks are being tallied on my account and will probably one day put my account on some type of "risky vendor" list, when in reality, I'm not causing them -- almost every one I've encountered was the customer not recognizing the charge, even though I go to great lengths to tell them when they order how the order will appear on their CC receipt.
It's quite frustrating...
Hi!
What I'd like implemented would be a custom product search in which you can get results according to the parameters you specify.
The Parameters would be something like:
Refund %
Poppularity %
Earned per Sale
Gravity %
Best Regards!
I'd like to see an optional shorter payout cycle, so Vendors can choose to be paid every fortnight or week. You can retain a reserve amount, for example by making payments for week one at the end of week 2.
This would greatly help me tighten my cash flow, and I'd gladly pay for this option. A tighter cycle also means more sales, and more money for Plimus.
#1 Remove the Refund button
#2 Allow entire countries to be banned from purchasing (based on IP address). Some countries produce far more fraud than real sales. Wire transfers could still be permitted.
#3 In the order notification email, list Plimus's and the Affiliate's commission. Without this, we have no idea how much we made on the sale.
#4 All orders where the country of the IP address does not match the credit card billing country should be flagged for manual review.
#5 All orders with an IP address that matches the IP address from a prior chargeback or refund should be flagged for manual review.
#6 It seems like automatic affiliate approval no longer works.
#7 Allow vendors to ban certain IP addresses.
#8 Allow vendor to set the sensitivity and weights used for triggering manual review.
#9 Ability to require manual review for certain countries (based on IP address).
#10 When the vendor says to process a specific order without manual review, just do it, and do it fast.
One important missing feature for us is the ability to have auto-recurring eCheck (ACH) payments, like many of our utility companies allow. For our subscription service, most of our customers are businesses with a business checking account but no credit card for the business, so this would simplify things greatly. As it is now, many of our customers have an employee use their credit card and then they request reimbursement from the company -- a bit cumbersome.
This one is HUGE for us. We recently discovered that when a customer orders, the email template content in effect at that time is *copied* to their database record and used in the future for that customer. So if you, the vendor, update your email templates for the emails that go out after the sale, it won't affect any previous customers.
We use these after-the-sale emails as payment reminders, so if we wanted to change the text of the message sent a year after they order (to remind them of renewal), we can't change it. The customer will *always* get the email template that was in effect when they ordered.
This makes the whole idea of the template system useless for emails sent out after the sale. I know this was raised with the engineering group a couple of times, but to date there's been no response as to whether this will be *fixed*.
I really don't understand how the design/development team ever thought this concept would work for vendors. Why even allow existing email templates to be modified if they won't ever be sent to existing customers? I know they're also used for new sales which they will affect, but the way they're used for the send-after-x-days feature really needs to be redesigned to pull the content from the *current* template.
As it stands now, if I want my customers to get a copy of the updated template message, I'd need to cancel their contract and have them create a new one to have the system copy the current template into their database record for sending later -- simply not an acceptable solution.
My wish is simple...if I, as a vendor have a problem during business hours I would like there to be someone present at plimus who can actually pick up the phone and talk to me. It seems that in the last year or so the vendor phone number goes straight to voicemail 10 times out of 10.
Refund notices should not go to the order notification email address. Our order notification address is automatically processed so that the order can be added to our database, a key generated, and the customer notified. Therefore, if you send any other type of email to that address, we'll never see it!
I'd also like to see an option that forces any order that is placed with a free email address to go to manual review.
And one more thing, you state that "we urge you to resolve this refund request
quickly, as unhandled refund requests are automatically refunded after a few days." That is the dumbest policy ever. Any customer can request a refund - offer no good reason - reject every resolution - and they will automatically get a refund. How on earth does that make any kind of sense?
With regard to chargebacks, keep in mind that chargeback laws are extremely one-sided in favor of the customer. Chargeback fraud occurs every day, particularly with software because there is no way to force the customer to return it. Customers can issue a chargeback for any reason and the credit card companies will traditionally honor it and return the funds almost immediately, sometimes before contacting the vendor (who is Plimus in this case). It is the vendor who is responsible for the burden of proof in these cases.
I've had a number of customers chargeback payments simply because they didn't recognize them (actually because Plimus's system used the wrong contract vendor name on the credit card statement), and eventually had to simply take the loss and write it off because fighting it wasn't worth the cost of our time to do so, and we had already rendered the services that were charged back.
Reports have shown (sorry I don''t have the references in front of me) that there are a lot of customers who intentionally engage in "chargeback fraud", essentially to "steal" merchandise and services from vendors simply because they know that they can take advantage of the chargeback laws, and they'll win in the overwhelming majority of the cases.
It's a bad system for vendors, but it's really due to the credit card laws and the way the credit card companies operate, not Plimus's policies. The next time you have a bad experience as a customer and want your money back, you'll be thankful it happens so quickly ;-) but as a merchant, it's quite frustrating. Business-to-business merchants don't see it as much, but business-to-consumer vendors are certainly at risk to this type of fraud, particularly depending on the kind of software they're selling and their general target market.
The fact is that if a vendor does not respond really quickly most customers looking for a refund will initiate a chargeback procedure. If the matter proceeds to the chargeback stage then if your chargeback ratio exceeds 0.4% then you stand to be charged a $15 chargeback fee.
It makes much better sense to have a liberal refund policy and use that to build general buyer confidence, than to risk the almost inevitable chargeback scenario by maintaining a belligerant standpoint. You will reap buyer confidence and win more sales through this than you will lose. The customers who are intent on cheating will probably beat you whatever your policy.
As for forcing manual review. This is a very touchy subject. A lot of vendors are totally against manual review and would take up arms with your suggestion.
Derek, Plimus
Does Plimus have a single vendor with a chargeback ratio less than .4%? That threshold seems absurdly low. Ours is 2.7% for 2009, and its only that low because we refund many obviously fraudulent orders before they can get charged back.
As for forcing manual review for orders from free email addresses, I said that it should be an option. Currently, Plimus gives the vendor no control over how manual reviews are triggered. Adding the various features I have suggested would greatly reduce our chargeback ratio.
I've raised this before and it's a really easy implementation but since it still hasn't been done I'll bump it here. ;-)
In the recurring-charge-successfully-processed email notification to the vendor, you include the custom fields from the original order. Yeah!!!
In the recurring-charge-failed email notification to the vendor, you don't include the custom fields from the original order. Boo!!!
Simply including those fields in that message would save us several minutes for each failed transaction which we now spend logging into Plimus and enteing the Account # into the Order Locator to see which customer web site (we host web sites) failed to charge. Then we can go into our server and suspend the site. If we could just see the custom fields on the failure notice, we could avoid several minutes of lookup per notice because we'd never need to log into the Plimus site just to see which site the failed order was for.
I *know* this is not a huge implementation effort and adding those fields to the email notification couldn't possibly cause other vendors any problems, so please see if a developer could take a few minutes to add them in. They already have the logic in the "successful charge" email generator. I'd do it for free but I don't have access to the source code. ;-)
Hi Derek,
I just got an email froim a customer who recieved a failure notice. He has several web sites with us under one Plimus acocunt, and the email makes no message of which web site it is.
I looked it up for him, but it would make sense if when they implement this feature, if they added the custom field values to both the vendor AND the customer emails to give the customer more specific information about the particular order that failed to charge.
Thanks!
-- Vinnie
Along with custom fields being shown on failure notices (thanks!), it would also be helpful to have them on the regular recurring receipts that are sent to customers. I have many customers who have several accounts with us (web site hosting) and when a charge comes in, they want to know which site it is for.
Right now, even if they log in using the link in the receipt email, they don't see the custom fields. This means they have to ask me to look up the order and report back to them. Multiply that by a couple hundred customers and my time is consumed fairly quickly doing routine transaction lookups.
I have created a vendor support ticket for this request but was told it's not possible to add the fields to the receipt. Since the custom fields were added to the failure notices atg my request, and at receipt-sending time you know the transaction refrerence #, I do believe the customer record could be looked up in the database and the custom fields retrieved and added to the outgoing message. Might not be easy, but definitely should be possible. I'm posting this message here in the hopes that other vendors with this need will also express their desire to see this enhancement added.
Regardless of how difficult it may be to implement, it IS necessary -- especially for vendors with customers who have multiple subscriptions. It just doesn't make sense for vendors to manually have to do something that takes *minutes* when the system can proactively do it in *milliseconds*. ;-)
Thanks!
Have you ever considered an online Wiki or a searchable knowledgebase for vendor features/support? Having vendor CP documentation in a searchable Wiki or as articles in a knowledgebase format would be quite helpful. Does one already exist? If so, where?
Hi there -- We are currently running a test project on a new dynamic user help system that collects responses to real support questions. If this goes well it should be on site by the end of next month.
We are also putting together a longer term knowledge base project that would partly be fed from this new help system. Also we are going to add a lot more visual and video material to the Learning Center during the next couple of months, and a reorganization of its content.
So, I hope a lot of what you are after will be in place by the end of 2009. You'll also see in our next version release better interface elements for new users.
Derek, Plimus
Thanks. I like the idea of a knowledgebase or wiki for vendor support. I can understand the need for visual/video content for tutorials, but I don't see it as efficient for answering specific questions about features. That is, I think it's quicker to scan a text document of several paragraphs looking for specific answers, rather than having to sit and watch a 2 minute video where you can't really "search" for keywords, etc. to home in on your specific question's content.
Like I said, videos are cool for tutorial lessons, but I wouldn't want to see the vendor knowledgebase consist primarily of video help. Likewise, having a "user guide" is also helpful, but what I'm talking about is more of a knowledgebase (Q&A) with specific answers to specific questions, which could easily be built from the questions on this forum as well as most questions submitted to the support staff via the ticket system.
That's how we do it for our business. Whenever a question comes in that is "common" or we feel will probably be asked by other customers, we add it to our knowledgebase, which is a searchable database that offers results in Q&A format, with no answer being longer than a couple of paragraphs.
The most important features I see in a support knowledgebase are: (a) searchable by keywords, and (b) concise answers to specific questions.
I find that the user forums are helpful, but I think there is some ambiguity as to how they are treated in terms of support from Plimus. That is, there are two methods of asking for help right now: the forums and the support ticket system, but no clear rules as to when each should be used. If I have a question, suggestion, or point that I think may be helpful to others, I'll ask in the forums hoping the response will help someone else with the same issue (although since the forums aren't searchable, it may not really matter). If my question goes unanswered for several days or if it's really important and needs quick attention, I submit a ticket. Along this topic, I think the forums could do with some reorganzing in terms of categories. People tend to post problems and feature questions in the "ecommerce" discussion area, but there could really be a category just called "problems or questions" (which could even be further subdivided if need be). Also, "wish list" seems to be a mash-up of more than just suggestions for enhancements, so perhaps that could be clarfiied. I think, in general, that the forums have taken on the role of a sort-of, kind-of support area, but I don't know if that was originally intended. Unfortunately, because support response in the forums is much slower (can be 5-7 days for any given message), it gives vendors the impression that Plimus support is lacking. Might be worth clarifying that problems and questions need to be submitted via the support system. Of course, the more questions that go through the support system, the less "public" content there is to view for "self-help". That's where the wiki/KB would really fill the void.
And I realize that no company likes to air its "dirty laundry", but having known issues in the database is also helpful so we don't bang our heads trying to solve something that is a known problem in the system and has yet to be fixed.
It would also be great if a part of the same support system allowed vendors to add feature requests to the database and also view the database for existing suggestions, perhaps showing their priority and planned implementation date (if one exists at that time).
I think offering large, searchable, easily-accessible "self-help" information repositories could reduce the dependence on Plimus' live support resources, which would free them up to answer more questions more quickly. It improves the time-to-solution for customers and ulimately allows Plimus' live support staff to improve their responsiveness reputation as they will have fewer questions coming in that require manual research.
Hi there,
The objective is to cover both these formats - how-to tutorials/videos on general product features, and a knowledgebase/search answers area for all the nitty-gritty questions about the Plimus Platform.
As regards Vendor Support - specific questions should go through Vendor Support. People post into the forums as well, and whilst we try to cover the questions, we often have to get the answer from the Vendor Support or tech teams, so it will usually take longer via the forum.
Requests for features are passed on and are always taken into consideration but it can be many nonths before they are incorporated into a release. If a support ticket on a feature request has been issued usually the initiator will be informed and thanked. Closing the circle in the forum is much harder.
Derek, Plimus
I would like to see a quick reference to the amount of my pending (upcoming) payment. I know I can run a sales summary report, but it shows the gross and commission amounts separately and I need to subtract them to get the net amount of my payment.
Since the payment cycle closes at the end of each calendar month, but payment isn't usually received until around the 18th - 20th of the month, there are at least 15-20 days where you could show the expected payment for the previous month in the My Account section at the top of the page where all the other totals are shown. This number would be shown from the 1st of the month unitl the payment is actually made (some time in the middle of each month).
Just a thought.
Hello Derek,
I have a few wishes:
1. I would like to see some kind of product ranking based on sales in the marketplace, which would be a goldmine of information both for vendors and affiliates.
Sg like CB Gravity of Popularity.
It would be great if this ranking would be tied somehow with sales data, and if it would reflect which products have not made a sale for example for 1 month.
2. I also notice in the marketplace that vendors input products like
MygreatProduct - Business License
MyGreatProduct - 2 User License
MyGreatProduct - Enterprise Edition
Perhaps the schema could be altered to enable for license types instead of using the product name field :)
Cheers,
G
Hi - thanks for the suggestion. What you need to bear in mind is that these are not rigid labels or categories that have been verified by Plimus, but merely names that each respective Vendor has freely applied to his/her products and contracts as they have seen fit to do.
Derek
© 2001-2010 Plimus Corporation, Inc.
Hi Derek- thanks for asking
I enjoy plimus and love your new site...:-)
what I like to have is a simple way to create a product and send it from plimus control pannel to my client.... without spending time describing a product.
just a request for payment.
Thanks!