Playbook, SaaS company

Will it work with what we already have

This looks like a technical question and frequently is not. A large share of it is somebody discovering that the capability exists and is only sold on a higher tier, which is a pricing answer wearing technical clothes. The rest splits into what the buyer's security team will insist on, and a supported browser list that has an end date on it.

Why this is not the general answer

The handling pattern for compatibility questions holds across every trade. What follows is the part that does not.

  • Much of this is not compatibility at all: the capability exists, it is gated to a tier, and the answer lives on the pricing page rather than in any technical document.
  • Buyers ask about sign in and automated provisioning before anything else, because that is the part their own security team will refuse, and a vague answer stalls an evaluation without anybody telling you.
  • Calling something supported is a commitment that gets forwarded internally and quoted in a decision, so a hedged maybe is more expensive here than a plain no.
  • Browser and device support is a tested list with versions on it, and the honest answer names what was tested rather than what usually works.

How it arrives

  • does it work with our single sign on
  • can we provision users automatically from our directory
  • which browser versions are actually tested
  • does it connect to the other tools we use
  • are the integrations included on the starter plan
  • does any of it work offline

What has to be indexed for this to work

Material behind this answer
Supported sign in and provisioning, with the tier against eachWhich standards you support, which plans they are sold on, and what an administrator has to configure. Two facts in one line, because the answer is useless to a buyer without the tier attached to it.
The browser and device support list, with versionsWhich versions are tested, what happens on older ones, and when support for a version ends. Vague wording here produces an evaluation on an untested browser and a defect report you cannot act on.
The published connector list, and what each one actually movesNot the logo wall, the behaviour: which direction data travels, how often, and what is not covered. Buyers assume any named connection is complete, and the gap between the name and the behaviour is where the disappointment lives.
The plan feature matrixThe single document that resolves most of this pair, because so many compatibility questions are really availability questions. Keep it as the live page rather than an export, since a retired tier quoted in an evaluation is a difficult thing to withdraw.

The reply

A reply worth copying
Company sign in and automated provisioning are both supported, and the plans they are available on are listed against them on the pricing page rather than being included everywhere [1]. The browser list gives the versions that are tested, and anything older than those is not covered even where it appears to work [2]. For connections to other tools, the published list says which ones exist and what each actually moves, and I should not guess beyond it. If the tool you need is not on that list, leave your name and work email and the team will tell you where it stands.

It answers the tier question inside the compatibility answer, because that is the fact the buyer has to take back to their own approvals. Saying older browsers are not covered even when they appear to work prevents an evaluation on an untested setup. And it refuses to speculate about connectors rather than offering an encouraging maybe, which is the sentence that gets forwarded.

Where it stops

The trigger. The visitor names an internal system, a bespoke setup or a tool that is not on the published list and asks whether it will work.

The handover, worded
I can only speak to what is on our published support and connector lists, and I cannot assess a setup I have not been told about. Leave your name, your work email and what you need it to work with, and somebody who can answer properly will come back to you.

It stops answering before it guesses, says who will pick it up, and asks for the one thing that makes a reply possible. Nothing about it reads as a dead end.

Never say this here

Out of bounds

  • Never say a connector, standard or platform is supported unless the published list names it.
  • Never say something is planned, on the roadmap or coming soon.
  • Never say an untested or retired browser version will probably be fine.
  • Never confirm compatibility with a system the visitor has described but you have not published support for.

Questions

Why do so many of these turn into pricing answers?
Because gating is invisible from the outside. A buyer reading a feature page has no way to tell whether something is missing or merely sold higher up, so they ask the technical question. Publishing the tier alongside the capability closes both halves at once.
Can it tell a buyer whether we would build a connector they need?
No, and it should not soften that. Anything that sounds like a commitment about future work becomes a line in somebody's evaluation document, and you will be asked about it at renewal.
Should the connector list live on our site or be uploaded?
On the site. It changes more often than almost anything else you publish, and an uploaded copy keeps naming connections after they have been withdrawn, which is a worse failure than not answering.

Keep reading

Try it on your own material

Upload a document or point it at your site, paste one line of HTML, then ask it something only your business could answer.