Sarah Parmenter

Throwing it out there…

I’ve been wondering about the best way to handle memberships within a physical environment, such as a shop. I want to be able to allocate services to that membership and then when that person comes into the shop to redeem an allocated service, be able to record it and have it come off the total.

This creates a few head scratching problems.

1) People sign up to memberships on different days of the month, which means, simply re-allocating the services say, on the 1st of each month, wouldn’t work. Amending each by hand, would be a no-go. I want the memberships to be handled by GoCardless via Direct Debit but GoCardless can’t tell what we’re allocating it against, of course.

2) I want them to take away a physical thing i.e a card. The card can be linked to a barcode reader but probably better for it to just have an individual membership number that is printed, then linked through to a database against that number, rather than another piece of software?

3) Is it best to just build a database for these members and have staff tick off allocations as they happen and re-allocate, somehow, on a given date?

There are plenty of “loyalty-based” systems (handheld systems that read the cards themselves!), but they seem a bit over-engineered for what I’m looking for. Probably really easy to all you ROR devs out there. I’m left head scratching and looking to technology to answer it. Any help, greatly appreciated.

This article was posted in Work Life. Bookmark the permalink. Follow comments with the RSS feed for this post.Post a Comment or leave a trackback: Trackback URL.

4 Comments

  1. Posted June 10, 2013 at 6:31 pm | Permalink

    I’m fairly sure GoCardless can bill on any day you want it to.

    Not entirely sure what you mean by “GoCardless can’t tell what we’re allocating it against, of course”. You mean if say, you’re allocating against a card?

    Stripe is currently in beta in the UK and would be my payment processor of choice if direct debit felt a bit weird for your customers to use.

    You realise that loyalty systems don’t have to be written in Rails right?

  2. Posted June 14, 2013 at 10:20 am | Permalink

    If I was building a web app to do it, I’d have a table of subscriptions, and a table of allocations. Each subscription would have a renewal date. I’d have a nightly cronjob run, find any subscriptions with a renewal date of today, and take payment.

    If payment is successful, set the renewal date to a month’s time, and then add some new allocations.

    The table of allocations would include a row for each service the membership allows, and an expiry date for the allocation (which would be the new renewal date – a month in the future). I’d have a ‘date used’ column so that an allocation can be marked as used. (So columns would be member ID, service, date used and expiry date, perhaps.)

    I’d then have a page for use in-store where the member ID could be entered (or scanned) and then show any allocations for that member that have no used date and haven’t passed the expiry date. And a button to mark any as used with today’s date.

    I’d resist the temptation to clean up and delete any expired allocations – they’ll be useful for reporting in the future. You’ll want to know how many people paid for things they didn’t use, or used them as soon as they became available (keen customers) or just before they expired (customers likely to cancel).

    Bit of a brain dump, but perhaps there’s something useful buried in there. Good luck! So many fun projects when starting something new.

    • Posted September 1, 2013 at 12:41 pm | Permalink

      Drew’s outline is an excellent outline for this kind of project. It doesn’t have to be built in Ruby; any database-capable language could easily pull this off.

      You could bave a membership number AND barcode for the same number on the membership cards – barcode scanners are emulated keyboards to a computer so you can scan the barcode into any application.

      Fairly simple to put together if you just wanted to get the basics in place to start with and build on it later – any competent applications programmer should be able to code this in a day max.

  3. Posted January 6, 2014 at 6:42 pm | Permalink

    Hey Sarah,
    I just happened across this post after having listened to a few of your Happy Monday episodes. (I also took one of your classes in NYC a couple years back. :)

    My wife happened to have opened a yoga studio a couple years back, and we made her a piece of software (http://tulasoftware.com) that now a lot of other yoga studios are using to run their businesses, and one of the things we do is handle memberships in a physical environment.

    While geared for yoga and dance type studios, we’ve learned is that it’s also been ‘hacked’ by some folks to handle pretty much any kind of class based business.

    I don’t know if what we’ve made would be perfect for what you’re looking for – if you’re still looking – but it can be used to:

    * Handle memberships
    * Collect online payments
    * Set up things like workshops as ‘one off’ type of events
    * Track student attendances, etc.

    We base everything on name and email because we wanted to avoid even physical cards – but no reason you couldn’t make cards if you wanted to.

    We integrated with stripe for payments.

    You can check the product out at http://tulasoftware.com and a bunch of detailed documentation at http://docs.tulasoftware.com.

    Wishing I would have run across this a few months back – but if you have any questions please don’t hesitate to write me!

Post a Comment

Your email is kept private. Required fields are marked *

*
*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>