> For the complete documentation index, see [llms.txt](https://docs.solcis.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.solcis.ai/partners/sell/qualifying-an-opportunity.md). # Qualifying an opportunity Check fit, urgency and buying readiness before you register an opportunity. A qualified opportunity has a clear business need, someone accountable for it, and an active buying process. Work through the questions below with the customer. Then record the answers before you register the opportunity with Solcis. The questions do three different jobs: * **Questions 1 and 2 are hard gates.** They test whether Solcis can work at all. They follow from how Solcis is built, not from its feature list, so the answers do not change between releases. Ask them first. A customer who fails one of them now will fail it in month six too. * **Questions 3 and 4 shape the deal.** They tell you whether advisory work comes first, and whether you are the only option or one of several. * **Questions 5 and 6 test buying readiness.** Is there a reason to act now, and someone who owns the decision? ## Questions to qualify the opportunity {% stepper %} {% step %} ### Will Solcis run in your own environment, operated by your team or a partner? Both Solcis products, Policy Studio and the Policy Engine, are software that runs in the customer's environment. Solcis does not host a version for customers. We are not a software as a service (SaaS) vendor. **Good answer:** they already run their own workloads in their own cloud, data centre or air-gapped network, and their policy restricts hosted software. **Partner-operated:** they have no platform or infrastructure team to run it. You, or another partner, can operate it for them as a managed service, on their infrastructure or yours. **Walk away:** they want a service that a vendor hosts and runs. See *Why Solcis › Who is it for*. {% endstep %} {% step %} ### Do your AI systems take actions, or only produce text? "AI systems" means the AI-powered software, agents and models the customer runs. The Solcis Policy Engine sits in the path of each action an AI system attempts, and decides it before it goes ahead. The value is in those decisions, so there must be actions to decide. **Good answer:** agents that write to systems of record, move money, grant access, change configuration or contact customers. **Not yet:** an assistant that only summarises or drafts, where a person carries out every action. Solcis can check its model requests and outputs, but there is little to decide. Treat it as early stage, and come back when the customer plans agents that act. {% endstep %} {% step %} ### Whose controls will Solcis enforce, and do they exist today? Solcis enforces the customer's own controls. It does not make anyone compliant with anything. It extends an existing governance, risk and compliance (GRC) programme to AI systems; it does not replace one. Out-of-the-box control sets give a starting point for common security and AI frameworks, but the customer must still adopt and own them. **Good answer:** a control library, framework mappings and an internal audit function are already in place. **Advisory first:** they expect the vendor to supply the controls. That is an advisory engagement before Solcis, and often one you can deliver. {% endstep %} {% step %} ### Can your AI systems' prompts and tool calls leave your environment? This question decides whether Solcis is the only option or one of several. **Strong position:** no. Regulation, policy or data classification prevents it, so every hosted alternative is ruled out before the evaluation starts. **Expect competition:** nothing limits where checks run. A hosted product may suit them, and you are in a feature comparison. See *Why Solcis › How Solcis compares*. {% endstep %} {% step %} ### Who is accountable if an AI system does something it shouldn't? Ask for a name. Accountability for what AI systems do is what creates the budget. **Good answer:** a CISO or chief risk officer, or a board that has asked the question and not had an answer. **Not yet a deal:** no one can be named. Without an accountable owner there is no economic buyer, and the work stays an experiment in the platform team. {% endstep %} {% step %} ### What is blocked, or already running without oversight, until you have a risk answer? Most customers are in one of two positions: * **Blocked:** agents they cannot deploy, and a backlog waiting on a risk question nobody can answer. * **Unsupervised:** agents already in production with no record of what they do or whether it complies. Either way, the missing risk answer creates the urgency, and usually the business case. **Good answer:** named use cases on hold, with a date or a cost attached to the delay; or live agents with no visibility of their actions and no evidence to show. A regulatory or board driver also counts. Record the driver the customer names. Whether it applies to them is for their compliance function to confirm, not us. **No urgency yet:** nothing is blocked, nothing is live and nothing is planned. Without a reason to act, the opportunity will stall in evaluation. {% endstep %} {% endstepper %} ## Questions to scope the opportunity These questions do not decide whether to pursue the opportunity. They shape the solution, the delivery scope and your role. Ask them before you propose anything. | Ask | Why it matters | | ----------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | How will the customer connect their AI systems, and how much coverage do they need? | The Policy Engine decides actions at model, tool and MCP endpoints. There are four ways to put it in the path, and most customers combine them. **An existing gateway:** if the customer already runs Kong AI Gateway, Docker MCP Gateway or IBM ContextForge, a Solcis plugin or interceptor asks the Policy Engine to decide each call, with no application change. **Solcis resource gateways:** MCP, REST and model gateways govern calls to MCP servers, REST APIs and AI models, also with no application change. **The Solcis SDK** (Node, .NET and Python) builds checks into the agent: before model calls, before tool calls and on output. It gives deeper coverage and richer context, and it fails closed: if it cannot get a decision, the action does not go ahead. **Other policy engines:** where the customer runs NVIDIA OpenShell, Microsoft Agent Governance Toolkit (AGT), OPA or Cedar, Policy Studio writes policies in that engine's format, deploys them, and brings the engine's decisions into Solcis coverage and evidence. Most customers start with a gateway for broad coverage and add the SDK where they need depth. The answer sets the integration effort, the second-phase scope, and which engineering teams you need to involve. | | Which agents and tools will stay outside the enforcement path? | Anything not connected is not checked and not recorded. Agent discovery finds AI agents and machines Solcis has no record of, so use it to name the gaps early. Naming a gap early avoids an argument about coverage later, and it is usually second-phase scope. | | Who must verify the evidence independently, and what will they ask for? | Internal audit, an assurance firm or a regulator. Every decision the Policy Engine makes gets a signed receipt and an entry in its tamper-evident evidence ledger. Anyone can check the ledger with the offline verifier, without trusting the people who run the system. For that check to be independent, keep checkpoints or receipts somewhere the engine's operators cannot change them; plan this into delivery. The optional transparency log adds witnessed proofs, but not in an air-gapped deployment. If someone must check the record independently, the evidence ledger is the deciding feature rather than a nice-to-have. | | How will controls get into Policy Studio, and does evidence need to go back? | Policy Studio syncs controls and frameworks from 6clicks and ServiceNow. It also imports them from OSCAL catalogues, spreadsheets or written control documents. For other GRC platforms, such as Vanta, Drata or Archer, use OSCAL or spreadsheet import. Policy Studio can send decision evidence back to the customer's GRC platform; in 6clicks it is recorded as continuous control monitoring results. Confirm which way evidence must flow, because it decides the integration work. | | Which regulation or framework is driving this, and who owns the control library? | Each control keeps a link to the requirement it satisfies. The answer names your compliance contact and the language the business case must be written in. | | Which model will run the AI checks, and where? | AI checks use a small language model that the customer runs on their own hardware. They choose one from the Solcis model catalogue in Policy Studio, or point the checks at a model server they already run. Model Deployer installs and serves catalogue models on the customer's machines. Some catalogue models run without a GPU, but most need one, so include this in sizing. AI checks can only block an action or escalate it to a person; they never allow an action on their own. Ask early whether procurement restricts where a model comes from. Several catalogue models are built on Qwen base models from Alibaba. IBM Granite Guardian is the alternative, but it is a weaker judge and needs larger hardware. | | Where will it run, how many environments, and who operates it after go-live? | Both products run on Linux hosts in any cloud or data centre the customer operates, connected or air-gapped. Install with Docker Compose, with Helm charts on Kubernetes, or from Azure Marketplace into the customer's own AKS cluster. Policy engines can also run as a system service without containers, including on Windows hosts. Confirm where it will run: an air-gapped requirement shapes the deployment and rules out every hosted alternative. Production, test and air-gapped environments set the size of the deployment. The operating answer decides whether the work ends as a handover or becomes a managed service you deliver. | | How will the customer buy and evaluate? | Find out who signs, which procurement rules apply (for example, sovereign-vendor or model-origin rules), and whether another product is already in place. Agree with the Solcis team how the customer will evaluate before you offer a proof of concept. Tell us the customer's country early: export rules can apply in some jurisdictions, and we confirm them before you quote. | ## Decide whether to register Register the opportunity when: * questions 1 and 2 have a good answer, or a partner-operated answer to question 1; * the customer has its own controls, or has agreed to an advisory engagement first (question 3); * an accountable owner is named (question 5); and * there is a driver with a date or a cost (question 6). Question 4 does not decide whether to register. It tells you how to position the opportunity. {% hint style="info" %} Early-stage opportunities are welcome when the next discovery step is clear. Record what you know, and what you will confirm next. {% endhint %} Do not register a lead without a customer conversation, a defined use case or a realistic next step. ## Prepare the handoff Include these details when you submit the opportunity: * Customer name, industry, country and main contact. * The answer to each of the six qualifying questions, with what supports it (for example, a named owner, or a blocked use case and its cost). * Business challenge, desired outcome and proposed Solcis use case. * Stakeholders, estimated value, target timeline and next meeting. * Your proposed role: advisory, deployment, integration, managed service, or a mix. Keep the record up to date as the opportunity progresses. Involve the Solcis team early if you need help with discovery, solution design or account planning. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.solcis.ai/partners/sell/qualifying-an-opportunity.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.