Consider the following:
The User may monitor its Service account via the “Acme Portal,” which is available at www.acme.com/accounts.
It’s phrased as language of discretion, but I don’t think that makes sense. Acme isn’t saying, “We’re allowing you to access your account in this manner.” Instead, the idea is that anyone who has an account can access it in that manner.
So how would you express that?
***
Updated 27 December 2015:
OK, enough pussyfooting around. Here’s an alternative formulation:
The User can monitor its Service account via the “Acme Portal,” which is available at www.acme.com/accounts.
If that functionality (I know, that’s not a great word) is a basic feature of the service in question, it might be ponderous to phrase it as language of obligation, as Mark suggests in his comment.
But I offer this with extreme trepidation, as currently no such category exists in the categories-of-contract-language universe.
***
Updated 28 December 2015:
Isn’t this a statement of fact by the vendor? Here’s how that would read:
The Vendor states that the User can monitor its Service account via the “Acme Portal,” which is available at www.acme.com/accounts.
Extra slash in the URL. Try http://www.acme.com/accounts.
SaaS? Two aspects:
1. The provider promises to provide a monitoring page (at the given address). What the monitoring page will show is often left unsaid.
2. The provider waives claim against the client for unauthorized access to the monitoring page, probably subject to general use restrictions—no overloading systems, violating the law using the services, etc.—elsewhere in the terms.
Language achieving #1 usually covers #2 by very strong implication. #1 is obligation, usually in an exhibit list of features or description of the service provided.
It’s often worth addressing remedies. How critical is the management page? Is failure to provide it, in working order, material breach? Is a missing or malfunctioning monitoring page downtime under the SLA?
On the tech side, if the client is security-conscious: Is there more than user name and password pair for the client? Can each user access a monitoring page for its own usage? Can one (“administrator”) account access a single monitoring page for all users belonging to the client?
That’s useful background information, but it doesn’t address the narrow question posed.
I’m sorry. I can’t quite make sense of the narrow question posed.
Even if the context is publicly posted terms of use, the norm for statements of “what the service does now” is provider obligation plus provision reserving right to change or drop features, perhaps with notice. Bare statements of what the service does beg interpretation as obligations, no matter how they’re phrased.
Is this as simple as “here is a URL you can bookmark, without worrying it will move or disappear in the future”?
But isn’t imposing an obligation on the vendor to create the portal different from saying how the user can monitor its account?
Ah, see Mark Anderson’s comment …
I think I’m catching up!
I’ve seen something as specific as the URL for accessing a feature of a software service come up in two situations:
1. The client intends to automate use of the feature, say by having software access and read information from the page. (Check for a “spidering”, “crawling”, “automated use”, or similar prohibited use provision.)
2. Information found on the page, such as uptime information, has meaning under other terms, like SLA.
The details usually end up in documentation for the service, published or provided under NDA. The contract incorporates via warranty of substantial compliance with documentation. Less often, as a covenant to do the things in an exhibit. In bespoke deals, there is probably change control for doc, among other documents.
Lighter-weight, informal, and back-of-napkin:
“As part of the Service, Acme shall provide an “Acme Portal” that reports {information} to User at http://www.acme.com/accounts through the whole term. Acme shall give User prior notice of any new URL where the Acme Portal will be accessible.”
Acme shall provide to the User access to the Acme Portal for the purpose of accessing its Service account.
I reckon so.
One feels good about oneself if one can shave four words off Mark’s word count: ‘Acme shall provide the User with access to its Service account via the Acme Portal’.
The original pertains not to discretion, but to ability.
The word warranty isn’t a categories-of-contract-language concept.
Re updated formulation: If the drafting task at hand is truly not to state a duty, but only to state the simple fact that the User has the ability to monitor its Service account in a particular way, then yes, you are short one category of contract language, ‘incidental facts’.
But if you are thinking about adding such a category, consider that instances of such language may be deemed warranties. Surely the User would be motivated to so argue if Acme cut off the User’s ability to monitor the User’s Service account.
See my update.
If it is a technical feature of the service rather than an obligation, it is not really a contract term, though it might form part of an agreed Specification. Perhaps there should be a category of “FYI” terms?
Often pondering, but trying not to be ponderous…
Behold my third version.
If you want to shoehorn incidental facts into an existing category, language of declaration is the best candidate.
That said, it’s a weird fit.
MSCD3 @ 3.27 says contracts contain two kinds of assertions of fact, acknowledgments and assertions where ‘the declaring party has knowledge of a fact and the other party wants the declaring party to assert in the contract that the fact is accurate’.
Of all the features of the Service, why would the User want the Vendor to state in the contract the accuracy of the one fact that the User can access its Service account at a certain Web address?
Version 3 also leaves the chronological element at sea. ‘[A] statement of fact is either accurate or inaccurate–it cannot *become* inaccurate’. MSCD 3.311.
As written in version 3, the fact (‘can monitor’) is stated to be true as of the instant of signing but at no later time.
Maybe that’s intentional, and the Vendor doesn’t want to say that the User ‘will be able’ to monitor its Service account via the portal for some period of time.
Making the fact into an instance of language of declaration wouldn’t immunize it from being treated as a warranty in a jurisdiction where creation of a warranty needs neither formal words nor intent to create a warranty.
Finally, is it prudent to leave unstated that falsity of the stated fact at signing or later carries no contractual consequence for the Vendor (if that’s what the parties intend)?
I agree that it’s an oddball fact, but it happened to catch my eye, so I built an example around it. I could dream up a more plausible example, but the semantics would be unaffected.
Yes, it speaks only as of the time of signing, but that’s a separate issue.
Again, the term of art warranty isn’t directly relevant to categories of contract language.
Not quite getting the point of the observation about warranties. Isn’t every warranty an instance of language of declaration, so that if you identify a statement of fact as a warranty, you have thereby determined the category of contract language to which it belongs?
Nope: at least according to the UCC, a warranty can be a statement of fact or an obligation.
Okay, but you said the original language of discretion didn’t ‘make sense’ because it didn’t express ‘the idea’, which was to say that the User can access the account in a certain manner.
You dismissed Mark’s suggested language of obligation in favour of (1) a ‘naked’ fact formulation, then (2) a fact with a speaker and a speaking verb. My point is that both run the risk of creating a warranty, and a warranty is not ‘the idea’.
To succeed at warranty-free, obligation-free statements of fact will apparently require another approach, perhaps exculpatory language (‘The Vendor States, without warranty, that the User can…’). That expresses ‘the idea’ without warranty baggage, and uses an existing category of contract language to do so.
What the what?
Ken:
I think you really have to know what the author is trying to achieve.
If the author is the User, then maybe the User wants language of obligation.
If the author is the Vendor, then maybe the Vendor wants to set up an argument that User failed to mitigate losses by failing to regularly check on its accounts, in which case the Vendor might start the sentence with “User acknowledges that.” And if the Vendor has a more elaborate procedure for claiming damages (through service level agreements or whatever), then that might introduce a provision allowing the User to claim amounts based on what the page shows (or whatever the process is).
Chris
What you suggest sounds like gaming the system. I suggest that the nature of the issue and how it relates to the deal will determine which category of contract language makes most sense.
Ken:
No, I’m not gaming the system. The deal ought to reflect whatever it is that the parties are trying to achieve. So, the author should choose a category of contract language that reflects what he or she is trying to achieve. Provisions setting up mitigation-of-loss arguments are pretty common in service contracts.
Thus far, you haven’t been very clear about what the nature of the issue is. All you have said is that the “the idea is that anyone who has an account can access it in that manner.” That doesn’t tell us what legal result either party to the deal wants. Or, to use your software analogy, when you compile and run the code, what do you want it to have done?
If, as you say, the idea is simply to inform the User of how to access information about the User’s accounts, that might be better stated outside of the contract. After all, words in contracts are about creating outcomes, not about educating. So, if the idea is truly just to tell the User something without creating any legal outcome, then maybe that information ought to go in the user’s guide or the training package.
Chris
Ken:
One final thought, though a little off the beaten path. If you need to encourage the user to regularly check their account status, then you might use language of recommendation: “Vendor recommends that User monitor its Service account via the “Acme Portal,” which is available at http://www.acme.com/accounts.” Again, this might set up a mitigation-of-loss argument.
Chris
‘If, as you say, the idea is simply to inform the User of how to access information about the User’s accounts, that might be better stated outside of the contract.’
Agreed, but if it’s an unexplained given that the contract itself must state the fact in question, why not just state the fact and not worry about whether it falls into any category of contract language?
Then no one has to dream up an obligation, prohibition, policy, recommendation, intention, belief, performance, or declaration to stuff the simple fact into.
I’ve suggested that in this case the choice boils down to language of obligation (if something needs to be built) or language of declaration (if something’s already in place). Generally, choice is driven by context, not by party agendas. That’s clear once you lay out explicitly what the alternatives are, as in this post.