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:
- 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.)
- 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)
- 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).
- 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).
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
-
adam commented
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".
-
Anonymous commented
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. -
Ryan (CTO, Pinellas Computers) commented
71 current votes, over 100 lifetime votes. Can we get something for contact "association" and email/phone "titles" already? Thanks.
-
Ryan (CTO, Pinellas Computers) commented
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...
-
david commented
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
-
Ryan (CTO, Pinellas Computers) commented
@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:
http://feedback.repairshopr.com/forums/165658-general/suggestions/7182891-ticket-comment-area-revamp-seriously-time-for-wysiwyg -
Aaron Caveny commented
-
Ryan (CTO, Pinellas Computers) commented
Hi Troy,
Thanks for the responses. This is an even bigger deal to us now, as we just became contracted by the biggest electronics rental company in our area. They have 7 locations; each with a separate phone number, email and address, with different contacts per location, but all a single point of contact for billing. I'm still not seeing the functionality that I think would help most. There's no clear and easy way to do any of the following as of right now:
Link a phone number to a specific email address or street address.
Flag that a sub-location must be specified when making tickets.
Title the phone numbers better than "Office". They're ALL office numbers, but which office?
Sub-addresses are separate from sub-contacts? Isn't that even LESS organized?I feel like the goal of this topic was to help link and organized contacts/phone/emails. Instead, we're even further from being able to show what contact information goes with which location. There's absolutely no way to show that Location "13852" uses phone number "555-4200" and is managed by the contact "Ronnie Smith" using the email "tampa@rentalking.com".
I feel like nothing really has a "place" because it still needs to be rebuilt from the base up; not just have things patched in. What else can we (the users on the forum) help answer to make this more functional? This is starting to feel like a lost cause for me :(
-
AdminRajesh Agarwal (Admin, RepairShopr) commented
Ryan - some responses:
1. Pick an existing address for appointments, assigned contacts, snail mail, etc.
-- Yes!
2. Show that there are additional addresses up where current phone numbers / addresses are.
-- At some point, there wasn't a good place atm
3. Assign/view a site "name" for additional addresses (Warehouse, Headquarters, Retail, etc)
-- Already there?
4. ^ Same thing for the primary address. Set the location type/name.
- No firm plans with this at the moment, waiting for feedback from many users
-
Ryan (CTO, Pinellas Computers) commented
Just noticed the multiple addresses feature. Is there going to be a way to do any of the following:
1. Pick an existing address for appointments, assigned contacts, snail mail, etc.
2. Show that there are additional addresses up where current phone numbers / addresses are.
3. Assign/view a site "name" for additional addresses (Warehouse, Headquarters, Retail, etc)
4. ^ Same thing for the primary address. Set the location type/name.I'm worried that additional addresses are going to become "sub-addresses", and will turn out just like sub-contacts where everything is patched in, instead of all the data being equally visible and able to select/assign from any module.
-
Spencer Pous commented
+1 for MSP feature
-
Spencer Pous commented
+1 for MSP feature. I have seen this asked for and sent you an email about it a year ago. I have customers with 50+ properties. It would be nice to have a listing of all these properties and the tickets associated with each. So we can lookup the customer by name, one of there properties and see all notes that have gone on at that location.
-
Brandon commented
I'd like to be able to setup multiple restaurant locations under one name so that I can track estimates, invoices, and tickets for each location separately but still show them as one customer. A lot of our clients have more than one location so this would be nice to have.
-
ILAN ELIYAHU commented
Hi @Troy - Any update for February?
Please make us 2016 sweet :) -
AdminRajesh Agarwal (Admin, RepairShopr) commented
@Mick - thanks for adding your votes.. We haven't done any of the specific planning on this. Our perspective is a little different from a user, but mostly aligned. We are only here to build software that you guys find useful, and to help your business. We do that best by fixing the biggest issues, adding the most important new features, etc.
With our view of the almost 1000 open suggestions here on this forum, plus the 100 or so things we want to accomplish on our internal lists of ideas, plus the new things we see in the world that we think we need to add, we have a lot to look at.
With the size of our dev team we can do "a few reasonably sized features" per month if we manage the scope properly - that means a lot of things don't make the cut in any given month.
When we are ready to work on this, like we recently did with purchase orders, I'll outline what we are planning and give opportunity for feedback on the specifics.
-
Michael Leone commented
@Ryan - Agreed mate (with your original, well considered, suggestions), i'll add my votes... Though i'm a little worried they may be wasted... It seems slightly concerning that these (fairly significant) issues are still hanging around after all this time, especially considering the significant feedback and support shown by Repairshopr users?
@Troy - G'day Troy, I understand your comment to Ryan - "We have to balance complexity, dev time, and weigh the pain on all this stuff", this is absolutely fair. But your last comment about semi-implementation could really do with a little more detail? Can you perhaps take a moment to explain (for the benefit of all the RS users that have support this suggestion) your current thinking (in a a bit more detail) on these issues and/or ideas/concerns/constraints/timeframes/etc with Ryans originals points?
Cheers,
Mick - ITSGC
-
AdminRajesh Agarwal (Admin, RepairShopr) commented
@Curtis - oh don't worry, he isn't letting it bother him.. We are still getting the usual amount of feedback.
-
User commented
Lol... Look who just ran head on with Troy's gigantic ego and arrogant posture.
Ryan, you are so valuable to this "community?". Don't let it bother you. -
AdminRajesh Agarwal (Admin, RepairShopr) commented
@ryan - Your feedback is taken as "We would like these things improved" - not "You must build it the way Ryan says because Ryan is a software architect at RepairShopr. Please take that the right way..
We have to balance complexity, dev time, and weight the pain on all this stuff.
-
Ryan (CTO, Pinellas Computers) commented
Hi Troy, I don't understand the logic here and I'm very beside myself on your most recent update.
This was the #1 most popular feedback submission for almost 2 quarters and is still top 10 even after 9 months. I came up with simple and effective solutions for every single problem users are experiencing in the entirety of the CRM functionality of RS. Every single user who voted for this gave me nothing but excellent feedback and praise for the implementation ideas on this.
Now, after 6+ months of saying it's coming, it's not going to be done "fully as described"? Why not? What is the point of voicing feedback to hundreds of users, getting all of their approval, and giving them all an opportunity to add/discuss other ideas, if it's not going to amount to anything more than "maybe we'll be able to help with some additional things mentioned". Seriously?
I would understand more if there were other/conflicting ideas, or something else this would clash with; but there's not! This is a major issue in the underlying infrastructure of RS and everything is effected by it for the worse. How is anything less than a complete overhaul even close to reasonable? PLEASE reconsider your opinion on this and listen to the 100+ users that have voted/re-voted this topic. That's the whole point of having Uservoice, right?
Otherwise, I literally can't even..