Members

As with Employee and Customer data, the first questions regarding Member data are: What is it, and what does it have to do with Rattail?

Rattail’s concept of a “Member” comes primarily from the world of retail food co-ops, where a Member is more like a Customer than an Employee. But there exist also worker co-ops, where a Member is really more like an Employee. Rattail’s Member features are meant to acommodate both scenarios.

Members often have some equity account associated with them, with join and (where applicable) withdrawal dates, and usually also a payment history for the equity.

So if your organization has a membership component, then you most likely already have some way to track accounts and equity etc. Why bring it into Rattail?

As usual the first answer is simple visibility. For instance you might be tracking accounts in a spreadsheet or Microsoft Access, or any of a number of similar “undesirable” solutions. Even if you continue with that tracking approach, you also could periodically import data to Rattail just so it can be more easily viewed by others via the web app.

And part of visibility is cross-referencing related data. Maybe you already have a good way to view accounts, but you have no way to view an account alongside its equity, or perhaps POS Transaction history etc. Showing the various types of data on one screen (maybe with a link back to the other system) can be quite helpful in some cases.

Another potential feature is to send email reminders to Members who have an upcoming payment due, etc. based on their account details. And it’s possible to monitor an IMAP folder for any “bounces” that result from sending such reminders, in which case can e.g. flag the account as having a bad email on file.

Similarly a Member account status may dynamically affect which discounts are available to their Customer account at the POS. This idea depends on the ability to effect certain changes in the POS system, e.g. add/remove electronic coupons for an account.

But..everything just stated is technically possible without importing the data to Rattail. So still at this point we’ve not established a good reason to actually import it.

You can of course create batches for performing account maintenance in whatever way is needed. Same general “rules” apply as for other (e.g. Customer) tables. Member data need not be imported into Rattail in order to use the batch features.

But unlike the Customer data, where the POS is frequently the obvious “authority”, many times Member data is not tracked (well) by the POS, and so custom spreadsheet workflows or similar tactics are employed to keep track of it.

So this finally is why you might want to import it into Rattail. Any tasks being managed via spreadsheet workflows (or whatever) can instead be managed directly in the web app.

If you choose this route, a couple of implications:

Rattail becomes your primary Member system, and you (presumably / ideally) no longer need your previous system for that, other than to keep it as an archive.

Data is maintained directly in the web app, for instance creating a new Member account, or withdrawing one etc. Also equity payments could be entered directly if they happen outside of the POS, e.g. when someone mails a check.

But equity payments still likely will happen in the POS also. And for this to work “seamlessly” it means Rattail must monitor the POS Transactions which occur, at whatever frequency is acceptable. Near real-time is possible and in some cases necessary for sake of dynamic coupons etc. But in other cases a nightly processing of the previous day’s transactions may be sufficient.