Talk to a person

Use the routes above to reach the team about plans, support, partnerships, or a security concern. Existing customers can open a ticket through the support desk inside the application. A clear first message helps connect your question with the relevant account and workflow. Include enough context to explain the problem, while keeping passwords, payment credentials, access tokens, and unrelated client information out of the message.

If you are still evaluating the product, describe the task you need to complete and the requirement that remains unclear. The feature, integration, pricing, and security pages answer different parts of that evaluation. Reference the relevant page so the team can address the exact gap rather than repeat a general overview.

For a plan discussion, share your client count, team size, service mix, and essential capabilities. For a support problem, share the steps, expected result, observed result, and relevant account context. For a partnership, explain the proposed relationship and audience. For a security issue, use the private reporting route and provide safe reproduction details. These are different conversations, and a precise subject helps make your intent clear.

You do not need a polished specification to ask a question. A short description of the real task is enough to begin. If a deadline affects your decision, explain it, but do not assume a response time or custom service commitment that has not been agreed. Keep the conversation focused on what you need to know next.

The pricing page covers plan differences, credits, and trial information. The integration directory explains automatic and guided access, supported roles, and reporting coverage. The download pages show current application availability and published files. The security and policy pages cover permission purposes and data-related information. Using the page relevant to your question can save a round of clarification.

If the published information appears inconsistent, tell the team which pages or statements differ. Include the link and the point that affects your decision. Do not fill the gap with an assumption about an undocumented feature, a future launch, or a custom contract. A specific question makes the answer easier to verify and useful to your agency’s planning.

Begin with the task you were trying to complete, then describe the steps in order. Include what you expected to happen and what happened instead. Mention the page or feature, the approximate time with your time zone, and whether the problem happens consistently. If it concerns a connected provider, identify the platform and the relevant asset without sending credentials. This helps the team investigate the same situation rather than guessing from a short message such as 'the report is broken'.

Add a screenshot only when it clarifies the behaviour, and remove unnecessary personal information or unrelated client records. Error text can often be copied into the message. Tell support whether the issue prevents work, affects one client, or has a workable temporary alternative. Do not repeatedly rerun a credit-consuming action simply to gather examples unless that investigation is appropriate. Keep related replies in the same conversation where possible, and explain any change you make during troubleshooting so the evidence remains understandable. A concise, complete report is usually more useful than many fragmented messages sent without context.

Describe the agency you are planning for: current and expected client count, team size, service mix, and the features essential to delivery. Include the research cadence if scans and audits form a significant part of the work. Distinguish an immediate need from a future possibility. If a contract, procurement condition, or payment arrangement matters, name it explicitly. This gives the team a concrete basis for discussing a plan instead of asking you to reconstruct the same information over several replies.

For a partnership enquiry, explain the audience, proposed relationship, and the practical outcome you want. A referral programme, an integration request, and an enterprise deployment are different conversations. Reference the relevant public page and identify the question it leaves unanswered. Avoid promising your own customers an unconfirmed capability or launch date while the discussion is open. A productive first exchange should clarify the requirement, the available information, and the next decision. It does not need confidential client exports, passwords, or payment credentials to establish whether there is a useful conversation to have.

A feature request is easier to assess when it starts with the person doing the work. Describe their role, the information they already have, and the output they need. Identify the point where the current process fails or becomes unnecessarily repetitive. Include frequency and impact: a task performed for every new client is different from an unusual exception. If another tool currently fills the gap, describe the handoff rather than simply asking for that product to be copied.

State whether the requirement blocks adoption, prevents an existing task, or would improve convenience. You can suggest an interface, but keep the underlying outcome clear so the team can discuss other supported approaches. A sanitised example often provides enough detail; passwords, access tokens, and whole client exports are not appropriate evidence for an ordinary feature request. Reference the relevant page if the published workflow led to a different expectation. Keep any response about possibilities separate from a confirmed delivery commitment. Your agency should continue planning around verified capabilities until a change is actually available. This makes the conversation useful without creating accidental promises to your own clients.

If a procurement reviewer has a questionnaire, provide the actual questions and identify the requirements that affect approval. Reference the security, privacy, processing, or subprocessors page where a published answer exists, then explain the remaining gap. For example, a need for a particular assurance report is different from a question about a provider permission. Naming the precise item helps the team respond to the requirement instead of offering a general product overview.

Include your organisation’s contact and the relevant decision date. Keep confidential client records out of the request unless they are genuinely necessary and an appropriate method has been agreed. Do not infer a certification or custom contractual term from a general control description. After receiving a response, check whether it answers the reviewer’s original question and preserve the answer with its context. If another team needs to review it, make the remaining uncertainty clear. This keeps the procurement conversation factual and reduces the chance that an informal explanation is repeated internally as a broader commitment. It also distinguishes questions about Agency Pilot from the access and configuration responsibilities your own agency must manage.

If a purchasing decision depends on an answer, state the exact behaviour you need to confirm. For example, name the provider and permission required for onboarding, describe the report a client must receive, or identify the operating system your team uses. Include the relevant public page and the detail that remains unclear. Distinguish a requirement from a preferred way of implementing it. This helps the conversation stay open to an existing supported workflow while making the outcome you need unmistakable.

Explain the impact of the answer. A requirement may block adoption, affect the plan you choose, or simply influence training. If a deadline exists, give the actual date and its reason rather than assuming a response commitment. Keep any unanswered point visible in your own evaluation record until you receive a clear response. Do not convert an informal discussion of possibilities into a promise to your client. Once the team answers, check that the response addresses the original task and ask a focused follow-up if it does not. This approach gives both sides a concrete question to resolve and prevents a long conversation from ending with different assumptions about what was confirmed.