CAUSE-BASED MARKETING SYSTEM

A system for cause-based marketing including an interface to communicate with registered merchants, causes and users, a memory to store data associated with activities of the registered merchants, causes and users, and at least one processor coupled to said interface and said memory, said at least one processor configured to: facilitate each registered user to associate with one or more of the registered causes; facilitate each registered user to view offers of donation from registered merchants to the causes with which the user is associated; record transactional data evidencing a registered user's transaction with an offering merchant; facilitate a user to allocate a donation resulting from a transaction with an offering merchant amongst the causes with which the user is associated; compile donation amounts allocated to each registered cause; and facilitate transfer of the compiled donation amounts from the registered merchants to the registered causes.

DETAILED DESCRIPTION OF THE INVENTION

In the drawings, like numerals indicate like elements throughout. Certain terminology is used herein for convenience only and is not to be taken as a limitation on the present invention. The following describes preferred embodiments of the present invention. However, it should be understood, based on this disclosure, that the invention is not limited by the preferred embodiment described herein.

Referring toFIGS. 1 and 2, a cause-based marketing system10in accordance with an embodiment if the invention will be described. The system10is a computing device110(seeFIG. 5) configured to register merchants20and causes30as indicated by arrows22and32. Merchant is intended to have a broad meaning and generally includes any individual or entity providing a good or service, for example, but not limited to, restaurants, hotels, stores, service providers and other businesses, whether in person, on-line, via a mobile application or otherwise. Similarly, cause is intended to have a broad meaning and generally includes entities and other organizations involved in receiving donations or in fund-raising activities, for example, non-profit or other charitable institutions, schools and sports teams and clubs.

In a preferred embodiment, the system10implements an approval process to ensure that a cause30meets minimum registration requirements before registration of the cause30. For example, the system10may be configured to check one or more of the following:501(c)3verification, physical site verification, on-line presence verification, association with an approved cause (e.g. a soccer team associated with an approved soccer club), and third-party verified lists or databases.

Each of the registered merchants20then approves, as indicated at arrow24, causes30from the registered causes to which the merchant20is willing to make donations or other contributions, for example, financial support, wish list items, merchandise, services, marketing or co-marketing fees, etc. As described below, the merchants20preferably can utilize the system10to specify specific offers to specific causes20. Additionally, in one or more embodiments as described below, causes30can utilize the system10to recruit merchants20to register with the system10and to support the cause. The table inFIG. 2illustrates an exemplary group of registered merchants M1-M3 and the causes C1-C12 which each merchant20has approved along with an associated offer rate23. The offer rates23typically represent a percentage of the qualifying sales the merchant20is willing to donate to the cause30. In the exemplary illustration, merchant M1 has approved four causes C1-C4, each with an offer rate23of 10%; merchant M2 has approved two causes C1 and C12, both with an offer rate23of 15%; and merchant M3 has approved three causes C1, C6 and C10, with the offer rates23varying at 10%, 20% and 15% respectively.

The system10is also configured to register users40. Users are members of or otherwise supporters of one of the registered causes30. Upon registration, each user40associates themselves with at least one cause30. The table inFIG. 3illustrates an exemplary group of registered users U1-U7 and the causes C1-C12 that each user40is associated with. Various methods can be utilized for recruiting users40to register with the system10and associate with one or more causes30, as will be described in more detail below. With causes30approved by merchants20and users40associated with causes30, the system10is configured to coordinate opportunities for users40to facilitate donations to their causes30by patronizing the appropriate merchants20. The tables inFIG. 4illustrate each merchant/cause opportunity each of the exemplary users U1-U7 have available to them based on the approvals and associations ofFIGS. 2 and 3. For example, user U1 can support all four of its causes C1-C4 by patronizing merchant M1, further support cause C1 by patronizing merchant M2 and further support cause C2 by patronizing merchant M3.

Once registered, a user40may access the system10, as indicated at42, through a communication device140(seeFIG. 5) to determine which merchants20have approved offers to the user's associated causes30. After the user40has patronized one of the approving merchants20and the qualifying sale has been registered with the system10, the merchant20will make a donation to the selected cause30, as indicated by arrow26. WhileFIG. 1illustrates the donation directly from the merchant20to the cause30, in a preferred embodiment as described hereinafter, the system administration collects the payment from the merchant20and makes payment to the cause30.

Having described the general operation of an embodiment of the system10, the system10will be described in more detail with reference toFIG. 5. The system10may comprise a computing device110which typically includes a processor111and memory112. The memory112may be utilized to store, for example, instructions that cause the processor111to perform various tasks and steps of the system10. The memory112may also be utilized to store, for example, registration information for the merchants20, causes30and users40as well as information relating to the offers and payments. The system10is also illustrated with a mapping data base113which may be utilized to coordinate a user's geo-graphic location with merchant locations, as described in more detail below. The mapping data base113may be stored in the memory112or may be stored in an external memory, as illustrated. Alternatively, the mapping data base113may be stored on another server, for example, the server of a third party mapping provider, which is in communication with the computing device110.

The computing device110may take the form of a server or any computing device having a processor. Thus, the computing device110may also take the form of a laptop, digital assistant, tablet computer, personal computer, or other computing device able to execute computer readable instructions.

The processor111may be referred to as a main processor or central processing unit (CPU). The processor111may include a single or multiple processing cores. Where two or more cores are provided, the cores may be capable of operating in parallel.

The memory112may comprise any number and combination of memory devices including but not limited to cache memory, such as static random access memory (SRAM), dynamic random access memory (DRAM), enhanced DRAM or the like. Any storage repository or non-transitory machine readable storage medium of a type known in the art may also be used. The processor111accesses the memory112through a communications bus or the like (not shown) to access any application or data stored thereon including, but not limited to, any computer readable instructions.

The system10further includes a plurality of portals which facilitate access and operation within the system10. For example, an administration portal114is associated with the computing device110. The administration portal114includes input and output devices which allow a system administrator to perform administrative tasks within the system10. For example, the administrative tasks may include activating/deactivating a merchant, cause or user or preparing reports of activity within the system10. Payment processing and customer relationship management (CRM) portals117and119, the function of each will be described below, are also associated with the computing device110. The payment processing and CRM platform117and119may be separate interfaces or may be part of the administration portal114.

Merchant portals120and cause portals130as well as user communication devices140are also associated with the computing device110. On a basic level, the portals120,130and the communication devices140allow the different entities to register with the system10, control offers and associations, and see reports on their respective activities. As part of the activity reports, the system10may tracks transaction allocations to causes and provide reports to users and/or merchants as a receipt for charitable tax deductions. Additional functionality of each of these portals120,130and the devices140is described below.

These portals120and130and the devices140may utilize separate interfaces, may be accessed through a system website115associated with the computing device110, or a combination thereof. The system website115may include system information, e.g. “About Us”, “Product Information”, “Application Download”, “Testimonials” and “Blogs”, but may also include sign in and registration access for merchants, causes and users. Alternatively or additionally, such sign in and registration access may be provided by a direct access application, for example on a smart phone, which allows the entity to access the system10without going through the website115.

Each user communication device140is preferably in the form of a mobile device, for example, a smart phone, tablet, or other mobile computing device having a geo-location capability, however, alternatively or additionally, the user communication device140may be a stationary device, for example, in the form of a desktop computer or the like. The geo-locator component may include a location application of a type known in the art. For example, if the user accesses the system10from a desktop computer or the like, the computer's IP address may provide geo-location information. Alternatively, in a mobile device the geo-locator may include a global positioning system (GPS) receiver or like. Regardless of its configuration, the geo-locator is capable of accurately identifying the geographic position of the user communication device140. It is also preferred that the communication device140include an image processing device162which allows the user140to record receipts as described below.

The various components of the system10may interface with the computing device110via wired or wireless communication over one or more networks. The networks may comprise any network of a type known in the art including but not limited to a local area network (LAN), a wide area network (WAN), a wireless network or any other network or network of networks including that generally known as the internet.

The following description provides exemplary functionality of the various portals. A system10in accordance with the invention may include none, all or any combination of the described functions.

Referring toFIG. 6, an exemplary user recruitment function will be described. With this function, either merchants20or causes30may recruit users40to use the system10. The recruitment function begins with a merchant20or cause30uploading contacts200to the system10. The contacts can come from various sources, for example, a merchant's mailing list or a cause's member list. Such uploading is done through the respective merchant portal120or cause portal130and can take various forms, for example, manual entry201, uploading of an excel, CSV or other file202, or uploading email contacts203,204. The merchant20or cause30then creates a custom message205advising the newly uploaded contacts of the entity's involvement with the fund-raising activities of the system10and inviting each contact to register with the system10if interested. The message is sent to each of the newly uploaded contacts206by the entity through the system10.

The function then takes different paths depending on whether the message was sent from a merchant20or a cause30. If the message was sent from a cause30, the system10checks at207to see if the contact's email is already registered with the system10. If the contact is already a registered user40, then it is unnecessary to send the invite message and instead the system10sends a message to the user's communication device140at208to notify the user40that the cause30is registered with the system10and requesting that the user40associate with the cause30. The contact is given the option at209to accept association with the cause30. If the user40accepts at210, the cause30is now recognized as an associated cause in the user's communication device140. If the user40declines at211, the process ends without an association. In either event, the system records are updated so that the cause30may check the user's decision. Returning to207, if the email of the contact receiving the message is not registered in the system10, then the cause's custom message is sent at212to the contact with information on the cause and on the system10and requesting the contact to register and support the cause30. The contact is given the option at213to accept association with the cause30. If the contact accepts at214, the contact may download a system application to the user's communication device and register with the system10. Upon registration, the cause30will be recognized as an associated cause in the user's communication device140. If the contact declines at215, the process ends without the contact registering. In either event, the system records are updated so that the cause30may check the contact's decision.

In recruiting user's or encouraging user use of the system10, and thereby increase donations to the cause, causes30may provide incentives to the users40. For example, a cause that is a sports league may provide an incentive wherein all donations as a result of user40transactions offset the user's league fees. In this regard and for other reasons, usage of cause members may be associated with a family account. For example, members of a family may register all or some of their family members under the cause member account so that transactions can be compiled to offset activity fees associated to individual family members.

If the message was sent from a merchant20, the system10checks at216to see if the contact's email is already registered with the system10. If the contact is already a registered user40, then it is unnecessary to send the invite message and instead the system10sends a message to the user's communication device140at217to notify the user40that the merchant20is registered with the system10. If the email of the contact is not registered with the system10, the merchant's message is sent at218to the contact with information about the system10and requesting that the contact register with the system10to support the cause30. The contact is given the option at219to accept the invitation to register with the system10. If the contact accepts at220, the contact may download a system application to the user's communication device and register with the system10. If the contact declines at221, the process ends without the contact registering. In either event, the system records are updated so that the merchant20may check the contact's decision.

Referring toFIGS. 7-11, additional preferred functionality of the merchant portal120will be described. In the embodiment illustrated inFIG. 7, the merchant portal120accesses the system10through a web application on they system website115, however, additional or alternative access means may be utilized. Within the merchant portal120, a merchant administrator may attend to administrative functions regarding the merchant's use of the system10. As illustrated, there is functionality to allow the merchant administrator to control the merchant's settings, to review billing information and review activity reports.

The merchant portal120also allows the merchant administrator to manage causes30approved by the merchant20. Referring toFIG. 8, an exemplary cause approval page230will be described. In the illustrated embodiment, the cause approval page230includes a section232listing the currently approved causes30. Basic information about each cause30is included and the administrator has the option to remove any of the approved causes30.

A cause category section234is also provided which allows the administrator to select an entire category236of causes30or a sub-category236a,236bfor approval. In the illustrated example, the category236is local schools, e.g. schools within a certain geo-graphic area, and the sub-categories are private schools236awithin that area or public schools236bwithin that area. The administrator may select any number of categories to provide offers to all registered causes30falling within the selected category/sub-category.

If the administrator would like to select specific causes30, a cause search area237is provided. The cause search area237includes a results list238which may be populated by default with recommended causes30. The recommended causes230may be selected based on various criteria, for example, cause demographics, cause member neighborhood location distribution, cause mission categorization, cause tax filing status, historical cause member shopping locations, cause member purchasing data, and financial transaction method data. For example, the system10may identify the most productive causes, i.e. causes who members are users40and frequently respond to offers. A search bar239is also provided which allows the administrator to search for specific causes30based on various criteria, e.g. name, location, category, etc.

Additionally, causes may utilize the system10to invite a merchant20to add their cause30to the merchant approval list. Causes30may base such merchant invitations on cause member requests or the system10may provide the causes30with recommendations of which merchants20would make good donations. For example, the system10may make recommendations based on merchants that have marketing geo-territories that match the home and/or work locations of users40supporting the cause30. The cause30can utilize the system invitation to taut the large number of cause members living near the merchant, may stop in the merchant or the large number of cause members may make recommendations as they frequent the merchant.

Referring toFIGS. 9-11, an exemplary offer creation page240will be described. The offer creation page240has a selection area242which allows the administrator to select which causes30the created offers will apply to, for example, all causes, causes within a select category, or an individual cause. The page240also includes a default offer area244whereat the administrator may set a default offer which applies at all times a special offer is not available. In the illustrated embodiment, the default offer is easily controlled by a slider bar245. In addition to the default offer, the page240includes a section246to create custom offers. In the illustrated embodiment, the custom offer section246has an area corresponding to each day of the week, allowing the administrator to create a special or custom offer for a given time period on a given day. As illustrated, different offers may be provided at different times of the day, for example, to provide incentives during slow times of the day, e.g. lunch, or tied to specific events, e.g. a football game on a Monday night. In addition to or alternatively, the page240may include a calendar section which allows custom offers for specific dates to be created.FIGS. 10 and 11illustrate exemplary sub-pages241aand241bwhich may be utilized to define a special offer. The first sub-page241aallows the administrator to define the time period of the offer, in the illustrated embodiment, using a dual-button slider bar247. Once the time is set, the system10moves to the next sub-page241bwhereat the administrator sets the offer for the selected period, in the illustrated embodiment using a slider bar249. The system10may create default or suggested offer templates for merchants based on various factors, e.g. type of merchant, the merchant's time, date, historical sales activity levels, labor considerations, market considerations, and other offers in the system.

Referring toFIGS. 12-19, exemplary functionality of the user communication device140will be described. In the illustrations, the user communication device140is a smart phone, however, other mobile or stationary computing processing devices may be utilized. In the illustrated embodiment, the user40has downloaded the system application142onto their communication device140which allows them to easily access the user portal of the system10. Upon opening the application142, the user40is brought to a home page141where they can select between a donation or merchant selection page151, a recording page161and a settings page181. The settings page181allows the user40to manage various settings. The illustrated settings are generally self-explanatory and can be configured to any level of complexity. In a preferred embodiment, the manage locations sub-page183allows the user40to define multiple “favorite” locations, e.g. home, work, school, which allows the system10to easily search in the designated location even if the user40is not currently at that location.

When the user40would like to find merchants that have made offers for the user's associated causes, the user40navigates to the merchant/donation screen141as shown inFIG. 13. The screen141displays a number of merchant offers143a-143dcorresponding to offers to at least one of the user's associated causes30. While four offers143are shown, more offers may be available based on configuration of the screen and also by scrolling the screen. The offers143which are displayed are based on various criteria, including for example, location of user and merchants, ratings of merchants, value of offer, cause/merchant matches, merchant special offers, historical usage of a merchant offer, member upgrade potential, member loyalty levels, time of the transaction. If the user40does not see an offer143that interests them or if they are interested in patronizing a specific merchant30, the user40can utilize the search bar146to search for additional merchants30, for example, by name, different location, category, etc.

The location criteria used by the system10is preferably a practical geo-location criteria as described with respect toFIG. 14. InFIG. 14, a first user40ais located in a rural area250with several merchants30a-30espread over a wide area and a second user40bis located in a more densely populated area260, e.g. a city, with many merchants30f-30m, etc. within a much smaller geo-graphic area. The system10utilizes the mapping data base113and is preferably configured to determine the type of area the user40is in and then define the target merchant area251,252based on the characteristics of the area. In the illustrated embodiment, the system10is configured to presume that user40ais willing to travel to merchants30utilizing a car or other means of transportation while user40bwould prefer not to have to use a car, but instead would prefer to walk or have only a short cab ride. As such, the system10utilizes a merchant target area251for user40athat is larger than the merchant target area261for user40b. The user40may override the presumptions, for example, if user40bis willing to take the subway or happens to be visiting the city in a car and therefore can travel further.

Additionally, the system10is preferably configured to account for “barriers” that override a simple radius approach to defining the target area. In the illustrated embodiment, user40ais located closer to merchant30fthan to any of merchants30a-30e, however, a river252separates the user40afrom the merchant30fand the bridge254does not provide easy access to cross the river252. Accordingly, the system10is configured to limit the range of the merchant target area251to the user's side of the river252. The system10can be configured to identify various “barriers” which are considered in defining the target area, for example, toll roads, highways driving, predicted congested driving. Again, the user40can select to override one or more of these considerations.

Referring again toFIGS. 13 and 15, the user40can select one of the suggested offers or a searched for offer and the user40is taken to a merchant offer screen151. From the offer screen151, the user40is provided with additional information regarding the merchant20and the offers being offered by the merchant20. The merchant20information may include, for example, address, phone, website, and rating information, any of which may be hyperlinked to allow the user to utilize, e.g. the phone number, or access more detailed information, e.g. website or ratings, by clicking on the link. Clicking on the directions button153will open a default mapping program which will provide directions from the user's current location to the merchant location. The offer page151preferably includes the current offer154and upcoming offers156. The user40can save any of the offers154,156to their calendar by clicking on the calendar button155.

Once a user40selects an offer, they simply patronize the merchant20during the designated period and then register the transaction with the system10. Various methods may be utilized to register the transaction. In one embodiment illustrated in FIGS.12and16-19, the user40registers the transaction by uploading a picture of the transaction receipt164to the system10. In the application142, the user40clicks the camera icon162which takes them to the camera recording screen161, which initially is a picture capture screen161a. The user40aligns the receipt164within the capture screen161athen captures an image of the receipt164as shown inFIG. 16. The system10may include functionality which allows the user40to confirm clarity of the image and/or to capture multiple images for larger receipts. Once the user40has captured an appropriate image, the system moves to a merchant selection screen161bas shown inFIG. 17. The system10is preferably configured to list geographically close merchants, but also includes a search bar to allow searching for a specific merchant or within a specific location.

Once the merchant20corresponding to the receipt164has been selected, the system10proceeds to a cause selection screen161cas shown inFIG. 18. The cause selection screen161clists each of the user's associated causes30. Causes30′ not supported by the merchant20may be grayed out, not shown, or otherwise not available for selection. The user40then selects the causes30to which the user wants the merchant's donation to go to. The user40may select a single cause or multiple causes30for a single transaction. If multiple causes30are selected, the donation from the transaction will be split among the causes30. Preferably, for simplicity, the split will be even amongst the causes, however, it is contemplated that the user40could select the distribution amongst the causes30. Once the causes30are selected, registration of the transaction is complete and the user40receives a confirmation page as shown inFIG. 19. The user40may be given the opportunity to rate the merchant, share their experience via social media, upload photos of their experience to the system and record other receipts. Merchants20may provide additional donations in response to photographs, video, recordings, reviews, ratings and other feedback from users40.

In an alternative embodiment, users40do not register their own transactions, but instead submit copies of their receipts to a selected cause30. The cause30would then submit batches of receipts164to the system10wherein the receipts would be registered and verified.

In yet another alternative embodiment, the merchant20may have hardware and software at the merchant point of sale (POS) which is able to communicate with the user's communication device140. For example, near field communication or other form of communication may be utilized. The merchant POS hardware will be configured to capture transactional data of user's transactions and then submit the transactional data to the system10. The transactional data would then be used by the system10for transaction verification.

While a few transaction data capture methods have been described, it is recognized that other methods may be utilized and that multiple methods may be utilized at one time.

Regardless of the method of capture, the system10verifies the data in the payment processing portal117before making any payments. An illustrative payment process270is shown inFIG. 20. At step271, the system10receives the captured transactional data. At step272, the system10verifies the transactions to confirm that each transaction met the merchant's criteria, e.g. the transaction occurred during the offer period and the user40was an active member at the time of the transaction. For each verified transaction, the system10at273then calculates the donation amount for the transaction, i.e. multiplying the offer rate times the transaction amount and then determining if it is split amongst multiple causes30. The calculated donation amount is then posted to the appropriate merchant account as a negative and to the appropriate cause account(s) as a positive as shown at274. Periodically, for example once per month, the system10pays all donations in each cause's account to the cause30, at275, and invoices all donations in each merchant's account to the merchant20, at276.

Referring toFIG. 21, an alternative payment process280is illustrated and may be used in conjunction with or instead of payment process270. In the payment process280, a user40pre-registers a payment account, e.g. a debit card, with the system10, as indicated at281. In step282, the user40conducts a transaction at a merchant20in accordance with a merchant order, however, the user40does not pay the merchant directly for the transaction. Transaction data is transmitted to and received by the system10as indicated at283. Preferably, such transmission is performed by the merchant20and is not dependent on submission by the user40. Upon receipt of the transaction data, the system10is configured at step284to debit the user's account for the amount of the transaction, regardless of whether the transaction actually met the merchant's offer criteria. At step285, the system10verifies the transaction to confirm that the transaction met the merchant's criteria, e.g. the transaction occurred during the offer period and the user40was an active member at the time of the transaction. For each verified transaction, the system10at286then calculates the donation amount for the transaction, i.e. multiplying the offer rate times the transaction amount and then determining if it is split amongst multiple causes30. At287, the system10credits the merchant's account for the amount of the transaction less the verified donation amount and a handling fee. The calculated donation amount is also posted to the appropriate cause account(s) as a positive as shown at288. Periodically, for example once per month, the system10pays all donations in each cause's account to the cause30, at289, and pays the balance of each merchant's account to the merchant20, at290.

The CRM platform119may be configured in various ways to enhance the marketing of merchants20and causes30and also may facilitate cross-marketing. The system10may be configured to implement one or more of the following functions to enhance merchant marketing. In one embodiment, the CRM platform119is configured to perform an ongoing analysis of a merchant's POS system data to optimize marketing and operations based upon merchant type, merchant revenue, time, date, historical sales activity levels, labor considerations, market considerations, staffing, current sales activity level, scheduled marketing events. The system10may provide alerts to key merchant stakeholders based upon customer preferences, offer favorability and the like to maximize the merchant benefit from the system10.

In another aspect, the CRM platform119may be configured to predict user40activity based on merchant offer characteristics, offer timings, cause communications, calendar additions, characteristics of the merchant20, characteristics of the user40, characteristics of the cause30, historical performance of system activity, and commitment effect of the user40. By tracking historical user utilization, both causewide and per individual user, allows the system10to better predict offer utilization as well as help target offers

The CRM platform119may also facilitate a dynamic bid platform that optimizes the offers merchants20market to an individual cause30or groups of causes30. The dynamic bid platform considers market conditions such as the number and amount of deals in the market and factors such as time, date, and location. The system10may set max bids, report potential opportunities to merchants, and offer recommendations to merchants based upon market conditions.

The CRM platform119may also allow the merchant20to enhance utilization by providing incentives to causes30or users40. For example, the merchant20indicates that it will increase the offer rate from 10% to 15% when cause specific users exceed $500 of transactions in a given time period. The system10may be used to communicate to the cause's users the need for additional activity to reach a milestone. Similarly, the merchant can agree to increase the offer rate from 10% to 15% when a specific user40exceeds $500 of transactions in a given time period. Again, the system10may be used to communicate to the user the need for additional activity to reach a milestone.

In another aspect, the CRM platform119may be used by the merchant20to create a “tournament” to increase user participation. The tournament design allows for a merchant to promote cause member usage among multiple causes by awarding an enhanced donation commitment to the top revenue generating causes. For example, the merchant sponsors a tournament where ten soccer team causes compete with each other for revenue generation at their local affiliated merchant. Sales are tracked for the period of the tournament and the enhances the top three teams with an additional donation.

In another aspect, the CRM platform119can be configured to calculate the cause mindedness of a particular merchant20. An algorithm may be applied to consider such factors as the number of causes supported, the level of donations to causes, the number of volunteer hours by merchant employees to causes, timeliness of donation payments, co-promotion frequency, event marketing frequency, event marketing frequency, frequency of wish list donations and user feedback. The cause mindedness ranking of each merchant20may be used within the system10as a factor in determining search list result order. The rankings may also be made available to users40.

The CRM platform119, or other aspects of the system10, may be utilized by causes30to enhance their marketing. As one example, the system10can be used to recommend causes30to a user40based upon geo-location, demographic information, access device information, similarity to other causes on the user's cause list, and characteristics of the population within their proximity.

Causes30can also utilize the system10to inform users40of specific events at one or merchants20that benefit the cause. The platform may be configured to remind users40of the cause fundraising events and allows users to add the events to their calendar. The cause30can track user40sign-up, i.e. adding it the event to their calendar, and predict the level of participation. If participation appears low, more marketing of the event can take place.

In this regard, the platform preferably allows the cause30to create automated messaging between the cause administrator and the cause constituency based upon offers in the current system, group events, and external factors including time, date, and location. To further enhance this feature, the system10may provide for an mail signature tool that appends communications from cause administrators to cause members with functionality that communicates fundraising programs, fundraising events, wishlist items, etc. Fundraising messages, updates and offers are channeled based upon the cause/user pairings. For example, and email from a soccer coach has a signature tool that auto updates information about the team or clubs fundraising efforts.

As mentioned above, the cause30may want to communicate a wishlist of desired items. By providing a list of tangible items, it may provide motivation for donations from cause members or to motivate transaction with merchants that commit to making donations to causes. The system10may also be configured to facilitate direct user donation for items on the list or simply general donations.

The CRM platform119may also facilitate co-marketing between merchants20and causes30. For example, cause marketing can be refined to co-promotions to cause members located in merchant targeted neighborhoods. For example, co-promotion is only promoted to members living or working in the merchant's targeted neighborhoods rather than all of a surrounding region. Similarly, causes can promote their cause to merchant customers not currently registered in the system10or to merchant customers who are registered in the system10but have not selected their cause to support.

The CRM platform119may also facilitate marketing by causes30directed to neighborhoods or target areas that coincide with merchant targeted neighborhoods or areas. For example, a cause can send a direct mail, email or message campaign to only those associated users40that live or work in an area targeted by merchant deals within that area. This saves the cause30time and expense of sending the message to users who are less likely to respond to the deal and avoids the users receiving messages about deals that are not local to them.

In another aspect, the platform can be configured to send merchant special product offerings to members of specific causes with the endorsement of the cause. For example, a restaurant promotes its gluten free menu for celiacs and it promotes donation commitment using the system10to members of Celiac Disease Foundation with the endorsement of the foundation.

Various functionality of the system10is described herein. A system10in accordance with the present invention may use only portions of the functionality while still performing within the scope of the invention.