The facts about ADP and Zenefits: Response to the claims made by Zenefits [pdf](adp.com)
adp.com
The facts about ADP and Zenefits: Response to the claims made by Zenefits [pdf]
http://www.adp.com/zenefits/downloads/The-Facts-About-ADP-and-Zenefits.pdf
Disclosure: I work at a competitor to both - posting this because I find it generally interesting from a data security and integrations perspective.
80 comments
http://blog.zenefits.com/adp-2/
ADP rolls out Zenefits competitor hours after claiming they were not in a lawsuit.
The truth will always reveal itself! /zenefits EE
The truth will always reveal itself! /zenefits EE
Other side of the story: https://news.ycombinator.com/item?id=9688058
This PDF has a better interface and user experience than anything else i've ever used with ADP on it.
seriously, you're not kidding. If ADP wants to convince me they've got programmers I can trust, a good place to start would be by hiring a UI designer above the age of 20 who can answer the question "what is a best practice".
Regardless of the qualifications of the average ADP programmer, they spend what we in the business would refer to as "a cubic fuck-ton" on application security. I have no idea if they get it perfectly right, but when ADP makes an argument premised on security, I take it seriously.
We must have seen different ADPs. The one I saw was still 1990s security all over the place. It didn't look like they had even heard of security.
They're one of those companies that tell their enterprise customers that they are not allowed to update to a new point release of Java.
They're one of those companies that tell their enterprise customers that they are not allowed to update to a new point release of Java.
Then yes, we have seen different ADPs.
If Zenefits prioritized payroll domain expertise and enterprise-level programming over UI design, they wouldn't have to feed off ADP.
[deleted]
This is not the first time a YC company has "hacked" their way into success-- for example AirBnBs spamming of Craigslist users and violating Craigslists ToS in other ways. In fact, these kinds of things come up so often I wonder if it's not encouraged.
It's kinda balsy, though, to get client's admin ids, and then use that to go after their data.... and then when this is cut off, to complain about it.
Especially given the entitled and, if ADP is being honest, dishonest way they portrayed the events.
It's kinda balsy, though, to get client's admin ids, and then use that to go after their data.... and then when this is cut off, to complain about it.
Especially given the entitled and, if ADP is being honest, dishonest way they portrayed the events.
How else would you suggest a 2 person startup compete with likes of ADP? This is client's data not ADP's data.
Zenefits is not a 2 person startup, they're worth billions of dollars, have hundreds of millions in the bank and have several hundred employees. It's probably better to think of them as a privately owned growth company than a start up at this point. (Edit: here's a source http://techcrunch.com/2015/05/06/zenefits-rising-hrs-hottest...)
That's absurd. If you can't do it right (meaning responsibly, ethically, legally, not in a better-is-better sense), I would suggest not doing it. Maybe some things are beyond a 2 person startup, without cheating. That's an ok outcome, if you haven't drunk the "all existing entities must be overcome by hook or by crook, and lo, the ends shall justify the means" SV koolaid.
With the whole SnapChat snafu where 3rd party clients were leaking photos, or getting hacked, it's pretty clear that ADP has a legal mandate to protect their customer's data.
It's an interesting shot back at Zenefits from ADP. I have no way to judge ADP's claims with regard to security and the volume of requests. It would not surprise me if they were true... or not. But I suspect the fourth row in the table is the one that really matters.
OP disclosure: I work at a competitor to both - posting this because I find it generally interesting from a data security and integrations perspective.
What do you think of the ADP claims?
If ADP's claims have any truth (and I can't say if they do), it's shocking and very bad.
Data security (SSNs, banking info) is difficult, but they're table stakes in the payroll and benefits space (ex., how do you securely share personal information across different benefits providers).
Honestly, my main takeaway is I'm happy our company built everything (payroll and benefits) in-house from scratch.
We worry less about integrations issues, and it helps with security when you have more control over everything.
It's been extremely difficult building everything from the ground up, and I've definitely questioned our approach (more than once I said, "Why don't we just integrate with X?"), but I think this validates the path we've taken.
This is a lesson I'm going to take away for whatever other software/service I may end up working on.
Data security (SSNs, banking info) is difficult, but they're table stakes in the payroll and benefits space (ex., how do you securely share personal information across different benefits providers).
Honestly, my main takeaway is I'm happy our company built everything (payroll and benefits) in-house from scratch.
We worry less about integrations issues, and it helps with security when you have more control over everything.
It's been extremely difficult building everything from the ground up, and I've definitely questioned our approach (more than once I said, "Why don't we just integrate with X?"), but I think this validates the path we've taken.
This is a lesson I'm going to take away for whatever other software/service I may end up working on.
> Honestly, my main takeaway is I'm happy our company built everything (payroll and benefits) in-house from scratch.
> We worry less about integrations issues, and it helps with security when you have more control over everything.
This is not a good take away. The same could be said for rolling your own cryptography — control + no integration — which is a really terrible idea.
This doesn't validate your approach since the problem wasn't that a third party you were integrating with messed up your data. I understand why you wanted to build everything in house, but this isn't an example that validates your decision.
This is not a good take away. The same could be said for rolling your own cryptography — control + no integration — which is a really terrible idea.
This doesn't validate your approach since the problem wasn't that a third party you were integrating with messed up your data. I understand why you wanted to build everything in house, but this isn't an example that validates your decision.
Hats off to ADP for responding.
Enterprise integrations are expensive and can take a long time to get to market. So I can see why Zenefits would have avoided doing so for as long as possible.
Perhaps Zenefits, having using their hack-around for a while, needs to look at a proper integration? Call ADP's bluff? If ADP is telling the truth that they've never had conversations about service integrations with Zenefits before, it seems like that may be a good place to start.
Perhaps Zenefits, having using their hack-around for a while, needs to look at a proper integration? Call ADP's bluff? If ADP is telling the truth that they've never had conversations about service integrations with Zenefits before, it seems like that may be a good place to start.
[deleted]
As someone who's team has been responsible for an enterprise integration with ADP on more than one occasion, it's really not that hard. It's well documented on their side, setting up data feeds is trivial if you need them, and one everything is working it's pretty much set & forget reliability. Sure, as mentioned in the previous thread, ADP's portal UX is horrifically dated, but that has nothing to do with back end integration.
I think none of our integration projects had an internal cost (labor) of more than about $20k.
I think none of our integration projects had an internal cost (labor) of more than about $20k.
I also managed an ADP integration & second this.
Their engineers were really quick to respond to us throughout the process too.
Their engineers were really quick to respond to us throughout the process too.
I'm glad they posted this. It sounds like Zenefits could get away with using a startup mentality to work around an enterprise software/platform provider's generally accepted architecture for integrations, if not their explicit TOS, and was burned. Perhaps ADP will learn from this and look at it as an opportunity, or perhaps they won't. It's not like enterprises with ADP contracts are going to switch away from them because they can't use Zenefits on top of it....
Integrating with ADP is easy, but like so many other enterprise software/platform integrations, each project has to be taken independently. Zenefits doesn't want this but ADP doesn't have any real reason to change things.
Integrating with ADP is easy, but like so many other enterprise software/platform integrations, each project has to be taken independently. Zenefits doesn't want this but ADP doesn't have any real reason to change things.
> Integrating with ADP is easy, but like so many other enterprise software/platform integrations, each project has to be taken independently.
How are those two statements not contradictory? Seems to me that if integration was easy (read standardized) it would be agnostic of, not specific to, who was integrating.
How are those two statements not contradictory? Seems to me that if integration was easy (read standardized) it would be agnostic of, not specific to, who was integrating.
"Easy" is not opposed to "time consuming and tedious". Its quite possible (and common, IME, in programming) for things to be both easy and time consuming, tedious things that need to be done one-off for each particular implementation because you are working with something that, for instance, resists the kind of abstractions that would make it generalizable.
Pretty much anything for which recipe-style cookie-cutter patterns are documented, for instance, fits this description.
Pretty much anything for which recipe-style cookie-cutter patterns are documented, for instance, fits this description.
Exactly this. Things like payroll integrations and benefits administration are not obvious and straightforward at any large company. For example, even common things like international transfers or leaves of absence can trigger manual processes at companies that don't have software to do it for them. Integrating with ADP is easy, but figuring out the business logic and process re-engineering is tedious.
It's exactly things like this why I think most programmers and architects should spend at least a year or two working in a large corporation. They'll be exposed to all kinds of situations that just don't exist in a startup (or even most SMBs).
It's exactly things like this why I think most programmers and architects should spend at least a year or two working in a large corporation. They'll be exposed to all kinds of situations that just don't exist in a startup (or even most SMBs).
Easy to me means not technically challenging. Over 90%+ of the enterprise integrations in my careers are tier 1 - 2 easy in the context of software engineering knowledge. It's usually a really convoluted form of "fill in the blanks in a form and pray it works."
But these are all complicated in that you could literally take the smartest person in the history of the world and make about the same rate of progress as if you had taken a pretty average person to do the same thing. These sorts of problems tend to be related to wicked problems. For example, there's a bazillion side effects to consider, meetings to be had about "what does this field mean to you actually?," and other things that are of business importance but are a complete snore to the programmer implementing them. You're not talking about whether to use singly or doubly linked lists or which datastructures to use in an integration almost ever, but you're talking about how well it will scale from the perspective of a business and how its own rules and patterns of use work.
Business algorithms might be something both hard and complicated of a topic, but unless your business is actually something technical such as algorithmic trading, scientific & technical research, etc. your business domain skill level is probably more about depth of knowledge than whether you're really smart or anything in itself.
Also, SOAP was a very popular "standard" but those of us stuck in the pits of writing tons of XML-RPC SOAP code for years knows that it was hardly ever more standardized in practice than "REST" is today.
But these are all complicated in that you could literally take the smartest person in the history of the world and make about the same rate of progress as if you had taken a pretty average person to do the same thing. These sorts of problems tend to be related to wicked problems. For example, there's a bazillion side effects to consider, meetings to be had about "what does this field mean to you actually?," and other things that are of business importance but are a complete snore to the programmer implementing them. You're not talking about whether to use singly or doubly linked lists or which datastructures to use in an integration almost ever, but you're talking about how well it will scale from the perspective of a business and how its own rules and patterns of use work.
Business algorithms might be something both hard and complicated of a topic, but unless your business is actually something technical such as algorithmic trading, scientific & technical research, etc. your business domain skill level is probably more about depth of knowledge than whether you're really smart or anything in itself.
Also, SOAP was a very popular "standard" but those of us stuck in the pits of writing tons of XML-RPC SOAP code for years knows that it was hardly ever more standardized in practice than "REST" is today.
> Our first priority is protecting our clients and their data.
...From themselves? If someone wants to manage their account through a 3rd party that allegedly uses some non-standard way of accessing ADP then that's a risk they decided to take. ADP should be figuring out a way to give Zenefits (and any other similar companies) more secure access to their platform, not cutting them off.
...From themselves? If someone wants to manage their account through a 3rd party that allegedly uses some non-standard way of accessing ADP then that's a risk they decided to take. ADP should be figuring out a way to give Zenefits (and any other similar companies) more secure access to their platform, not cutting them off.
I am not sure why are you down voted. This in the unfortunate reality where incumbents like ADP have no incentives to share their data. Greater the lock-in harder it is for a customer to migrate away from their systems. In this case I would want to give Zenefits a benefit of doubt.
> incumbents like ADP have no incentives to share their data.
It's not ADP's data. It's the employer's data. The employer has decided to use it with Zenefits.
It's not ADP's data. It's the employer's data. The employer has decided to use it with Zenefits.
Stored on ADPs servers with a signed contract granting ADP rights to take any required actions to ensure security and integrity of said data.
Hell, ADP doesn't even allow the transfer of SSNs from one ADP product to another if it's not absolutely necessary!
Hell, ADP doesn't even allow the transfer of SSNs from one ADP product to another if it's not absolutely necessary!
ADP already offers access. Zenefits decided not to utilize that formal access.
>If someone wants to manage their account through a 3rd party that allegedly uses some non-standard way of accessing ADP then that's a risk they decided to take.
would the average ADP customer understand thats whats happening?
would the average ADP customer understand thats whats happening?
> ADP should be figuring out a way to give Zenefits (and any other similar companies) more secure access to their platform, not cutting them off.
From the PDF:
Despite having many legitimate ways to integrate with ADP properly, Zenefits chose an unsecure and indirect approach.
> If someone wants to manage their account through a 3rd party that allegedly uses some non-standard way of accessing ADP then that's a risk they decided to take.
From the PDF:
Despite Zenefits serving less than 0.25% of the clients on our system, they had been responsible for up to 25.0% of the total user traffic (in other words, a hundred-fold times ordinary user traffic).
The Zenefits approach was not only putting excessive and unnecessary demand on ADP’s servers, but it was pulling sensitive information, including unmasked Social Security numbers and employee banking information, in a manner that did not comply with ADP’s standards for data security.
It sounds like ADP did what any company, large or small, would do when faced with a third party accessing its systems in an unauthorized and inefficient manner.
From the PDF:
Despite having many legitimate ways to integrate with ADP properly, Zenefits chose an unsecure and indirect approach.
> If someone wants to manage their account through a 3rd party that allegedly uses some non-standard way of accessing ADP then that's a risk they decided to take.
From the PDF:
Despite Zenefits serving less than 0.25% of the clients on our system, they had been responsible for up to 25.0% of the total user traffic (in other words, a hundred-fold times ordinary user traffic).
The Zenefits approach was not only putting excessive and unnecessary demand on ADP’s servers, but it was pulling sensitive information, including unmasked Social Security numbers and employee banking information, in a manner that did not comply with ADP’s standards for data security.
It sounds like ADP did what any company, large or small, would do when faced with a third party accessing its systems in an unauthorized and inefficient manner.
> Despite having many legitimate ways to integrate with ADP properly, Zenefits chose an unsecure and indirect approach.
Do you really think Zenefits just chose this "lesser" method on a whim? I've never met the team from Zenefits, so I can't say for certain, but if they're not idiots then I think there's a reason why they decided not to use the regular API. Whether that's a requirement of getting their app approved by the ADP Marketplace, or some restriction on the data that they are able to get through the official API - I think that there's something that ADP isn't mentioning.
> It sounds like ADP did what any company, large or small, would do when faced with a third party accessing its systems in an unauthorized and inefficient manner.
As far as unauthorized methods go - you'd patch the hole in your security to prevent them from getting through. Unauthorized methods of accessing your systems shouldn't exist, and blacklisting the domain name of the third-party isn't how you fix a security flaw. For the excessive load, they should just implement rate limiting across their system & return a 429 when someone goes over.
Of course, I really doubt that they were accessing ADP via a real security flaw - they were probably just making the same requests as users are able to, but in an automated fashion. And if that's the case then the term "unauthorized" doesn't apply, because users are clearly authorized to make those requests.
Do you really think Zenefits just chose this "lesser" method on a whim? I've never met the team from Zenefits, so I can't say for certain, but if they're not idiots then I think there's a reason why they decided not to use the regular API. Whether that's a requirement of getting their app approved by the ADP Marketplace, or some restriction on the data that they are able to get through the official API - I think that there's something that ADP isn't mentioning.
> It sounds like ADP did what any company, large or small, would do when faced with a third party accessing its systems in an unauthorized and inefficient manner.
As far as unauthorized methods go - you'd patch the hole in your security to prevent them from getting through. Unauthorized methods of accessing your systems shouldn't exist, and blacklisting the domain name of the third-party isn't how you fix a security flaw. For the excessive load, they should just implement rate limiting across their system & return a 429 when someone goes over.
Of course, I really doubt that they were accessing ADP via a real security flaw - they were probably just making the same requests as users are able to, but in an automated fashion. And if that's the case then the term "unauthorized" doesn't apply, because users are clearly authorized to make those requests.
> As far as unauthorized methods go - you'd patch the hole in your security to prevent them from getting through.
"They gained access to our systems by convincing clients to give them administrative access to our platform."
When ADP's clients giving out administration access[1] is the security hole, that is a reasonable way to patch it. The alternative is for ADP to fire their clients.
[1] I have not seen ADP's TOS, but I would expect giving out the administration login to third party outfits is a violation of it.
"They gained access to our systems by convincing clients to give them administrative access to our platform."
When ADP's clients giving out administration access[1] is the security hole, that is a reasonable way to patch it. The alternative is for ADP to fire their clients.
[1] I have not seen ADP's TOS, but I would expect giving out the administration login to third party outfits is a violation of it.
> I've never met the team from Zenefits, so I can't say for certain, but if they're not idiots...
The founder of Zenefits posted here on HN that "APIs == zero errors"[1]. Anybody who has worked with APIs knows this is not the case so you may be overestimating Zenefits' competence.
> Unauthorized methods of accessing your systems shouldn't exist...
Yes, scrapers should not exist.
The founder of Zenefits posted here on HN that "APIs == zero errors"[1]. Anybody who has worked with APIs knows this is not the case so you may be overestimating Zenefits' competence.
> Unauthorized methods of accessing your systems shouldn't exist...
Yes, scrapers should not exist.
> For the excessive load, they should just implement rate limiting across their system & return a 429 when someone goes over.
Practically, I'm not sure that would be much better for Zenefits.
Practically, I'm not sure that would be much better for Zenefits.
I think that rate limiting might just force Zenefits to stop using whatever contributed to the high load, and ensure that their API calls are efficient enough. Otherwise, if they really can't do without that volume of calls, then at least they would be locked out in the same way that everyone else is & they couldn't really call it unfair.
I hate ADP with a burning passion (as a user of them across three different companies now) but their points are totally reasonable. Zenefits looks like a petulant child and seems to have made no good faith effort to integrate with ADP properly.
"but it was pulling sensitive information, including unmasked Social Security numbers and employee banking information"
Did ADP just admit they keep SSN and banking information in plain text on their servers???
Did ADP just admit they keep SSN and banking information in plain text on their servers???
[deleted]
No, but they admitted you can access that information if you are logged into an account.
If you have figured out a way to do something like print a employee's copy of an IRS form like a W-2 or 1099 without having plaintext SSN information involved in the process I would sure be curious to hear about it.
If you have figured out a way to do something like print a employee's copy of an IRS form like a W-2 or 1099 without having plaintext SSN information involved in the process I would sure be curious to hear about it.
That raises an interesting question. Why is my SSN printed on my W-2?
Presumably I already know my SSN, so do not need the W-2 to remind me of it.
Presumably I already know my SSN, so do not need the W-2 to remind me of it.
Because the SSN is the "primary key" for pretty much all interactions with the taxing authorities. That's why it's called a "Taxpayer Identification Number" and so on. Sure it's a sensitive piece of info, at least to some extent, but it's not some highly classified secret. Putting it on tax forms is sort of the point.
Right, which is why it needs to be on everything I send to the IRS, or that my employer (or their agents such as payroll companies) send to the IRS concerning me.
But I don't see why it needs to be on things my employer (or their agents) send to me. Sure, SSN is not some highly classified secret, and it is on enough things it does not need to be on that having it on W-2 probably doesn't noticeably cause any extra harm. I'm just curious if it actually needs to be there.
If I'm doing my tax return on paper instead of electronically, and need to physically attach a copy of my W-2, I can fill in the SSN field, just like I filed in the SSN field on the top of the 1040. Having the SSN on the form then, when it goes to the IRS makes sense so that they can match it up to the 1040 if it becomes separated from it accidentally [1].
If I'm doing my tax return electronically, the IRS uses the W-2 information they get from my employer (or its agents) electronically. The paper W-2 is really just to let me know the pay and withholding numbers so I can fill out my returns.
[1] Well, maybe not. It did back in the days when they actually looked at the physical W-2, but now I believe they get an electronic copy even if the taxpayer is not filing electronically, and so I don't think they look at the attached W-2. In fact, I vaguely recall the last time I filed a paper return being told not to attach my W-2, although I'm not certain of that.
But I don't see why it needs to be on things my employer (or their agents) send to me. Sure, SSN is not some highly classified secret, and it is on enough things it does not need to be on that having it on W-2 probably doesn't noticeably cause any extra harm. I'm just curious if it actually needs to be there.
If I'm doing my tax return on paper instead of electronically, and need to physically attach a copy of my W-2, I can fill in the SSN field, just like I filed in the SSN field on the top of the 1040. Having the SSN on the form then, when it goes to the IRS makes sense so that they can match it up to the 1040 if it becomes separated from it accidentally [1].
If I'm doing my tax return electronically, the IRS uses the W-2 information they get from my employer (or its agents) electronically. The paper W-2 is really just to let me know the pay and withholding numbers so I can fill out my returns.
[1] Well, maybe not. It did back in the days when they actually looked at the physical W-2, but now I believe they get an electronic copy even if the taxpayer is not filing electronically, and so I don't think they look at the attached W-2. In fact, I vaguely recall the last time I filed a paper return being told not to attach my W-2, although I'm not certain of that.
I'm not sure that entirely makes sense. This presupposes that your name and salary information is somehow less sensitive information than your SSN, and ignores the fact that essentially the entire point of the form existing at all is to document the statement "Please match SSN [X] with income [Y]" and removing one of those two pieces of data defeats that purpose.
One reason could be so that you could verify that your information was sent to the IRS with the correct SSN.
Not at all. They said that Zenefits was pulling that info from their servers. ADP is probably not happy with the the prospect of Zenefits being a potential breach source for that info.
Worse, that "in a manner that did not comply with ADT's standards for... security". So apparently you can retrieve sensitive information from them insecurely.
if you can view the info you've put on then site, the yes. it sounds like zenefits was scraping the personal ui. how could you display someone's social security number to them so that a screen grabber couldn't' get it?
as a heavily mangled captcha?
No. They admitted they keep it in some form that can be converted to plain text.
I would expact that they need SSN for reporting to the IRS, and bank information for direct deposit. If they are following proper security practices, these will be encrypted on the servers, and get decrypted as needed.
I'm not familiar with what clients can do via the administrative interface, so don't know if it is reasonable to provide access to the decrypted data over that interface.
I would expact that they need SSN for reporting to the IRS, and bank information for direct deposit. If they are following proper security practices, these will be encrypted on the servers, and get decrypted as needed.
I'm not familiar with what clients can do via the administrative interface, so don't know if it is reasonable to provide access to the decrypted data over that interface.
I never expected to feel sympathy for ADP. This is a pretty effective PDF.
Now where's the Zenefits rebuttal to this salvo? I think this story is really interesting on a number of levels.
Zenefits just released a response: http://blog.zenefits.com/adp/
They're probably too busy right now talking to their recent investors [1] to provide one.
[1] http://techcrunch.com/2015/05/06/zenefits-rising-hrs-hottest...
[1] http://techcrunch.com/2015/05/06/zenefits-rising-hrs-hottest...
They weren't too busy to fire off the initial complaint over social media though? Supposedly that's what prompted ADP's response, though I can't find a link to Zenefits complaint.
Using ADP was the worst part of my week at my previous company. This PDF is better designed than anything I ever saw from ADP. And good to know of have more ideas about both sides of the story.
Just swap this story around and change it to:
Big corp. starts illegally stealing data through improper means and not following T&C of small-funded startup
and there would be an uproar.
All those fluff tech-sites that treat Apples new Iphone with incremental changes as "big news" would suddenly have months of juicy news to bash the big corp to the point where their bigger media-parent companies would follow suit and damage the big corp indefinitely.
Maybe folks should just call "a spade a spade" here.
The startup violated the T&C of ADP and whether or not ADP is 100% honest of the server-volume from this company, the startup still committed an illegal action.
You can "disrupt" industries all you like, but when you break explicit contracts, you can't go crying on social media about it and expect things to work out for you.
As far as PR goes, ADP won with this line:
"We’re willing to work with our clients who use Zenefits, and with Zenefits directly, to find a solution that fulfills our clients’ needs and protects their data."
Big corp. starts illegally stealing data through improper means and not following T&C of small-funded startup
and there would be an uproar.
All those fluff tech-sites that treat Apples new Iphone with incremental changes as "big news" would suddenly have months of juicy news to bash the big corp to the point where their bigger media-parent companies would follow suit and damage the big corp indefinitely.
Maybe folks should just call "a spade a spade" here.
The startup violated the T&C of ADP and whether or not ADP is 100% honest of the server-volume from this company, the startup still committed an illegal action.
You can "disrupt" industries all you like, but when you break explicit contracts, you can't go crying on social media about it and expect things to work out for you.
As far as PR goes, ADP won with this line:
"We’re willing to work with our clients who use Zenefits, and with Zenefits directly, to find a solution that fulfills our clients’ needs and protects their data."
> The startup violated the T&C of ADP
Here's a fun question... Did Zenefits ever agree to the TOS?
Here's a fun question... Did Zenefits ever agree to the TOS?
> By using the Zenefits Service, you hereby grant us permission to access your Account Information maintained by identified third parties, and make changes to this information as directed by you, on your behalf as your agent. When you use the 'sync payroll' feature of the Service, you will be directly connected to the website or APIs for the third party you have identified. We will submit information including usernames and passwords that you provide to log you into the site. You hereby authorize and permit us to use and store information submitted by you (such as account passwords and user names) to accomplish the foregoing and to configure the Zenefits Service so it is compatible with the third party sites for which you submit your information.
So basically a user of Zenefits gives Zenefits the authority to act as an agent on behalf of them. So, technically when Zenefits accesses the ADP site they are legally seen as the authorized user themselves.
If I knew that a service was going to act on my behalf towards another party and that other party wasn't happy about the way that service behaved towards them. I might question my use of letting that service act as my agent.
Zenefits is actually pretty smart here because they can say "our users want this, they've agreed to our ToS that says we act on their behalf".
So basically a user of Zenefits gives Zenefits the authority to act as an agent on behalf of them. So, technically when Zenefits accesses the ADP site they are legally seen as the authorized user themselves.
If I knew that a service was going to act on my behalf towards another party and that other party wasn't happy about the way that service behaved towards them. I might question my use of letting that service act as my agent.
Zenefits is actually pretty smart here because they can say "our users want this, they've agreed to our ToS that says we act on their behalf".
I disagree with your conclusion there. Having your clients violate the ADP TOS (and then subsequently violating it yourself while scraping data) is clearly not a smart move as illustrated by ADP's response.
Agreed. Zenefits took an engineering/business shortcut by scraping and using the default 3rd party user credentials. It was only a matter of time before this got shut off. They'll do what every other large 3rd party does, sign an MSA of some sort, build a better integration, and pay a massive annual fee to ADP for access. This is Financial Services
From a business ethics and security sense, I'm on ADP's side here. However, this type of press (or awareness) from ADP customers' is what makes this move smart: https://twitter.com/AaronKlein/status/607051950928953344
Imagine Zenefits was simply a broker and your broker said to you "ADP just shut off my access to them so I can't use their service, how about we use XYZ instead?". As long as I trust my broker is providing value then it doesn't matter what payroll service I use. So, if Zenefits is confident people value their service above the service a payroll service provides, then they will most likely win in this case.
Imagine Zenefits was simply a broker and your broker said to you "ADP just shut off my access to them so I can't use their service, how about we use XYZ instead?". As long as I trust my broker is providing value then it doesn't matter what payroll service I use. So, if Zenefits is confident people value their service above the service a payroll service provides, then they will most likely win in this case.
"By accessing and/or using the Site, you indicate your acceptance of these terms and conditions." [1]
IANAL - It seems as though they did agree.
1: http://www.adp.com/legal.aspx
IANAL - It seems as though they did agree.
1: http://www.adp.com/legal.aspx
"By accessing and/or using the Site, you indicate your acceptance of the sale of your soul to the devil."
i posted this yesterday, but the top three reasons i didn't go with zenefits (not that it matters because apparently they are taking over the world):
1. sales people were pushy dickheads that implied i was wasting their time by re-scheduling their demo due to emergency client issues, when i am their prime audience - an overworked, underpaid, understaffed startup founder.
2. they couldn't articulate how they integrate with my payroll service. it was a bunch of hand waving and "trust us". unfortunately i know how technology works and i'm not going to "trust" anyone unless they have a well defined solution.
had i known i was supposed to give them my administrator login information, it would have been a non-starter anyway.
3. the fact that their business model was basically to take business from existing insurance brokers seemed a little lame to me. why can't i just pay for your services?
1. sales people were pushy dickheads that implied i was wasting their time by re-scheduling their demo due to emergency client issues, when i am their prime audience - an overworked, underpaid, understaffed startup founder.
2. they couldn't articulate how they integrate with my payroll service. it was a bunch of hand waving and "trust us". unfortunately i know how technology works and i'm not going to "trust" anyone unless they have a well defined solution.
had i known i was supposed to give them my administrator login information, it would have been a non-starter anyway.
3. the fact that their business model was basically to take business from existing insurance brokers seemed a little lame to me. why can't i just pay for your services?
1. OK - I agree.
2. So - did you get mint.com to tell you how they integrated with your bank(s) ? Did your local bank tell you, for that matter, how they did background searches on their staff ?
3. You clearly don't manage a company with issues like COBRA, insurance, or payroll.
I almost didn't get past #1, but #2 and #3 were non-issues. Why? Because when you manage a business, you have to focus on your core business: So either pay to outsource HR (6K month, thats a salary right there), risk noncompliance with a broker, or go with Zenefits and worry about under-the-bed monsters that do not exist under #2-#3.
2. So - did you get mint.com to tell you how they integrated with your bank(s) ? Did your local bank tell you, for that matter, how they did background searches on their staff ?
3. You clearly don't manage a company with issues like COBRA, insurance, or payroll.
I almost didn't get past #1, but #2 and #3 were non-issues. Why? Because when you manage a business, you have to focus on your core business: So either pay to outsource HR (6K month, thats a salary right there), risk noncompliance with a broker, or go with Zenefits and worry about under-the-bed monsters that do not exist under #2-#3.
i think the only thing that's clear here is you don't actually run a business, because you're pretty much wrong, or make incorrect assumptions, on every single point.
for example: i do know the background-check procedures my bank uses on its employees. it's in the fucking brochure they give you when you open a commercial account.
for example: i do know the background-check procedures my bank uses on its employees. it's in the fucking brochure they give you when you open a commercial account.
every single point you've made is wrong.
It's funny watching the Zenefits response: Bring in the yComb & Celebrity Investors (Jared Leto / Ashton Kutcher) to get public opinion on their side via twitter #ADPeeved and a Change.org petition. So far at least on social media there's not a lot of noise from impacted customers. Just negotiate an MSA, pay the fee, build a proper integration and perform better Risk Management in the future (like a $4.5B business should).
Why doesn't Zenefits just become a payroll provider? Is the an enormous amount of regulation around providing payroll services?
That [currently] is not Zenefits' business model. Their entire premise is that you can practically use any providers you want for your benefits such as various 401K providers, various health care plans, etc., as well as any payroll vendor. Zenefits makes its money as a broker when you choose to go through Zenefits to get things such as payroll or benefits administration services. But the key is that Zenefits itself is not providing the said services. They are paid on commission or rev. share with the providers that ultimately service Zenefits customers.
While they could become a payroll provider themselves, that isn't really their mission. As well, it's not so trivial to write some software "over the weekend" and have a solid payroll system. While payroll companies actually have very little regulation (this is true, and somewhat surprising), it is complex to build a payroll system that can accommodate all the various needs of clients. Just to name a few things to get started: Hourly, salary, pay cycles, 1099, fed/state/local taxes and tax codes and rates, time off tracking, punch in/punch out, check printing and electronic deposit, paper and electronic tax filing, tax payments, garnishments, time off tracking, pre/post-tax deductions, worker's compensation rates, union dues, and the list just goes on from there.
While they could become a payroll provider themselves, that isn't really their mission. As well, it's not so trivial to write some software "over the weekend" and have a solid payroll system. While payroll companies actually have very little regulation (this is true, and somewhat surprising), it is complex to build a payroll system that can accommodate all the various needs of clients. Just to name a few things to get started: Hourly, salary, pay cycles, 1099, fed/state/local taxes and tax codes and rates, time off tracking, punch in/punch out, check printing and electronic deposit, paper and electronic tax filing, tax payments, garnishments, time off tracking, pre/post-tax deductions, worker's compensation rates, union dues, and the list just goes on from there.
There sure is. I've got a tiny bit of experience with ZenPayroll, and they're separately licensed in the states they're permitted to operate in (and it's a minority of states, IIRC).