I was reading this thread by @CWAL about how they approach gift card organization and use.
https://saverocity.com/forum/threads/churning-organization-lets-get-physical-with-pictures.520938/#post-650442
The reason for the system outlined there is that the electronic system became too convoluted when purchases increased.
Agree with it or not is a different (yet relevant) discussion, but the important thing I wanted to look at was finding what might be the 'best' way to handle something like this. And from there, assigning a 'bounty' to delivering a solution. The solution could then be stored here as a Resource for the benefit of the community.
Calling Project Managers
What components are important when designing a solution? Can we create a systematic approach to this. To me, I think that the project needs to be taken to a certain level before being sent out to bounty for delivery.
Possible Process
Looking at the giftcard process outlined in the link above, I'd want to start with a discussion about whether it is necessary to actually keep these things. What purpose does it serve, why are records important, are they for internal process or might they be called upon by an external investigation if things look weird, etc.
Once we 'understand' what is going on, and create a list of reasons that must be addressed, that is when we could create a bounty. For example, is there a way that you could snap a photo of the giftcard that would create an automated listing within a spreadsheet, that included the date of the photo, the amount of the transaction, the location of the giftcard purchase, and other things?
To test if that would work, we would have to do something like 'lose' a giftcard. What happens if I have a photo of GC1 and call in to say I lost it, or I need a replacement.. will the number suffice, does it require the number on the back too? Does GC2 (different vendor) work the same way?
It would be pretty cool if we could crowd source a solution for things that CYA better, and then use the skills of people here to create something that helps us all spend less time faffing about and more efficient.
Amount of Bounty
I think the bounty should fit the need. If it is an IFTTT solution (the GC Project solution might be an IFTTT solution) then the bounty should be less than if it is a custom built solution. Depending on how much each bounty is, I might be able to cover the amount myself, but if higher, perhaps we create a 'pool' of funds to kickstarter it. Money to be collect pre project and paid out when approved by the donees.
https://saverocity.com/forum/threads/churning-organization-lets-get-physical-with-pictures.520938/#post-650442
The reason for the system outlined there is that the electronic system became too convoluted when purchases increased.
Agree with it or not is a different (yet relevant) discussion, but the important thing I wanted to look at was finding what might be the 'best' way to handle something like this. And from there, assigning a 'bounty' to delivering a solution. The solution could then be stored here as a Resource for the benefit of the community.
Calling Project Managers
What components are important when designing a solution? Can we create a systematic approach to this. To me, I think that the project needs to be taken to a certain level before being sent out to bounty for delivery.
Possible Process
- Problem/Need explained via post. Polling attached to post to see if there is demand for this to be a bounty.
- Project discussed within post.
- Best solution selected, author of best solution gets option to write up the solution as a resource. If they don't want to/have time another person can. Walkthroughs should have images and charts as necessary to make it useful.
- If solution requires coding or automation tools to execute a bounty will be assigned to the development of it, or the well outlined process of how to automate within IFTTT or Zapier etc.
- A thread becomes a 'Bounty' when agreed upon and assigned such a title, we then see if we can make it happen.
- A bounty becomes payable when the product is released here as a resource and people agree it does the job within the scope of the defined project.
Looking at the giftcard process outlined in the link above, I'd want to start with a discussion about whether it is necessary to actually keep these things. What purpose does it serve, why are records important, are they for internal process or might they be called upon by an external investigation if things look weird, etc.
Once we 'understand' what is going on, and create a list of reasons that must be addressed, that is when we could create a bounty. For example, is there a way that you could snap a photo of the giftcard that would create an automated listing within a spreadsheet, that included the date of the photo, the amount of the transaction, the location of the giftcard purchase, and other things?
To test if that would work, we would have to do something like 'lose' a giftcard. What happens if I have a photo of GC1 and call in to say I lost it, or I need a replacement.. will the number suffice, does it require the number on the back too? Does GC2 (different vendor) work the same way?
It would be pretty cool if we could crowd source a solution for things that CYA better, and then use the skills of people here to create something that helps us all spend less time faffing about and more efficient.
Amount of Bounty
I think the bounty should fit the need. If it is an IFTTT solution (the GC Project solution might be an IFTTT solution) then the bounty should be less than if it is a custom built solution. Depending on how much each bounty is, I might be able to cover the amount myself, but if higher, perhaps we create a 'pool' of funds to kickstarter it. Money to be collect pre project and paid out when approved by the donees.
- What amount makes sense? I want it to be something that is a 'thank you' for the person, but perhaps not up to their full hourly rate.
- Also, we could consider farming out complex coding if people here are too busy, and hire Freelancer or Odesk people to execute a solution for us.