Jump to content

Feedback for Clients Contacts Feature


Matt

Recommended Posts

  • WHMCS CEO

Ok, here's the latest feature I'm looking for feedback on before implementation. And it's the feature for multiple contacts under a client.

 

The way I see it working is there will be two types of contacts. Client accounts as they currently are will have the primary admin info for that account. There will then be billing contacts under that client for billing. It will be possible to have unlimited billing contacts per client, and one will be set as the default billing contact for automated invoice charges to be charged through. It would be expected that most customers would only have 1.

 

There will also be an technical contact type. This contact type will be used for adding additional emails to a users account. These can be used to open tickets associated with the account and send copies of emails to more than one address. The emails that get sent will be definable - such as product emails, invoice emails or support emails only.

 

I can only see one other obvious feature related to this and that would be multiple logins, but then we start getting into the issue of limiting what each user can access such as just invoices, just tickets, etc... and it makes things quite a bit more complicated + lots of template changes. Is that really needed?

 

Feedback and opinions are appreciated as always.

 

Matt

Link to comment
Share on other sites

  • Replies 52
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Posted Images

  • WHMCS CEO
The above would be no use to me at all. :)

This feature will be directed mostly towards those using merchant gateways where a client may want to use a card to pay that is registered to a different person so needs seperate details for it.

 

And to confirm, this is in the planning stage and will not be in 3.2. The feature list for 3.2 has already been released in the announcements section.

 

Matt

Link to comment
Share on other sites

I think this is an excellent start and am really looking forward to this!!!

 

As far as the multi-login, I do think it makes a lot of sense, but as you stated, that should involve (ACLs) the possibility of the account admin assigning permissions...

 

To keep the login simple, I would have each contact row contain one field called auth_level, and this would be one of three things: 1. full access, 2. billing + tickets, 3. tech + tickets only.

 

In trying to keep it simple:

Billing + tickets ... all invoices, emails, product and service list (no detail) + tickets.

Tech + tickets ... view service details, emails +tickets

 

On the template side, I would just assign a auth_level variable to the session or assign it internally to a smarty variable, which can be checked against in the template, (not in the core code, to allow more flexibility).

 

When you load any template, do the auth_level check at the top and redirect to, or load a generic templated page stating the user does not have sufficient privileges to view the page they were trying to access.

 

If the ACL is not implemented, it would be nice to have a field in the database for the auth_level anyway, so WHMCS admins can implement it as they see fit.... in other words, allowing them to do something along the lines of the above example.

 

Will these contacts also lend themselves to one of my previous requests to also reuse/assign the contacts to the domain registration?

Link to comment
Share on other sites

Sounds good - all we need is multiple contact details and the ability to set who should receive billing notices.

 

For example with our larger customers, the person who signs up is in the IT dept but the person who pays the bills is in the finance dept.

 

To automatically CC the billing contact on any invoices (so the customer can see the invoice was sent to their billing dept), as opposed to just send two e-mails, would be neat, too.

 

Not too bothered about multiple logins though :)

Link to comment
Share on other sites

We find no need for this feature either. When and if it is implemented it would be nice to not complicate the use of the system for users that have no need for this.

For instance, not adding extra settings that would need to be configured if you choose to continue without the extra client fields.

Link to comment
Share on other sites

PPH, exactly! I think that is probably the way it will and should work, so if no extra contacts are defined, it will use the one used at creation for all. .. and when they pay via credit card, they should be able to choose, "Billing Address is the same as the Account Address".

Link to comment
Share on other sites

PPH, exactly! I think that is probably the way it will and should work, so if no extra contacts are defined, it will use the one used at creation for all. .. and when they pay via credit card, they should be able to choose, "Billing Address is the same as the Account Address".

 

Thumbs up to all of that. thumbsup%5B1%5D.gif

Link to comment
Share on other sites

I have a few clients that have a webmaster working for them. The webmasters are granted access to the client area.

 

The only problem is that the webmaster cannot receive any invoice-generated emails, read the cpanel welcome email, or any other emails because the emails are sent to the client.

 

This is actually not a problem because the webmaster can actually view all emails that were sent to the client's email address via a page in the client area of whmcs! So I think how it is now is fine.

Link to comment
Share on other sites

Many SMEs (small medium enterprises) and even some divisions of large companies do host with dedicated and even shared hosting providers.

 

Another thing ... some people are also using WHMCS for things other than hosting, where there is also a need for that. Consider providers offering Internet services, ASP services and VoIP, etc.

 

So the assumption that it is not needed is very subjective to your own needs. I think, at large, it is needed.

 

In fact, you will also note that more and more businesses support multiple login, precisely for the same purposes as what was suggested here. Some of these even include your own industry... take a look at Network Solutions, OpenSRS and DirectNIC, etc, or hosts such as INetU, The Planet, AccessITX, NYII, etc... They all offer some level of administrative and billing logins.

 

Personally, if you can't tell, I am a staunch advocate of this feature ;)

Link to comment
Share on other sites

  • 2 weeks later...

Client accounts as they currently are will have the primary admin info for that account.

 

There will then be billing contacts under that client for billing.

 

There will also be an technical contact type.

 

Feedback and opinions are appreciated as always.

 

Having multiple contacts associated with an account are a must :D

 

If every account has a minimum of 1 contact, then for each contact the account owner can set what that contact can accomplish.

 

Primary contact can set the permissions for other contacts

Each other contact can then be flagged to be used for

billing

tickets

domain registrants

etc

Link to comment
Share on other sites

Definitely top priority for me at the moment too. Very much looking forward to this feature, even in it's most simple of implementations.

 

My comments from another thread on this topic:

Specifically I am looking for a way to have a main client email address that they use to log in and manage their accounts, all support tickets, etc, and then an optional alternate "accounts only" email address that they can use to receive notifications of new invoices.

 

The client should also be able to log in with that alternate "accounts only" email address (or a login token?) and see a list of current and past invoices, and be able to change any billing / credit card details as well as (most importantly) pay any outstanding invoices.

 

It would be handy - but not essential at this stage IMHO - for the client to be able to submit and manage accounts related support tickets with this alternate login. I say not essential as the accounts person could already submit accounts enquiry tickets via email piping, and when it comes down to it an accounts clerk is going to be less likely to be wanting to log in to a ticketing system to communicate with a supplier that they have to pay!

Link to comment
Share on other sites

The above would be no use to me at all. :)

This feature will be directed mostly towards those using merchant gateways where a client may want to use a card to pay that is registered to a different person so needs seperate details for it.

 

And to confirm, this is in the planning stage and will not be in 3.2. The feature list for 3.2 has already been released in the announcements section.

 

Matt

 

Personally I think this might open the door for higher fraud...

Link to comment
Share on other sites

I am interested in being able to have the invoices sent to multiple email addresses within a company or organization. Like CC or BCC fields for additional email address. All the other options being consdiered may open the door to a higher liability for fraud... It all depends on how Matt includes the options for it. I am sure that Matt wil carefully consider the oprions before he releases it to us so that we will have the proections that we need. For me, if we simply had the CC and BCC option right now I would be happy!

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Recently Browsing   0 members

    • No registered users viewing this page.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use & Guidelines and understand your posts will initially be pre-moderated