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

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. 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 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. Check the applicable reason-specific requirements. The table below is an internal review aid, not a universal submission form.

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. 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 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 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.”