(Excuse the cross-post. It looks like the discussion is moving to the "CRM" group - but that migration might take some time.)
Just wanted to toss out that ThinkShout's been working on two modules that might be interesting to folks looking at native CRM in Drupal 7.
The first is called Entity Registrations. It's largely a rewrite of the Sign-up module using the entity system. In short, "registration entities" can be add to any content type. As such, registrations are fieldable. You can manage registration limits on nodes of the applicable content type(s), send emails to site visitors who have created registrations, etc. It leverages the Entity API - which gives you Views and Rules integration "for free." It also allows for creating multiple sign-ups with a single registration.
The Entity Relationships module ships with a submodule (still in active development) for managing registrants. Registrants are also entities (and thus fieldable as well). The idea here is that you could capture data about each individual registrant for registrations that reserve more than one place on an event. Since both the registration and the registrant entities are fieldable, you could, for example, create a registration form that allows a teacher to sign-up her class for an event, and then enter the lunch preferences of each student attending...
The second CRM-related module that we've been working on is the MailChimp module. I know that tying CRM functionality to a single 3rd-party service is less than ideal. But with the MailChimp STS, MailChimp Lists, and now the MailChimp Campaign submodules that ship with this project, we're very close to providing a bulk mail tool within Drupal.
Comments
Look interesting sean. I've
Look interesting sean. I've looked into mailchimp for a client. I still feel uncomfortable with tying it to a 3rd party but I feel like it might be a better place to go because I'm also nervous about self-hosted mail systems in the hands of lots of end-users.
We'll take a look at Entity Registrations. But on first look I feel like entity registrations is something the flags module is supposed to eventually be able to handle. Is that right? Is there something this module does intrinsically different to flags?
Why not CiviCRM
CiviCRM already has Event Registrations and Mail modules - why not leverage the capability that's available there?
Impari Systems, Inc.
http://www.imparisystems.com
Made a wiki post about this:
Made a wiki post about this: http://groups.drupal.org/node/179484
Hi seanberto!
Is this part of RedHen? Most of our notes and updates on that go something like, "we don't really know what's going on but here's a link". Would you consider joining the broader dialog so that we can all work together towards a longer-term solution?
Recommendations:
I strongly encourage the first 3, but that last one is totally up to you. I think it will help your project if you keep it as an active member of the Drupal CRM ecosystem. None of us can answer every use case, and none of us can sustain a full blown solution. Managing an entire user community and feature development cycle through Drupal 7, Drupal 8, and beyond is a bigger job than any single organization should take on. The best thing we can do is seek areas of collaboration and share the load.
That said, I can't speak for why you've chosen to set up a separate group, and thus I can't assert that deprecating it will accomplish what you want.
Bunch of replies ;)
@Allie, Thanks for the suggestion that we get on those calls. We are very excited to engage with the larger group. Re: RedHen, in short, when we started the project and initially committed code, there was little coding progress on other CRM fronts as far as we could see. This isn't a criticism - and we could have been wrong. We just wanted to dive in. I'm happy to chat more about the future of RedHen, but that's probably best discussed offlist to keep threads focused. There is, however, both documentation and code describing our work and vision - as well as user stories for development. It's on the D.O. project page: http://drupal.org/project/redhen. Regardless of the details - it's awesome to see all this energy and we're stoked to work with the group!
@matthewboh, there's a lot of energy right now in providing CRM functionality natively within Drupal. Check out the CRM and CRM API Drupal Groups for more on the motivations.
@matthewboh and @yautja_cetanu, yes, tying a mass mailing tool to a single, paid API does have it's drawbacks. However, the problem with trying to work with an open source mass email tool is that it requires the site/server admin to be an expert in email server configuration, delivery, etc. We've considered trying to create a wrapper API that would allow you to potentially plug into various 3rd-party email delivery tools - such as MailChimp, Amazon, etc. However, working on the Mapstraction module, which attempts the same thing for mapping APIs, we learned that adding an abstraction layer often results in the lose of a lot of cool features that are singularly available in different APIs. MailChimp's API is incredibly robust. We get a really high delivery rate and analytics at a very low transactional price. It's pretty sweet.
@yautja_cetanu, re: entity registrations vs. flags. Could you point me in the direction of how flags could be leveraged to manage multiple sign-ups for an event created through a single registration? If it's there, that's awesome! We just didn't see it. We're in discussion with the Sign-up module: http://drupal.org/node/1285384 about how our work might or might not fit in with the future of that module.
As with all of these tools, we're very excited to collaborate with others. At the same time, we often find that we need to scratch our own itch for specific clients. In the case of the registrations module, there's currently no better solution that serves the need of a client who needs a site live within the next month. So, we put this module together. Rather than sitting on it, we released it - knowing that doing so means that we have a responsibility to now maintain it for the rest of the community.
Again, it's so great to see so many good folks working together on these tools!
-Sean
re: entitity registrations:
re: entitity registrations: Thanks for the response. I think we'll look into it and get back to you. Like pretty much everyone we tend to want to use as generic as possible modules, but we tend to overestimate what they can do and have to retreat! So I think we'll compare your module to what we could do with flags and write it up. I'm sure it won't go anywhere but might help us understand how far flags go when we start wanting to use it for loads of other stuff in CRM
"As with all of these tools, we're very excited to collaborate with others. At the same time, we often find that we need to scratch our own itch for specific clients. "
Regarding that statement: CitizenKane comes along to them and he is working to a strict timeframe and client in a similar manner. The meetups are just on skype, we are trying to keep them to only half an hour and they are just a brief "status of whats going on" where even if you say "nothing to report" its quite useful because the hope is we might naturally find areas to collaborate or find we're working on the same problem in slightly different ways etc. I'm saying this because after reading the issue http://drupal.org/node/1156950 there was talk with chriscohen about issues with duplicating efforts. We've actually decided to encourage duplication now :)
If you'd like, pop into #drupal-crm and I can get you up to speed on the development that has happened by the different parties either on irc or skype. I'm in the UK so around 9-5 GMT and fridays are our specific CRM day.
Also please don't worry about keeping threads focused at this stage. At the moment everything is a bit of a mess anyway and I'm kind of making it a bit of my role to read everything and consolidate stuff.
RE: mass mailing...
I do a lot of my hosting on Amazon's EC2 servers and it seems like emails from their IPs have a higher chance of getting flagged as spam, probably due in part to how easy it was for spammers to setup servers and use Amazon's bandwidth.
I find it to be a little bit better in terms of my emails getting through to the end user and the ease of use when I outsource that functionality to someone like MailChim, Constant Contact, or BlueHornet.
Making sure emails get to the
Making sure emails get to the end user is vital in customer relationship management. With all the parameters involved in CRM, one must stay on top of the different aspects in order to reap the full benefits. For some, CRM is a chain link where engaging in social media, sales, analytics, or even reaching out to an email marketing agency may be part of a scaled strategy. For others, CRM may not be so detailed, where one aspect or variation is enough for that particular enterprise.
That being said, the variety in which CRM can be approached creates a need for as many modules as possible across different platforms and frameworks. I look exploring more as Drupal 8 continues to evolve.
More on mass mailing
There's a better forum for this, but I'll weigh in anyway. The MLM Module was specifically designed to address this challenge, without locking anyone into any specific service(s). This module was originally written for Drupal 4.6. It was ported/rewritten several times through Drupal 6, and needs yet another pass during its upgrade to Drupal 7.
As problematic as that sounds, I stand behind the necessity for this module for the following reasons:
As a hosting provider, we give our users access to huge, fast, bulk mail tools for free - which saves $100/month or more over using MailChimp. However, I think it should be OK for our users to use Constant Contact or MailChimp if those solutions make them happier, and I think that making that decision should happen independently from making a bunch of theming, configuration, and user-facing subscription form changes.
What I hope to see is work that supports a central UI for disparate uses. For example, a module like MailChimp could still use much of the hosted UI for message composition and delivery, but outsource its subscriptions to a central UI. If a Mailman module does similar then you get the best of all worlds - with only one place to update your settings.
MLM is actually a live, working module - and has been for many years. But like a lot of my stuff it's a little bit misunderstood and needs a D7 refresh. I haven't dragged this into the broader CRM discussion, but I hope that coordinating on a consistent mail system with pluggable backends will be part of the long term strategy. And I super-duper hope that some of the efforts that people are spending on duplicating efforts can go into conversing on the possibilities. We all know it will be better in 1-2 years if we do it that way, even if it feels like a drag on the 1-2 month timeframe :)
Great ideas, Allie
Thanks! We're excited to engage with the group.