# SaaS service not as described: compare the promise with the product

[By Evidenz](https://evidenz.dev/)  5 min read

A customer may receive access to a SaaS product and still dispute whether it matched the offer. Compare the description relevant to the purchase with the functionality delivered to that account during the paid period. Preserve the specific discrepancy and the attempted resolution; a successful login does not settle a missing-feature complaint.

A SaaS service-not-as-described complaint concerns the difference between what the customer says they bought and what the product provided. Start with that difference. In B2C, it might be a missing export format in a personal subscription. In B2B, it might be a company workspace without the automation included in its agreement. Access and activity matter, but they cannot explain the discrepancy on their own.

## Is this non-delivery, a missing feature, or dissatisfaction?

Identify the customer's actual complaint before selecting the evidence. “I could not open my account” calls for an access investigation. “I could open it, but the promised export was unavailable” requires a comparison with the offer. “I did not like the results” needs a more specific explanation of the expectation and any promised standard.

[Stripe distinguishes product-not-received from product-unacceptable claims, including products or services represented inaccurately before purchase.](https://docs.stripe.com/disputes/categories) Read the category on the actual case alongside the customer's wording. Do not reframe a quality complaint as non-delivery merely because the access records are easier to retrieve.

The [digital-service delivery guide](https://evidenz.dev/articles/digital-service-not-received) owns the access question. Here, the task is to establish which promised function or characteristic the customer says was missing or different. Subjective dissatisfaction should be investigated fairly without automatically treating it as a proven defect or an invalid complaint.

## What did this purchase actually include?

Retrieve the offer relevant to the payment: the plan description, checkout wording, order form, or specific sales commitment. Record its version or date, the account or workspace, and the covered period. Today's pricing page may describe a feature added after the purchase or a limitation introduced later.

Keep qualifying details beside the promise. A feature described as included, a separately purchased add-on, and a roadmap item need their own wording and availability context. If the customer cites an email commitment that differs from the plan page, retain both and investigate the discrepancy.

Then inspect the customer's actual configuration: plan, entitlements, feature flags, relevant software version, and prerequisites. A feature existing somewhere in the product does not establish that it was available to this paid account.

## Compare the promise with the delivered function

[Adyen's guidance for digital goods and services distinguishes evidence that a service was as described from evidence of its use.](https://docs.adyen.com/risk-management/understanding-disputes/dispute-reason-codes) Check the applicable reason-specific requirements. The table below is an internal review aid, not a universal submission form.

A promise-to-function review for a SaaS complaint

| Part of the review | Record to inspect | Question to resolve |
| --- | --- | --- |
| Historical promise | Relevant plan page, checkout, agreement, or sales message. | What function or standard was represented for this purchase? |
| Account and period | Subscription, workspace, entitlement, and effective dates. | Which account and paid interval did the promise cover? |
| Delivered function | Relevant output, configuration, attempted operation, and result. | What could the customer actually do, and when? |
| Specific discrepancy | Customer explanation, reproduced behavior, and contrary records. | Which part differs, and what remains uncertain? |
| Attempted remedy | Original support reply, repair, workaround, or verified financial adjustment. | What was offered, carried out, and still unresolved? |

Explain what a technical event means. A video export may produce embedded captions while the complaint concerns a separate subtitle file. A dashboard download may be manual while the paid feature is scheduled delivery. Keep those actions distinct.

## Personal subscription: the export worked, but the promised format was missing

**Illustrative B2C case.** A creator buys a captioning-app subscription after the offer lists downloadable subtitle files. The account exports three videos with captions embedded in the image. The customer asks where to download an SRT subtitle file; support confirms that this plan cannot produce it.

The video exports establish use of one function. They do not show delivery of the separate file described in the offer. Preserve the historical description, selected plan, available export choices, and original support reply. The finding should name the exact mismatch instead of saying either “nothing was delivered” or “the customer used the product, so the complaint is false.”

If the records show that SRT export was available through another screen, investigate whether the customer could use it and what instructions were supplied. A different explanation needs records too.

## Company workspace: manual use does not establish scheduled automation

**Illustrative B2B case.** An analytics workspace's order form includes scheduled CSV exports from the start of the paid period. Members view dashboards and download CSV files manually. The customer disputes the subscription because the scheduled exports never run. Engineering finds that the workspace's scheduling entitlement was not enabled.

Follow the order form to the billed workspace, then compare the entitlement history, schedule configuration, attempted runs, and support correspondence. Manual downloads explain some use; they do not establish that the included automation was provided.

Check prerequisites rather than assuming every absent run is a product failure. If the scheduler required a destination or permission, inspect the configuration and the instructions applicable then. Preserve any provider-side failure or missed setup commitment as well as a customer-side configuration gap.

## Record the remedy as carefully as the defect

A repair, workaround, service extension, account credit, and card refund describe different actions. Record what support proposed, whether the customer agreed, what happened, and when. A later working feature does not erase the record of an earlier unavailable period.

[Intercom distinguishes internal notes from customer-facing replies.](https://www.intercom.com/help/en/articles/8300304-how-to-manage-customer-tickets) When reviewing a remedy, identify the original message and its audience. An internal suggestion to offer credit is not the same record as a credit promised to the customer or a confirmed adjustment.

If the charge is disputed, follow the provider's current case instructions before taking another financial action. Use the [accept-or-contest framework](https://evidenz.dev/articles/accept-or-contest-chargeback) to document the finding, including facts supporting the customer. The response should explain the relevant promise, delivered function, discrepancy, and resolution with readable supporting records. The [attachment guide](https://evidenz.dev/articles/preparing-dispute-evidence-files) covers preparing those records for review.

## Keep the offer beside the customer history

Evidenz is being built for B2C and B2B SaaS investigations where payment, account, support, and product records need to be understood together. For a service-quality complaint, its intended timeline should keep the relevant plan and account alongside actual access, feature behavior, and support commitments. That context matters when one team sees successful activity while another has acknowledged a missing feature. The useful finding explains both. The case owner still needs to verify the promise and choose an appropriate response through the provider; the aim is an accurate account of the service supplied.

## Follow-up questions

### What if the feature works now, but we cannot establish when it was fixed?

State the earliest verified working time and the gap in the historical record. Check relevant configuration changes, deployments, successful operations, and support messages. Do not use today's successful test as proof that the feature worked throughout the disputed period. Keep an unverified repair date out of the response.

### Can we say the customer never contacted support if no ticket is found?

Describe what was searched and how the account was matched. A customer may have used another email, a sales contact, or an in-product channel. Reconcile any message the customer supplies. An empty result in one inbox supports a narrower statement than “the customer never contacted us.”

## Sources and scope

Sources checked October 2026

Published by Evidenz. Examples are illustrative, not customer results. Check current requirements and the actual case against the linked sources.

- [Adyen: Dispute reason codes and defense requirements](https://docs.adyen.com/risk-management/understanding-disputes/dispute-reason-codes)
- [Stripe: Dispute reason code categories](https://docs.stripe.com/disputes/categories)
- [Intercom: How to manage Customer tickets](https://www.intercom.com/help/en/articles/8300304-how-to-manage-customer-tickets)

Customer context is our starting point.

Evidenz is being built for B2B and B2C SaaS: a shared customer history across subscription billing, accounts, support, and digital product activity. Join the waitlist for early-access news.

[Join the waitlist](https://evidenz.dev/#hero)

## Keep reading

[5 min read

### Digital service not received: choose evidence that shows delivery](https://evidenz.dev/articles/digital-service-not-received)[5 min read

### Chargeback evidence for subscription businesses](https://evidenz.dev/articles/chargeback-evidence)[4 min read

### Accept or contest a chargeback: make the decision from the records](https://evidenz.dev/articles/accept-or-contest-chargeback)[5 min read

### Prepare chargeback evidence files that a reviewer can actually read](https://evidenz.dev/articles/preparing-dispute-evidence-files)

Canonical page: https://evidenz.dev/articles/saas-service-not-as-described