Difference between revisions of "Membership process wip"
m |
m (add BoardProcess category) |
||
(7 intermediate revisions by one other user not shown) | |||
Line 25: | Line 25: | ||
** Opens up a protected URL and helps new member fill in an online form | ** Opens up a protected URL and helps new member fill in an online form | ||
**OR | **OR | ||
− | ** Creates a publically accessible URL for new member , sent by mail/whatever, | + | ** Creates a publically accessible URL for new member , sent by mail/whatever, which allows a new member to |
− | which allows a new member to | + | *** Read policies/info/etc about the space |
− | ** Read policies/info/etc about the space | + | *** fill in details required for membership (most of it) by himself; sanity-check input for nick-collisions, etc. |
− | ** fill in details required for membership (most of it) by himself; sanity-check input for nick-collisions, etc. | + | *** Allow member to specify mailinglist-preferences |
− | ** Allow member to specify mailinglist-preferences | ||
Line 43: | Line 42: | ||
** Send a summary to admin@board.techinc.nl | ** Send a summary to admin@board.techinc.nl | ||
− | == | + | ==STEPS== |
− | + | [[File:member-process-v1.svg|thumb|Process shown in schematic form]] | |
Steps of procedure: | Steps of procedure: | ||
* handson (fill in memberform, handson with member | * handson (fill in memberform, handson with member | ||
Line 64: | Line 63: | ||
* Go to board.techinc.nl/tools/ and choose EITHER: | * Go to board.techinc.nl/tools/ and choose EITHER: | ||
** Option 'Fill in Memberform' | ** Option 'Fill in Memberform' | ||
− | OR | + | ** OR |
− | ** Option 'Create token for remote memberform fillin | + | ** Option 'Create token for remote memberform fillin (remote subscription) |
+ | |||
+ | ===remote subscription=== | ||
+ | * prospective member lands on page, presnted with: | ||
+ | ** Links to terms/conditions | ||
+ | ** Links to useful info | ||
+ | ** Memberform with member-useful info to be filled in (YES wants fob, but not info about how it is/was paid, what fob-id was/is, etc) | ||
+ | ** System validates form; checks sanity for nickname collisions, missing entries, etc. | ||
+ | ** Has opportunity to review form before submission OR cancel | ||
+ | ** Proceed to 'validation' if confirmed | ||
+ | |||
===validation=== | ===validation=== | ||
Line 85: | Line 94: | ||
** process data into tinance | ** process data into tinance | ||
** Process data into mailman | ** Process data into mailman | ||
+ | ** Process data into doorbot | ||
+ | ** Send fob-process request to UR | ||
** Process data into membership-form-database | ** Process data into membership-form-database | ||
** Send confirmation mail with neat overview of all relevant data to the member (suggested: pdf with secure signature) | ** Send confirmation mail with neat overview of all relevant data to the member (suggested: pdf with secure signature) | ||
If something fails at some point; mail admin@board.techinc.nl with link to validation-page to re-do the form; providing info about what went wrong | If something fails at some point; mail admin@board.techinc.nl with link to validation-page to re-do the form; providing info about what went wrong | ||
− | |||
==System== | ==System== | ||
==Implications/limitations== | ==Implications/limitations== | ||
It would be most preferable to have the data of old members retro-actively added into this system so that there is a concise way to find all data about all members when required. | It would be most preferable to have the data of old members retro-actively added into this system so that there is a concise way to find all data about all members when required. | ||
+ | |||
+ | =Cancel membership= | ||
+ | Members do leave. Which things need to be considered/done/handled and how do we make sure that all the different things are in sync ? (esp. UR/doorbot) | ||
+ | |||
+ | =Schedule action for later activition= | ||
+ | Sometimes, cancelations/activations/changes need to be scheduled for a later date; especially when somebody just paid for a month but announces that he/she wants to cancel his/her membership. There is currently no way to 'disable in the future', nor to be reminded of having to perform some action in the future (if not possible to have happen automatically) | ||
+ | |||
+ | =Payment reminders= | ||
+ | This part of things is critical in having the association stay healthy and to be able to know how many real members we have. | ||
+ | A crucial concept here is closer integration of the process with a ticket/handling system that keeps track of what's been sent, what the status is, and that also gets updated when a bank-transfer changes the status if the person doesnt mail to inform us (currently, tickets for people that PAID after reminding them stay OPEN, unless the person triggers a check by having mailed us to inform us to expect a payment..., to give an example..) | ||
+ | |||
+ | |||
+ | =Detection of expiring year memberships= | ||
+ | It'd be good to anticipate an expiring long-term membership (6months or more ?) at least a little while before it happens and trigger a ticket for a mail to be composed/created | ||
+ | |||
+ | =Invoice generation= | ||
+ | Using info from the member-form-db could make this a much easier process. | ||
+ | |||
+ | [[Category:BoardProcess]] |
Latest revision as of 17:16, 12 September 2020
Contents
Introduction
There's a need to integrate/streamline a number of procedures/tools regarding the way we currently handle memberships of the space. Most of these have to do with handling member-forms, doorfobs, etc.
New Member
Currently
Bringing in a new member involves a number of things that currently are seperate:
- Inform member about rules/rights/etc of the space.
- Fill in memberform
- Transfer memberform content into online form
- Add member to the tinance system
- Inform member about joining our mailinglist
Suggested future situation
Informing the member about how things work will be unavoidable, also in the future, but might involve more pre-made/pre-prepared materials in online or paper form. The rest, however, can be modernized a little.
- NO paper form anymore
- Online form system that auto-performs a number of steps
- Include subscription to members-list to the process
Procedure
- Board-member either:
- Opens up a protected URL and helps new member fill in an online form
- OR
- Creates a publically accessible URL for new member , sent by mail/whatever, which allows a new member to
- Read policies/info/etc about the space
- fill in details required for membership (most of it) by himself; sanity-check input for nick-collisions, etc.
- Allow member to specify mailinglist-preferences
- Upon completion, form is checked/completed (administrative info about fob/etc) and 'approved'
- The approval triggers sending a verification-email to the new member who has to reply to it and/or visit included link
- Upon confirmation:
- Add user to tinance
- Contents of memberform *logged* for future reference in some way. preferably in a verifiable/signed manner: a pdf signed with pgp-key would be useful.
- Contents of memberform *SENT* to new member with all the detail as filled in/confirmed/verified. PDF signed with PGP-key ?
- Contents (also) added to an electronically searchable medium (a DB of memberforms)
- Add user to mailinglist(s)
- Send a summary to admin@board.techinc.nl
STEPS
Steps of procedure:
- handson (fill in memberform, handson with member
- OR
- invite (create token, send to new member)
- remote subscription (Fill in memberform)
after which:
- validation (review filled in form)
- verification (mail member with request to validate subscription)
- processing (upon verification, subscribe member; process data with several tools)
handson
- go to board.techinc.nl/tools/, option 'Handson Member Form'
- Fill in form contents with member input.
- Upon completion, submit. This will procede to 'validation'
Invite
- Go to board.techinc.nl/tools/ and choose EITHER:
- Option 'Fill in Memberform'
- OR
- Option 'Create token for remote memberform fillin (remote subscription)
remote subscription
- prospective member lands on page, presnted with:
- Links to terms/conditions
- Links to useful info
- Memberform with member-useful info to be filled in (YES wants fob, but not info about how it is/was paid, what fob-id was/is, etc)
- System validates form; checks sanity for nickname collisions, missing entries, etc.
- Has opportunity to review form before submission OR cancel
- Proceed to 'validation' if confirmed
validation
- Take input of filled in memberform and perform input-checking
- Perform sanity-check on certain items
- Present information; note peculiarities; allow for corrections
- Allow for 'rejection' at this point; if 'accepted', proceed to 'verification'
verification
- generate an overview of filled in data that is relevant to a new member to be able to review
- send overview to member via mail
- Store verification-request mail somewhere to be included in of 'processing' step
processing
- FIRST: generate audit-file. Suggested: PDF with all info, securely 'signed' Audit file should contain as much verification-info as possible (mail-headers, etc); also the original verification-request mail
- THEN:
- process data into tinance
- Process data into mailman
- Process data into doorbot
- Send fob-process request to UR
- Process data into membership-form-database
- Send confirmation mail with neat overview of all relevant data to the member (suggested: pdf with secure signature)
If something fails at some point; mail admin@board.techinc.nl with link to validation-page to re-do the form; providing info about what went wrong
System
Implications/limitations
It would be most preferable to have the data of old members retro-actively added into this system so that there is a concise way to find all data about all members when required.
Cancel membership
Members do leave. Which things need to be considered/done/handled and how do we make sure that all the different things are in sync ? (esp. UR/doorbot)
Schedule action for later activition
Sometimes, cancelations/activations/changes need to be scheduled for a later date; especially when somebody just paid for a month but announces that he/she wants to cancel his/her membership. There is currently no way to 'disable in the future', nor to be reminded of having to perform some action in the future (if not possible to have happen automatically)
Payment reminders
This part of things is critical in having the association stay healthy and to be able to know how many real members we have. A crucial concept here is closer integration of the process with a ticket/handling system that keeps track of what's been sent, what the status is, and that also gets updated when a bank-transfer changes the status if the person doesnt mail to inform us (currently, tickets for people that PAID after reminding them stay OPEN, unless the person triggers a check by having mailed us to inform us to expect a payment..., to give an example..)
Detection of expiring year memberships
It'd be good to anticipate an expiring long-term membership (6months or more ?) at least a little while before it happens and trigger a ticket for a mail to be composed/created
Invoice generation
Using info from the member-form-db could make this a much easier process.