Re: For those interested in the CRM/Entity management

[Ed W <..hidden..>]

Joshua D. Drake wrote:
> Here is the current model:
> http://ledger-smb.svn.sourceforge.net/viewvc/ledger-smb/trunk/sql/Pg-database.sql?view=markup&pathrev=1244
>
>   

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?)
- Duplicate company names are quite common, ditto for people names
- 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..)
- Multiple email addresses and tel numbers are possible.  However, also 
useful to mark one or more as "primary"
- 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?
- "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. 
- Arab names can follow a different convention to western names.
- Might want to loose middlenames as a field?  In fact for most purposes 
even breaking out forename and family name is overkill?  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?
- 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


Actually the whole area of "how do we build an external system onto 
this" is worth thinking over.  It's not sensible to try and make LSMB be 
all things to all people, but equally if I am going to (say) build a 
website shop that hooks into the data here then I probably need some 
strong ways to tie into the data easily.

One thought might be to have a structured format for custom extra 
fields.  The idea being to allow people to extend the customer data 
fields, but in return they have to use certain naming conventions for 
fields and tables (Goldmine used to require you to have fields like 
CUSTOM_XXX, etc).  These extra fields could then be dynamically added to 
various views in the LSMB system and allow limited ability to extend the 
system without major programming.  I'm thinking here of the case that I 
want to add say a "Customer Number", or "internal employee id", or 
"employee tax code" or similar.

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. 

The above would allow for example a very simple system to be built which 
would mean that whenever my (asterisk) phone rings that the system will 
open up a summary view for that customer with their name, details, notes 
of previous calls, and a summary of invoices to that customer.  If it's 
an unknown number then I can easily tap in their contact details while 
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

Looks promising

Ed W