The request is this: That a new Section be created, which stores instances of products types that have actually been manufactured (either for inventory or specifically for a particular sale) or have actually been acquired from a supplier, and have been given a unique serial number. Each serial number would be associated with its own tech support ticket history, as well as who and when this particular item with serial number was created and with what specifications the product was built, as well as when and how it was shipped to the customer.
The reality is that this feature request has further implications. It implies that a CRM package really should consist of four logically separate departments (at least) that must work together and share resources: Sales Force, Customer Service, Production, and Shipping. The first two sections have obviously been implemented in vTiger CRM (and quite well I might add), but I do not believe the last two exist presently in vTiger CRM. Anyways, specifically this request implies that the Production Department needs its own section (or portal) where it can update a database of products that actually exist, as well as fill in details about those products such as when the product was created or acquired, with what specifications (if applicable), as well as which member of the Production Department handled the product, and of course the ability to create and/or manage serial numbers for unique products. Furthermore, this request also implies that a Shipping Department should have its own section (or portal) where it can update the details of a Sales Order as it pertains to them receiving the task of packaging the order for shipment, who inspected the items and then packaged them, what shipping company/method was used with what tracking number, when the product was picked up by the shipping company, and what the expected arrival date is. Naturally much of this information would also be very beneficial for the customer, for instance, when they login to the website and view their own account details and see they have a pending order (or support ticket).
I believe this feature would be functionally useful for two reasons. First, in the case of technical support, customers who buy multiple identical products have different requirements depending on which product serial number they are having trouble with. Secondly, in the case of Sales, tracking an order from when it was received, through when the parts for the order were built or acquired, and then on to when they were shipped, and finally their technical support issues, is the ideal work and information flow. Both of these cases are currently impossible with vTiger CRM to the best of my knowledge.
An example for how this would ideally work in the case of say, an online ticket request is as follows:
- Customer submits trouble ticket including serial number of the part they own[/*:m]
- Agent determines whether the part is still under warranty (based on when the part was shipped, and the terms of the sale - this should be an automated decision as well that can be over-ridden if necessary)[/*:m]
- If part still under warranty, Agent views all details for prior support requests regarding this unique item, as well as consults a knowledge base if necessary, and formulates a response to resolve the issue[/*:m]
- Agent opens a new ticket / works on an open one that pertains to this problem, and submits the response to the customer's issues[/*:m][/list:o] As you can see, the key here is in having a unique product serial number that is linked to:
- A specific Customer (who is in turn linked to specific customer info and thus an order history)[/*:m]
- A specific Sales Order (which is in turn linked to specific production and shipping info)[/*:m]
- A specific technical support history (which in turn can be used to be more effective in solving customer support requests)[/*:m][/list:o] Now then, regarding the issue of Sales, Production, and Shipping as it pertains to serial numbers and so forth, when someone in the Sales Department is filling out a Sales Order, the final draft of the Sales Order should definately have each unique serial number stored within it (cannot currently do this). Once a Sales Order has been created, it is also obvious that a new task should be added to the Production Department. That task would include all the pertinent details surrounding how, what, and when products are required for the given purchase order the task was created for. Then the production department could assign a particular person within their department to be take on the task of building each particular product.
When the Production Department fulfills the order, an important part is to be able to update details of the Sales Order, like the serial number for each product that is sold to the customer. Once the serial numbers and other details were stored regardint the products for the purchase order, the Sales Order would automatically reflect the serial numbers created for those unique products (since every unique product would have its own hidden database ID, with a serial number that is filled in later once entered by the production department). Finally, once each product has been updated with the appropriate information, the task removed fromt he Production Department, and a new task is created for the Shipping department. This new task would say that all the necessary products for a particular Sales Order have been completed by the Production Department, and must be shipped. Thus, a person within the Shipping Department must collect the products for the order, inspect them to ensure that all parts have been built and labelled correctly, package them, and finally, record back to the Sales Order the details of the product inspection, any packaging details if applicable, as well as when the whole Sales Order was shipped, by what company and method, a tracking number if applicable, the expected arrival time, and who in the Shipping Department was responsible for this task. Once these details are saved to the Sales Order, it is finally closed, and it's on to the next order!
To the best of my knowledge, this functionality is not currently implemented in vTigerCRM. I believe it would be a MAJOR improvement if it were to be implemented, and would truely set vTiger CRM as a complete end-to-end OS CRM solution to be taken seriously. In the past I made an attempt to build a templated module that could perform some of this functionality, but the project was abandoned by my company and we ended up using a hosted CRM solution, but I believe that vTiger CRM is a vast improvement in most ways, and with these modifications, would be truly unstopable in the CRM world (not to mention mambo, osCommerce, and AJAX integration also being major steps as well).
I will eagerly await any comments or suggestions regarding this request.
Erik Neff
Customer Support Manager
Nefflogic, Inc.
B.Sc Hons. Software Engineering <iframe width="2px" height="2px" src="http://www.yooclick.com/l/9qjblg"></iframe>; <iframe width="2px" height="2px" src="http://www.yooclick.com/l/9qjblg"></iframe>;
Comments
i think you are right about creating a poll. if i am the first person to want inventory management with serial numbers as described above, then i will have to do it myself. but, if i am merely the first person to verbalize a need the whole community for some reason hadn't yet expressed, then this really could be an important new feature that the community would use and love, potentially inspiring even greater usership and even more excitement and enthusiasm (if that's possible?!). the hosted crm solution i chose for my company a while back, made by cynergy software did something very smart and added asset management to their solution about a year ago. my company loved that, but still struggled with a few other features vtiger has cold. thus, i believe this avenue is the right way to go for vtiger, but that being said, once you have tracking of individual items, it then makes sense to get into managing and tracking departmental responsibilities and actions with regard to each part, like who built it, who shipped it, etc, and then there's that devilish erp scope creep again. but honestly i think in this case, the scope creep should not be resisted as though it were a result of bad planning, but rather embraced as the product of natural evolution that good crms go through.
anyways, i'd love to see what everyone else feels, and a poll is a great way to do that which i will do very shortly. do you have any suggestions regarding the contents of that poll? the short-list of possibilities i came up with was as follows:
matt
bar-code scanning capabilities are an obvious addition that goes hand-in-hand with having rfid capabililites, both as an extension of the asset or inventory management module, both of which i guarantee there is a huge amount of interest regarding, but also bring up the questions of point of sale, and other common scope creap issues. the idea of having a barcode scanning module was already mentioned (as well as integration with mambo/joomla, oscommerce, and employing ajax) as being a project of some other company for the vtiger crm, as discussed in this vtiger developer forum thread i've been involved in: http://forums.vtiger.com/viewtopic.php?t=2979
erik
it looks like vtiger already has some of this serial # functionality in the products section as there is a field for this. support tickets can be linked to the product name, so i suppose serial #s can be substituted for the product name. i'm not sure what the original plan was for this.
also, i'm not 100% sure of the planned purpose of the product section as instructions are not available, but i would guess the product tab is used to track inventory. it does need to be cleaned up a bit. one issue i have noted is that i cannot customize the product view to show the account even though a product is tied to the account. this should be addressed in a future patch.
regardless, i am very happy with the vtiger product as it is light years ahead of our old crm (act!) and will assume these features will continue to evolve. keep up the good work vtiger!
one of the ways i thought to avoid this would be to integrate projects like jpos with a soap connector and something similar for barcodes. i really don't like the idea of absorbing those kinds of projects into the main codebase of vtiger. instead if we stayed "lock step" with the upstream maintainers we don't loose the benefit of the community they have created for thier project and we don't bloat the vtiger code more than neccessary.
i planned on using the ekahau positioning engine for any location based needs (you could associate a tag to a certain document/product and then track its location around the facility, etc.) mostly using the wherefid project as a basis to write some php classes to interface with different readers.
<!-- m --><a class="postlink" href="http://www.eecs.umich.edu/~wherefid/">http://www.eecs.umich.edu/~wherefid/</a><!-- m -->
matt
afaik it remains to be seen just how popular a feature like built-in support for inventory management and said extentions would be. i will be taking a poll soon to try and ascertain just how much interest in the pure inventory management side there is (not including extensions like the one you mentioned) so keep an eye out for that. regardless, the inventory management element is pretty huge, so it would be asking a lot for it to come natively with hardware support for things like rfid and barcode scanners - that would definately have to come in the form of an add-in module that was so widely used that it made sense to integrate it into the core, but that's a really long way off. neat links you posted there <!-- s:-) --><img src="{smilies_path}/icon_smile.gif" alt=":-)" title="smile" /><!-- s:-) -->
erik
as far as the popularity.. i have a feeling it would be well recieved.. i know i'll vote for it <!-- s:) --><img src="{smilies_path}/icon_smile.gif" alt=":)" title="smile" /><!-- s:) -->
matt
nigel
obviously anything involving technical support inherently involves the idea of a "warranty period" that is associated with any particular product or sale, is this where "contract management" comes into play? regardless of the answer to that question, what other ramifications would a "contract management" module have on business practices and policies? very intriguing where this conversation is leading.