[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: For those interested in the CRM/Entity management
- Subject: Re: For those interested in the CRM/Entity management
- From: "Joshua D. Drake" <..hidden..>
- Date: Wed, 06 Jun 2007 21:19:26 -0700
Ed W wrote:
Joshua D. Drake wrote:
Here is the current model:
Just shooting from the hip here:
- Would be useful to be able to "expire" a contact completely so that
they are no longer active (or do we expire them per class?)
You would expire them per class. It may be, dead lead, inactive,
expired, whatever you actually choose. Although, it may be an
interesting idea in the future to actually track class changes and when
- Duplicate company names are quite common, ditto for people names
Yep you are right, mistake on my part. Fixed.
- Normalisation is often good, but it's also painful sometimes. I need
to cut and paste addresses in and out of the system and right now it
needs loads of work to paste into each field. Not everyone will need
addresses and names so normalised (I have no better suggestion as to
what to do though..)
What are you cutting and pasting out of and why aren't you using a form
or other tool such as OOBase or Access to do it?
- Multiple email addresses and tel numbers are possible. However, also
useful to mark one or more as "primary"
Disagree, by the very term, you can only have a single primary number.
Keep in mind that you could always add more.
- Custom field information, especially to allow integration with other
systems. Eg my customers get an account code from us on another system,
we also track the SIM codes for various purchases and it's useful to
have that info easy to find. Could add a generic "foreign key" field
which can be updated with a key from another system to assist in tying
two systems together?
We will have custom field capability in 1.3 AFAIK.
- "Company" is often useful to abstract (but makes the model very
complicated). eg for suppliers I may have contact with multiple people
from that business.
Sure, and there are facilities for that with the company_to_entity
lookup table or person_to_entity, allowing for a many relationship
between all contacts.
- Arab names can follow a different convention to western names.
True, but that is a functionality of the template.
- Might want to loose middlenames as a field? In fact for most purposes
even breaking out forename and family name is overkill?
Depends on how deep you want to go with the relationship.
In practice you
sometimes get the "Henderson Chapman Curruthers Smythe"s of this world
and without prompting you don't know if the first name is a double
barrel or not, same with the last one, etc. Also I get a lot of "John
and Jane Smiths" where you want to be able to search on both husband and
wife names because you don't know who will call.
- How will we handle "James Smith" of "Acme industries" where we want to
easily search on either name?
You would search the entity. Every contact has to have an Entity.
- Plenty of generic "Notes" fields solve a lot of problems...
Especially if they are all easily searchable. Lots of times its ok just
to stuff things in there rather than having a more structured system to
capture the data
This part is still being worked on. I committed "part" of it tonight but
it is not ready for comment.
A simple prospect tracker and todo list would also be *hugely* useful.
A simple model might be an additional table "customer-contact" which has
fields like date of contact, notes of meeting, follow up date, notes of
further work required, value of work.
You would be able to do that now with note classes. Although we don't
yet have facilities for things like date of contact or follow up date.
> we talk and if they want to buy something then I have everything ready
to go to knock out a sales order.
Anyway, just thinking outloud
Joshua D. Drake
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
Ledger-smb-devel mailing list
=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/