I’m a PHP developer installing SuiteCRM to help a friend with her translation/interpretation business. Being a CRM newb, I’m having a little trouble determining wihich modules correspond with her particular basic business needs. Could you please confirm/address what I put in the square brackets below?
Basically, a client [Account Module] calls her requesting a translator (aka sub contractor, not an employee) [ ? Module] for a particular job [ ? Module]. Once the job is completed, the translator sends her an invoice [? Module]. She then sends her own invoice [Invoice module] to the client.
Where modules don’t already exist, is the duplicating of a particular one recommended over another?
Will she be able to “assign” particular sub contractors to a job?
I’m thinking this might be spilling over a bit from sales into service but is this still pretty doable for SuiteCRM?
I think she will want to use the Quotes / Invoices / Products modules. Maybe also Opportunities if she wants to manage possible business deals, not yet confirmed. The less modules she can use to get her simple work flow going, the better.
I belive the Invoices module will be used only for her own accounting (Invoices she creates for her customers); other invoices received from translators to be payed by her can probably be simply “Notes” with file attachments.
… especially the one about Accounts and Contacts since it explains the kind of approach I think is best, and the one about Notes and Documents (to understand that difference).
About the “assignments”… Will her sub-contrated translators be “users” in SuiteCRM, with their own log in? Or are they simply people she deals with via email or something?
I read over the concepts page. Nice to see the real world connection to the modules. I should have made that more clear…“Basically, a client [Contacts Module] representing a business entity [Account Module] calls her requesting a translator”
Are you recommending the Products module to separate the interpreting service from the translation service? That sounds logical.
Correct. The sub-contractors will NOT need to log in. Just emails back and forth. So, that’s where a lot of my confusion is. I agree the less Modules the better. So, somehow I just need a “list” of sub-contractors with associated emails that I can somehow “assign” to a “job.”
I feel like the whole flow I described above should be called a “Project” or something with some custom statuses, just to clearly indicate a “request,” request “granted” or “denied”, job completed, and Project ended (i.e. all parties have been paid). But I don’t think that’s what the Project module is for.
I read an Opportunity as a potential Account that you’re hoping to land a FIRST deal with? Is that correct? I’m not sure how that fits in other than that.
When you decide to drop a module, not work with it, often you can replace it by a simpler mechanism like a custom “status” field in some other record.
What you’re saying about Projects might be a case for this. If you decide you don’t need the complexity of Projects/Tasks/Resources you can be better off with a simple field on each job with a drop-down “Request/Granted/Denied/Closed” or whatever. You do this from Admin /Dropdown editor and from Admin / Studio.
An opportunity doesn’t have to be just for new customers. You can have as many Opportunities as you want attached to the customer’s records. Think of them as “business deals”, each deal gets its own opportunity record. I believe they might fit your system well to represent what you’re calling “a job”.
Do you have a demo system set up so you can play with these things in practice? That’s usually the best way to decide.
