The 100% PERFECT SOLUTION for having MULTIPLE Phone Numbers and Email Addresses instead of using SUB CONTACTS !!!
Introduction: I have been spending the last MONTH brainstorming ideas for how to best optimize/clean-up the issues with sub-contacts not being “real” contacts (as far as the RS system is concerned) (see list of details below). I am very happy to report that I have a 2-stage overhaul solution that will ABSOLUTELY FIX EVERY LIMITATION/PROBLEM that exists with contacts, sub-contacts, and “business” contacts. I’m (almost) not joking when I say I should be paid for figuring this out. I call it: Linked-Contacts
References: These are the problems that exist that drive me crazy, and I know everyone else hates too:
- Sub-contacts of a business almost always need to reference data from the “main” contact (office phone, address, etc) which requires entering the same data multiple times into any sub-contacts. This requires excessive re-entry of information that is overridden when a new sub-contact is assigned to a ticket. (http://i.imgur.com/md7lfsx.jpg)
- Sub-contacts do not pull a CID lookup, even when set as the assigned contact for a ticket. (very annoying)
- Sub-contacts do not support customized phone numbers other than Phone and Mobile. (very weak. What about office numbers with extensions?!)
- Sub-contacts of a business often need to exist twice – as an individual and a business sub-contact, even though the info is the same.
- Sub-contacts have no way to reference their relation (assistant, mother, accountant, co-owner, etc) to the “main” contact (without changing their name, which is retarded)
- Sub-contacts do not support “sub-businesses” – like companies with multiple offices (eg. separate medical offices with shared staff)
- Sub-contacts for individuals (like family members in the same home) seems logical, but is super messy and is impossible to keep organized.
Deduction: I consider sub-contacts to be “piggyback” contacts and are a poor solution to connecting/grouping “real” contacts together. I know this is a serious overhaul of a module, but it CAN be done – and the sooner it’s done, the easier it will be. Sub-contacts as a feature needs to be ELIMINATED, even if that means we have to manually re-enter all data that is currently stored as sub-contacts. I would normally say “depreciated”, but it’s so horrible that I really think it needs to be taken out back and shot.
Metaphor: Sub-Contacts are Windows Vista, and “Linked-Contacts” are Windows 7. (Okay, enough mean words…)
Application: Instead of seeing “Sub-Contacts” in another contact’s page (which are required to be created/edited from within that “container contact”) – you would simply be able to “Link” contacts that already exist together (http://i.imgur.com/EbSSEpG.jpg). You could very quickly link or unlink related contacts to either a business “container” account, or even to other individual customer accounts (useful for families).
STAGE 1 – “LINKED” Contacts:
1. Every sub-contact that currently exists needs to be converted to a “real” contact – meaning they have their own customer page, their own phone number, their own email address, etc. (In reality, sub-contacts all should have this, but may not because they live in an imaginary world where they are not bound by the same security checks as real contacts.)
2. Businesses should not be attached to a “main contact”. As it stands currently, the business name is more of a “nickname” for the customer than what it should be – a CONTAINER! A business is nothing without a contact, and most contacts are not the business. (The only appropriate example is a sole proprietorship who never has plans to have another employee – good for them.) Otherwise, businesses are a “folder” for the employees – which are the “files”. (these metaphors are brilliant, I know)
3. A business and a contact are not the same thing. A business needs to be created differently that a contact. (While I love the convenience of being able to create a contact and have them associated with a business instantly, you should not be able to edit both the contact and the business as one).
4. Businesses should have their own “customer page” but should not be able to have any data (tickets, estimates, etc) assigned to them directly. The account page for the business would show all “linked-contacts”, along with ALL data (communication logs, tickets, invoices, estimates, etc) for EVERY one of the linked contacts, all in one central place (like a container).
5. Creating a ticket for a business would force you to choose one of the linked-contacts as the assigned contact. You would not be able to create a ticket just for “The Business”. This would ensure that someone is always responsible/assigned to the businesses ticket.
6. The business would be allowed to have address(es), and phone number(s) – which would automatically associate to any linked-contact that is assigned to a ticket for the business.
7. Individual contacts could be used for individuals as a personal account – showing only the contact’s private data (tickets, estimates, communication, etc). However, if a ticket is made for the business (with the linked-contact set as the assigned contact) that data would be linked only to the business container account, and would not show in the individual’s private customer account.
8. Any ticket/data that is associated with a business account would reference the business’s information, in addition to the linked contact – specifically the CID lookup feature. Meaning, the system would be aware that a ticket is “for” a business “on behalf” of a linked-contact.
9. Business “container” accounts would be able to link to other business container accounts – useful for businesses with multiple locations, but different owners (like franchises). You would be able to see that a call may come in from “Taco Bell Largo” but it’s actually going to be billable to “Taco Bell St.Pete”, which is part of the same franchise, but has a different owner and set of assigned contacts – which would help eliminate accidental association with incorrect contacts.
10. Individual accounts could benefit by linking multiple family members together. Even if they don’t live together, it’s nice to associate people who are part of the same family – especially when they sometimes pay for other family member’s invoices.
11. Although families would not be a part of a “container” account (like a business), you would have the ability to view ALL data related to all of the individual linked-contacts – in case one of them is referencing a ticket for a family member. This would be very helpful for cross-referencing work across different accounts.
***** SEE COMMENT SECTION FOR CONTINUATION OF “STAGE 2” (ran over text limit) ******
We recently added multiple addresses, more to come.
I started using RS two weeks ago. I have many businesses that I take care of who's sub-contacts are also customers. One of the very first questions I asked support was how to deal with sub-contacts, and if I could like them to existing contacts somehow. As I'm importing over 2700 customers from Google Contacts & QuickBooks the usage of sub-contacts has made this process a total mess. Additionally with the inability to use multiple email addresses on a contact and for other contacts I'm forced to skip importing some of my customers.
I came to RS from using a free and feature-lacking ticket solution called osTicket and it's contact handling was far superior to RS's methods in many ways.
Your solution is a great idea and I really hope RS is working on implementing your ideas.
Jim Walker commented
I agree with you 100%! I also want to thank you for coming up with something the RS people will actually listen to.
Does your solution account for where the personal email and business email is the same? Current RS does not and it's annoying. When I asked about it I was told "To bad, that's how it works." I have several business owners that are also personal clients, a couple of them only use one email but don't pay personal expenses from business accounts.
Randy Biehl commented
A sync with o365 or google contacts would help a ton! Even if we just had name, email, phone number, addresses. This would SERIOUSLY help my field techs and make their lives a ton easier.
Warren Bull commented
I want to bump this because its actually a briliant idea and something I struggle with often.
@Farook: Yep, still a limitation...
Farook Ayub commented
@ Ryan - You have mentioned you have added multiple addresses, however I still cannot use one email address for 2 contacts. Does this have to be enabled somehow?
James Moore commented
The OP's post is spot on, that sounds great.
AdminTroy (Founder, RepairShopr) commented
Thanks for the detail Scott, many people say generically "the flow needs to be improved" but those comments are not actionable. We can probably get a few if not all of the things you mentioned handled in the very near future.
Keep it coming!
Scott Peeler commented
We have been using RepairShopr since October 2015. Since then I have seen a lot of good progress. I give the developers high praise for what it does do well, because it does a lot REALLY well. There are many things that desperately need attention, and Customer Info/Contacts is a big one! The other day I wanted to email a customer an estimate. After I created the estimate, I assigned a contact from the list. When trying to email the estimate I got a message that said: "This customer is set to get NO email". This made no sense, because it showed the “Assigned Contact” Name and Email address on the estimate. Then I realized that it was referring to the email on the main “Customer Info” section, which was blank. For large business customers we generally leave the Name and Email fields blank, because there are multiple people that need communication. Apparently the "Contacts" aren't really usable anywhere in the communication, but are just merely for reference only. Then I discovered that this is true across the board with Invoices, Tickets, etc. The only way to send an email to a specific person was to manually copy and paste their info from Contacts and put it in the Customer Info fields. I could use Outlook to send them an email with an attachment, but that takes a lot more effort than just pressing a button. The whole idea behind RepairShopr is that it’s supposed to streamline workflow and make things easier. It’s hard to get excited about new Feature Fridays, when a basic feature like Customer Contact Info still doesn’t work right.
It's been a year since the last enhancement to this topic. Can we please have some of the "more to come" soon?
Ryan Armbruster commented
Just checking in to see if any changes have been made with contacts/customers management. We like a lot of features within RepairShopr, but the current flow for contacts has been a deal breaker for us. We will continue to monitor this thread as the proposed idea would appear to correct much of our concerns... I suppose we will check back again later.
Any update on this?
@Troy: No update on this in 9+ months. Can you give us an idea of what's next?
I also agree that the Business name should not just be an alias of a contact. A business is an entity who's employees may change. And maybe I'll do work for the same employee at a different business if they leave.
Any roadmap plans for any of these ideas.
There should be a "barely started and not really getting anywhere" tag for ideas like this instead of just "started".
I agree that having the Business name as an alias of the contact is not effective.
Don't think the idea of not having the ticket data associated with the business is good, employees leave and the ticket history needs to stay attached to the business. A business is a defacto entity, person, therefore, a contact in it's own right. As I understood the above, You can have a John Doe that works for Acme, and brings in items for repair for the business and for themselves. You don't want to intermix the data and billing between the two. This can be more complex if John Doe works part time at another business and brings in repair items for that company as well, and further if they are the main contact for their Church, Elks club etc etc. Things to consider as you look at this suggestion. You should also consider adding multiple email addresses per contact, like phone numbers, many people have many addresses for differing reasons. Emailing can email to all or selected.
71 current votes, over 100 lifetime votes. Can we get something for contact "association" and email/phone "titles" already? Thanks.
I wouldn't hold your breath @david. This has been top 10 voted for a year and a half and still the only thing added has been multiple addresses. Other topics seem to keep getting prioritized over this, even though the CRM a backbone feature of the RS system. Chuck, Matt and I have all but given up on this...
Multiple Name/Address fields:
We need to be able to clearly define at least four categories of contact/name/address data:
• “Collect from”: For jobs pre-booked online we can arrange UPS collection (with optional carriage insurance if required at 1% of“Declared value”)
• “Invoice to”: For invoicing at the end of each month in one batch.
• “Owner”: To discuss the actual fault
• “Return to”: This is often different – i.e. return to warrantor (etc) if replacement has been sent out. It's can be disastrous and very awkward to rectify if equipment is inadvertently dispatched to the wrong place by, say, a new member of staff while I'm not looking!
And It is essential to be readily able to define each and any of these at any point in the workflow.
We handle warranty servicing of several brands on behalf of various manufacturers where equipment is often collected from the SHOP for repair and then possibly returned directly to the OWNER (or the shop - or back to the distributor if the item has been swapped out - or scapped for parts - i.e. not returned).
INVOICE details often need clarification so need to be defined for each job even though they may be “warranty” status. Since some shops offer 5 year warranty, if the failure occurs within year 1 the manufacturer or distributor pays but in year 5 the shop is responsible.
In order for a warranty repair to proceed we require a prop-of-purchase (purchase invoice etc). If this proves to be unavailable the job must be invoiced to the owner and status may be changed to non-warranty (though this is less important providing we know who is paying).
(On my current system we have each of these overlayed, with tabs to select whichever is viewed. Buttons below each tab on each page enables copying of one to another which is handy since these fields are frequently all the same.)
In addition to the four areas defined we also have “Dealer” and “ClientOfClient”. I must confess these have proved rather superfluous, however, I appreciate there may be different workflow scenarios so perhaps the headings of these fields I have listed should perhaps be definable by the user:
Name/address1, Name/address2, Name/address3, Name/address4, Name/address etc
@Aaron: Right, but this one was made almost a year prior to that one. I'd say that post you're mentioning is more related to this on from back in May 2015:
Aaron Caveny commented