ask yourself (and/or clients):
1. do you ever have the need for multiple attachments?
2. do you ever have the need for styled (HMTL) email (bold, colors, etc.)?
if you answer 'yes' to either of these question, then they need a plug-in (or other external means) of using FM data in email (send).
3. do you ever have the need to have multiple people follow the correspondence?
if you answered 'yes', then they need a plug-in (or other external means) of getting email (w/ or wo/ attachments) into FM (receive).
I have found that clients will pay for whatever fits their needs. Sometimes it's a compromise. Sometimes it's a plug-in, sometimes it's other methods.
I've not implemented an email plugin but – like you – I'm a commercial solutions developer.
From my experience I gather that customers are looking for an immediate communication solution, email is "too slow". I hear this and feel older . I think customers are looking more for a chat solution like SeedCode's FM Chat, which by the way works without plugins.
I'd use an email plugin to send massive emails for marketing, get emails from a certain account to extract data and use it in my database but never to make a full email client. Years ago, Giuseppe Pupita created a full email client. May be you can contact him for more reference.
For example, you could use the plugin to collect all emails regarding an invoice number and show those emails in the invoice record. That sounds cool.
Just my 2¢ of Mexican pesos.
thanks for your input.
Questions 1 to 3 will probably all be "yes" for most of our customers. But my may concerns still are:
- will they be willing to change their current system?
- will they pay for a new/different system that might have weak points? Or can we compete with Outlook?
- how much effort is it for us to implement it?
- how about support ?
Keep in mind - we are selling standard solutions with street prices from 99.- to max 599.- Euros.
maybe I am getting old (49) too. Never chatted with a customer so far, only emailed or skyped.
I can imagine chatting inside a company though and our Webdirect solution does offer this plus a blog.
I fear, that people would expect a full email client - they get it with other CRM systems too.
Of course it would be much easier just to get some mails for parsing them, for what purpose ever.
Will contact Giuseppe and ask for his experiences tomorrow.
For me, the question is: Where to start - and where to stop...
We don't include emailing in a standard solution - but we have quite a few installations with dacon's mailit.
Customers would like to integrate mails in their workflow. Means: Send mail from FileMaker, ie concerning a project - and receive the answers, adding the incoming answers (mail) to the project, automatically..
WHat, when somebody replies to a mail concerning project 1 - and adds 'btw. I got some news for project 2'... Then, we got twice a problem with updates (FM, provider, other..). Therefore, emailing that requires more than the 'defaults' is custom, here
We have used SMTPit as an outgoing email plugin very successfully for years. There are a couple of issue using it with FMP14 but I'm sure they will be corrected soon. This plugin allows HTML rich text, multiple attachments, etc. Support has been responsive and relatively quick when needed. As an in house developer, I really cannot speak to cost or how much a client would be willing to pay.
Many years ago we tried using the Pupita email system and found that the volume of emails (especially spam) for 15 users was a problem. Also, any single email, usually with an attachment, that caused the system to crash would bring down our entire solution. These crashes would happen several times a week or even daily. Of course having 15 employees twiddling their thumbs while I struggled to get the system back up and remove the offending record was unworkable and we abandoned that functionality.
My understanding is that the way filemaker deals with container fields, and thus attachment, has been greatly improved and the issues we were having back then may not be a problem any longer.
Integration was easy, SMTPit comes with sample scripts and files which I quickly adapted to our system. Maintaining plug ins on every client computer is a bit of a hassle but no worse than maintaining any other email application which we have to do for each client computer anyway.
I hope this helps,
We've integrated 360Works' Email plugin into our base solution, and it has the ability to be a full-blown email client. In our own, internal solution, we all use it as our main email client and have shut down our others. Aside from multiple attachments and html emails, the ability to receive emails is a huge plus for us. One big advantage is that if the same email is sent to three of us, the receive script recognizes this and updates the assignments on one record, rather than creating new records. This means when I get to that email I can see if one of my colleagues has already handled it. Another is that I can link that email to various project(s), contact(s) etc., and/or assign it to an additional user, so that it's visible everywhere it's likely to be relevant.
However, we made a system preference for whether to use the solution as an email client or not. Some clients are locked into another email client, or just don't want all their emails going through FM for one reason or another. If they set that preference to "no", then we just send email via client (which for most programs ends up with a copy of the email in the preferred app's "sent" folder) and allow users to copy/paste incoming email activities where applicable.
It was a lot of work to set this up, and in most cases the technology wasn't the challenging part. Deciding what should happen in a shared email client took a lot of discussion and consideration. IMO, though, it was well worth it. We love it internally, and when our clients choose to use it, it tends to solve a lot of challenges preemptively.
thank you for your input.
Everything that increases support and failures and doesn´t add much to our profit of course is a problem with cost sensitive solutions as we offer them.
So the question might be, how many licenses more would we sell with email integration compared to now with no integration.
Aside from multiple attachments and html emails, the ability to receive emails is a huge plus for us.
That´s point. I guess for all customers this would be a big advantage in CRM, ERP and other solutions.
However, we made a system preference for whether to use the solution as an email client or not. Some clients are locked into another email client, or just don't want all their emails going through FM for one reason or another."
But that is our fear. Investment in cost and work and in the end people don´t pay for it or don´t use it.
What if you add basic functionality that won't affect your costs too much and release a 1.0 version?
Then listen to your customers, if email is good then invest on it, if not, you didn't loose that much.
that´s a possible approach. We even thought of integrating some functionality relying on a plugin, without supplying the plugin itself. So at least we wouldn´t have the license cost and the customer could decide.
And sure, integrating only some very basic functionality would be easy.
Only my German thinking is somehow against that. Like Mercedes Benz: "The best or nothing"
"The best or nothing"
They can do that because they have customers willing to pay for a Mercedes.
On the other hand, you can create an excellent basic feature. Basic doesn't mean bad nor unpolished .
if it should be 'Mercedes-like', then sell it withouth email (email goes to the 'supplementary' - list)
customers here will pay for the email-functionality - if they need it. The standard solution hast the standard email-features included. For multiple attachements, HTML/RichText (etc) we install a plugin, full integrated (when needed)
"Mercedes" might be said too much. With our more lowcost like products we can´t offer the Mercedes. On the other hand even in a "Ford" or whatever might be appropriate in this comparison, you would have some standard feature set people expect to be there.