Hi everyone! I'm new here, and I've been tasked with reviewing our new contract for a support ticketing SaaS. I'm a bit stuck on the warranty section.
I was expecting some standard promises about the software working as described, but the language is really bare. It basically says the service is provided 'as is' and 'as available'. There's no mention of uptime guarantees or that the features will match the sales demo. Is this normal? 😅
I come from more of a project management background, so I'm still learning the legal side of things. I'm worried this leaves us with no recourse if the platform has major bugs or goes down frequently. Our team is really counting on this tool to streamline our customer support.
Has anyone else seen this? Should I push back and ask for more specific warranties, or is this just standard boilerplate I shouldn't worry about? Any advice on what to ask for instead would be super helpful.
Yeah, that's pretty common, especially with smaller or newer SaaS vendors. The 'as is' language basically limits their liability. It's not great, but I've seen it a lot.
Your concern about uptime and features is valid, though. You might not get them to rewrite the warranty, but you can ask for addendums. Push for a separate SLA with specific uptime percentages and penalties (like service credits) if they're missed. For features, ask if they can reference the product description or a specific feature list in the contract as the "service specifications."
It turns the sales demo from a marketing thing into a contractual baseline. Worth a shot
Yes, it's common, but you're absolutely right to be concerned. From a project management view, you need reliable inputs to deliver outputs, and an 'as is' clause turns a critical tool into a variable you can't control.
I always treat this as a negotiation point. Since you're new to this, here's a practical script you can adapt: "We understand the standard warranty position. To make this partnership work, we need some stability around service levels. Can we attach a simple SLA schedule with a 99% uptime commitment and service credits for outages? Also, can we incorporate the feature list from our proposal document as Exhibit A, so we have a shared baseline?"
It moves the conversation from challenging their legal terms to solving your operational need. They might not budge on the core language, but you can often get these attachments. Let us know how it goes
Measure twice, automate once.
That negotiation script is solid advice. It mirrors how we approach vendors in the self-hosted space when evaluating their enterprise support tiers. A caveat from that experience: the financial penalty in those service credits is often capped very low, sometimes to just the previous month's fee. It makes the SLA more of a symbolic commitment than a true financial risk for the vendor.
You can probe this by asking for the credit calculation formula before signing. If the remedy for a major outage is a 5% discount, the operational risk hasn't really been mitigated.
It's totally normal to be worried about that. I'm in the same boat, learning this stuff as I go with our ERP.
One thing I learned the hard way is that 'as is' can also mean they might change core features without notice, and you'd have no say. Even if they add an SLA, you should check the "modification" clause. Sometimes they can change the tool so much it's not what you bought anymore.
The script from user1395 is really good. I'm saving that.
Spot on about checking the modification clause. That's often where the real risk is buried, not the upfront warranty.
I've seen vendors who met a 99.9% uptime SLA, but quietly changed the data schema or API in a "routine update" that broke all our integrations. The SLA was useless because the service was technically "available," just not in a usable way.
Push to get the current API spec or core feature definitions appended as an exhibit. Makes "as is" refer to something concrete you can measure.
show me the bill
Totally normal to be worried, especially coming from project management where you need predictable inputs. You're right to want more clarity.
The 'as is' clause is common boilerplate, but treating it as *non-negotiable* is a mistake. You should absolutely push back. Your goal isn't to rewrite their legal section, it's to attach schedules that define what "as is" actually means for your day-to-day. Ask for an SLA (even a basic one) and an exhibit listing the core features you're buying. That way, if the service drifts from that baseline, you have a concrete point of reference for a conversation, which is often all the leverage you need.
The script user1395 gave is perfect for this. It frames it as a partnership need, not a legal fight. Good luck
Keep it civil, keep it real.
Yes, this is a standard starting position, especially for vendors who want to limit their liability. Your concern is completely valid from a project management perspective, because you're right, an 'as is' clause turns a critical dependency into an uncontrollable variable.
You should absolutely push back, but the key is framing. Don't ask them to delete the warranty clause. Instead, follow the excellent advice here and request attached schedules that define the baseline. Specifically, ask for an SLA with an uptime percentage and a remedy, and an exhibit that incorporates the feature list from your sales proposal or a specific API documentation version. This makes "as is" refer to something measurable.
A practical next step is to check the 'Modification' or 'Changes to the Service' clause right now, before you even reply. If they can unilaterally change the features underlying your attached exhibits, those documents become pointless. You'll need to tie the modification clause to those exhibits, so any material change to the listed features or specs requires advance notice or constitutes a breach of the agreement.
Normal for a starting position, not normal to accept as final.
The main risk isn't the downtime you see, it's the feature drift you don't. An 'as is' warranty with no attached baseline means they can change the API or core workflow in an update and you have no standing.
Your pushback should be to attach exhibits. Get the current API spec or a specific feature list from the sales proposal appended. That way 'as is' refers to that documented state, not a moving target. It gives you a concrete baseline for future disputes.
Numbers don't lie.
Yeah, the feature drift point is huge. Even with a solid SLA, we got burned when a vendor "updated" their reporting module and half our custom dashboards broke. The service was up, but the value was gone.
That's a great tip about appending the exact API spec. Going to ask for that explicitly next time.
Does anyone have experience getting vendors to actually version those exhibits? Or do they usually just attach a static PDF that becomes outdated?
Getting them to version the exhibits is a real challenge. In my experience, attaching a static PDF is the most common outcome. It's often a battle just to get the current spec included, let alone a commitment to keep it updated.
You can try asking for a clause that states any "material changes" to the attached API spec or feature list require X days of notice, or even a mutual agreement. That's been more achievable for us than true versioning. It doesn't solve everything, but it moves the baseline from a frozen document to something with a change control process, however light.
Has anyone had success getting a formal versioning clause, where the exhibit number increments with each spec update? I imagine only the largest vendors with mature legal processes would entertain that.
Yeah, the static PDF thing is what I'm afraid of. It feels like it solves today's problem but creates a new one in six months when everything is different.
Has anyone had luck with just asking for a snapshot of the current public documentation, with the date and URL? That way it's at least *referencing* something that might get updated, even if the attachment itself doesn't. Or is that too flimsy?
I'm really new to this, so sorry if that's a silly idea. The "material changes" clause suggestion seems like a good middle ground I could actually ask for without feeling in over my head.
Yeah, that's super common boilerplate. But don't let them tell you it's non-negotiable just because it's standard.
Coming from project management, your instinct is right. An 'as is' clause with no attached SLA or feature baseline turns the tool into a complete unknown. It's not just about uptime, it's about the platform staying usable for your specific workflows.
Instead of asking them to rewrite the warranty, ask to add an exhibit that lists the core features from the sales demo or a current API spec. That way "as is" refers to that specific snapshot, not a moving target. Makes it way easier to have a conversation later if things change. Did the sales team give you a specific feature list you could reference?
Totally agree that attaching a sales feature list is a solid move. It bridges the gap between "as is" legalese and the working relationship you need.
One thing I'd add: when you ask for that exhibit, be specific about the *deliverable format*. A lot of times they'll agree, then send over a two-page marketing PDF. Instead, request something like a version-stamped document (even if it's just "Version 1.0 - March 2024") from their internal Confluence or Notion. Makes it feel more like an official artifact than a sales slide.
We've even had success getting a high-level architecture diagram included. It sounds fluffy, but when they changed a core data flow later, pointing to that diagram gave us a much stronger "this is not the service we bought" position.
Pipeline Pilot
The addendum approach is the right one. Pushing for a separate SLA is good, but be ready for the credit negotiation. They'll often offer credits that are a fraction of your monthly fee, which is meaningless if the outage costs you real business.
And on features, specifying the exact proposal document with a date stamp is critical. Otherwise you get a generic "product description" that's just more marketing fluff.