As part of a site we are creating, our client wants to have a directory of offers, you can search by postcode to find offers near you, then print out coupons with unique ID numbers . Like Shopadocket. http://www.shopadocket.com.au/
Anyone done something like this or have any tips?
I have not understood the unique code requirements, here is one way to do this:
-first of all create a page where users can register and log in
-set up the "offers" as webapp items - you can then search them by ZIP code
-once an user finds a webapp he likes he opens it up and goes to the "detail" view of the webapp
How will this setup work for you?
Thanks for the tip, I will look into this.
I just need a unique ID to track who has downloaded what coupons - a case ID number would do the trick, but the bnly way to generate a case for each download would be to add a hidden form to every coupon, right?
I'm trying to make it as easy as poss for the client to manage moving forward, so coding in hidden forms will be a last resort.
I had the idea last night of using the "Quote" feature. Does that still exist in BC?
Basically send the clients to a store without them having to go through the checkout process, as the coupons are free.
So I would put all the coupons into a category in the store, then get customers to get a "Quote" rather than "Add to Cart". Then BC hopefully would send an email to the person with the details of the coupon and a "Quote Number" which I could rename as Unique ID number - and the transaction would all be tracked in the CRM. Hopefully. I have not looked into this yet though.
The method I was going to use (elsewhere) involved populating a database with pregenerated codes which could then be checked against the coupon after its printed out. This has the advantage of not requiring encryption that can be broken since the difference between a valid and invalid number (and coupon) is just whether it already exists in the system, but I haven't tried this using BC yet, and I don't know how feasible or unweildy it would be. You would obviously have to manually build coupons in a webapp and possibly remove them afterwards though.
Here is probably the best tip you will get on this one - dont use BC.
Creating a docket system that is truely robust with what you are describing would not take that much development effort for a PHP developer using a opensource platform like Drupal or Joomla.
In the case you have described BC is not the correct solution for your customer so dont use it.
Its better for you and the BC community as well - why? Simple. If your customers site goes big they will basically start asking for more and more tracking features which BC cant provide. At least if you create an app on your own you can grow it and do whatever the customer wants.
I would also say to the BC crew - if we had a web apps API this probably would not be the case but we dont, and looking at the speed of development we wont be getting it any time in the next year.
My advice, It would be best to avoid BC for this project.
although... if you have the ability to build it in php elsewhere you can set it up to be embedded in bc although that would probably be a serious pain. I'm considering doing this if it turns out it can't be done sufficiently using webapps.
What I have decided to do is build a web app directory of all the coupons.
The key is to create a case for each coupon claim, and use the case number as the unique coupon ID.
The coupons web app will be in a secure zone in this site, so customers will need to be registered and logged in to view the coupon directory.
In the Web App Item Detail View template I will insert a web form.
In the web form I will pre-populate fields (they are already logged in so I can pull in their name and email address) including the Deal URL and hopefully the Deal Description (I watched a Kiyuko tutorial on how to use module tags to pre-populate form fields). Then I will change the SUBMIT button to “Get this Deal”.
That will trigger an auto-responder email to the customer which will act as the coupon. The auto-responder will include all the form fields and the Case Number. It will tell the person that the Case Number is their unique coupon ID which they need to claim the deal. Because a case is created, I can track it in the CRM and create reports that will tell me who has claimed what deals, and what the relevant Case Numbers are for each merchant.
In the secure zone I will have a “My Case History” page where customers can view their own case history and look at what coupons they have claimed, and get their case numbers again if they need to.
I have built a very rough prototype and I think this will work.
That seems better than what I was going to do, which was just enter codes manually into a webapp without any tracking or anything. I also considered doing it through ecommerce, treating them as downloadable content but I don't know how that would work out.
Yes I looked at e-commerce too, but the e-product system just emails you a
link to download the file, so I thought if the end result is customer
receiving an email, it¹s better they get one without having to go through
the checkout process and ³buy² a free item, that¹s really clunky.
Also e-commerce only offers you one ³large product layout², which doesn¹t
suit me because I will also be selling physical products in the future and I
want more flexibility in the layout.
The web app system allows you a different layout for each web app, much
The only downside of not using the e-commerce system is not having inventory
control, (eg: merchant wants to offer 100 deals only) but I figure I can
somewhat overcome that with a disclaimer like ³offer limited to the first
100 bookings² or some such, and expiring the web app item after an agreed
number of days.
Europe, Middle East and Africa