Sókrates Pilot — Onboarding Questionnaire
Authoritative English version. Icelandic mirror: onboarding-questionnaire.is.md.
How this form feeds the pilot SOW. The answers here are the direct inputs to the pilot Statement of Work template (ticket T6.3 / #67 — SOW template lands in a separate ticket; update this link once it ships:
TODO: link to docs/sales/pilot-sow-template.md when T6.3 is merged). Please return this form before the discovery call so we can arrive with the scoping questions already narrowed down.
v1 scope reminder. In v1 we connect exactly two source systems. Please list all candidate systems in section 1 — we will scope the pilot to two together during the discovery call. Everything else in this form should be filled in with those candidates in mind; we would rather see too much than too little.
1. Systems
List every candidate system that might be in-scope for the pilot. We will select two during the discovery call. For v1, typical pairings are one CRM / sales-facing system and one operational system (accounting, service desk, ERP module, etc.).
| # | System name | Vendor | Version / edition | Approx. record count (orders, contacts, tickets — whatever is most meaningful) | Hosted by | Primary business owner |
|---|---|---|---|---|---|---|
| 1 | ||||||
| 2 | ||||||
| 3 | ||||||
| 4 | ||||||
| 5 |
Notes / context on data freshness, known data-quality issues, or in-flight migrations:
Answer:
2. Authentication
For each system listed above, describe how Sókrates will authenticate against it. If the answer is “we do not know yet,” say that — it is a valid answer and tells us where we need to do joint discovery.
| # | System name | Auth method (OAuth2 / API key / DB user / SSO-fronted / other) | Where the credential currently lives (password manager, key vault, email, post-it) | Who has access to that credential today | Rotation cadence (never / ad-hoc / quarterly / other) |
|---|---|---|---|---|---|
| 1 | |||||
| 2 | |||||
| 3 | |||||
| 4 | |||||
| 5 |
Are any of the systems behind an SSO / IdP (Azure AD / Entra, Google Workspace, Okta, other)? If yes, name the IdP and the owner on your side.
Answer:
Is there an existing policy that governs how third-party tools receive credentials to these systems (e.g. security review, vendor onboarding)? If yes, who runs it and what is the expected turnaround?
Answer:
3. Network
Sókrates v1 ships as a GMKtec mini-PC that sits inside your network. It reads customer systems from inside the LAN and reaches a small set of external endpoints over HTTPS. We need to know what your network will and will not allow.
3.1 Outbound (from the Sókrates box out to the internet)
For each endpoint below, check whether outbound HTTPS from the Sókrates box is allowed today. If unknown, check “unknown” — do not guess.
- OpenRouter API (
openrouter.ai) — used for LLM inference routing. Allowed / Blocked / Unknown: - Voyage AI (
api.voyageai.com) — used for text embeddings. Allowed / Blocked / Unknown: - Pydantic Logfire (
logfire-api.pydantic.dev) — used for structured observability. Allowed / Blocked / Unknown: - Anthropic API (
api.anthropic.com) — fallback inference provider. Allowed / Blocked / Unknown: - Sókrates Fleet endpoint (hostname will be provided by us before installation). Allowed / Blocked / Unknown:
If any of the above are Blocked or Unknown, who approves exceptions, and what is the expected lead time?
Answer:
3.2 Inbound (from Sókrates in to the box)
The box runs a local web UI / MCP endpoint on the LAN. End users reach it from inside the office network. We occasionally need to reach it from outside for support.
- Is remote support access acceptable in principle? (VPN / WireGuard tunnel from us into your network, initiated by us only, scoped to the box.) Yes / No / Needs security review:
- If VPN is not acceptable, what is the fallback? (Screen-share session initiated by your side / on-site visit / no remote support at all.)
Answer:
3.3 Proxy / NAT / firewall constraints
- Is there a corporate HTTP(S) proxy the box must route through? Yes / No: If yes, proxy hostname + auth method:
- Is the box going to sit behind NAT on a dedicated VLAN, or on the general office LAN? Answer:
- Any deep-packet-inspection / TLS-intercepting firewall in the path? Yes / No / Unknown:
- Who owns the firewall change process on your side (name + role)? Answer:
4. Priority workflows
Sókrates earns its keep by answering the questions your team wishes were easy to answer today. List the top three questions you most want Sókrates to answer on day one. Concrete beats abstract — “which deals are stuck in finance approval for more than 14 days” beats “a better view of our sales pipeline”.
Workflow 1 — the question:
Answer:
- Systems involved (names from section 1):
- Frequency you would want an answer (on-demand / daily / weekly / monthly):
- Who asks this question today, and how do they answer it today (spreadsheet pull, ask someone, nobody answers it):
Workflow 2 — the question:
Answer:
- Systems involved:
- Frequency:
- Who / how today:
Workflow 3 — the question:
Answer:
- Systems involved:
- Frequency:
- Who / how today:
Anti-patterns — questions you do NOT want Sókrates to touch in v1 (e.g. anything touching payroll, anything customer-facing, anything that would require write-access to a system of record):
Answer:
5. Key users
Sókrates has a small set of named users in v1. For each person expected to use Sókrates — or to be the subject of its reports — fill in a row. Aim for 3–6 people; more than 8 is too many for a v1 pilot.
| Name | Role / title | Seniority (exec / manager / IC) | Preferred channel (Slack / email / WhatsApp / in-person / other) | What kind of question they would bring to Sókrates |
|---|---|---|---|---|
Is there a power user / champion on your side who will own the day-to-day relationship with Sókrates during the pilot? Name + role:
Answer:
6. Communication channels, integrations, and automations
Sókrates can be used through more than one human-facing channel, and can also connect to operational tools through MCP servers or other APIs. For v1, these channels and MCP tools do not automatically expand the “exactly two source systems” scope unless they are also being used as business-data sources. They do, however, affect security review, credentials, deployment effort, and the pilot SOW.
6.1 User-facing communication channels
Which channels should users be able to use to talk to Sókrates during the pilot? Check every candidate and mark the expected v1 status.
| Channel | Required in v1? (yes / no / maybe later) | Workspace / tenant / account | Admin owner | Auth / bot setup owner | Notes on retention, compliance, or message export |
|---|---|---|---|---|---|
| Web UI on LAN | |||||
| Slack | |||||
| Microsoft Teams | |||||
| SMS | |||||
| Telegram | |||||
| Discord | |||||
| Signal | |||||
| Mattermost / Matrix / other self-hosted chat | |||||
| Other |
Are there any channels where Sókrates may read messages but may not send replies? If yes, name the channels and explain the rule.
Answer:
Are there channels where attachments, screenshots, or exported files are expected? If yes, name the channel, expected file types, and any size / data-classification limits.
Answer:
6.2 Email integration
If email is in scope, answer these questions even if email is “just” a notification or support channel rather than one of the two source systems.
- Mailbox type (shared mailbox / individual mailbox / distribution list / alias / other): Answer:
- Provider (Google Workspace / Microsoft 365 / IMAP+SMTP / other): Answer:
- Preferred protocol or API if known (Gmail API, Microsoft Graph, IMAP+SMTP, SMTP-only outbound, other): Answer:
- Allowed email actions (read only / draft replies / send replies / send new outbound mail / forward messages / label or archive): Answer:
- Who approves mailbox access and OAuth scopes / app passwords? Answer:
- Should Sókrates preserve threads when replying? Yes / No / Unknown:
- Any mail retention, eDiscovery, legal hold, DLP, or signature requirements? Answer:
6.3 Social media apps and external messaging services
List any social media or external messaging services where Sókrates is expected to help. Include services that are only “maybe later” so we can avoid designing the pilot in a way that blocks them.
| Service | Desired use (monitor / summarize / draft / publish / DM / escalate / other) | Required in v1? | Official API available? | Credentials owner | Approval required before posting? |
|---|---|---|---|---|---|
| X / Twitter | |||||
| Facebook / Instagram | |||||
| Bluesky / Mastodon | |||||
| TikTok / YouTube | |||||
| Other |
Are there brand, legal, or compliance rules that forbid automated posting or require human review before anything is sent externally?
Answer:
6.4 Workflow automations and triggers
Which automations should Sókrates run during the pilot?
- Scheduled reports (daily / weekly / monthly). Which reports, recipients, and cadence?
- Event-triggered alerts from a source system. Which event and source system?
- Incoming webhook from another tool. Which tool sends it, and what payload shape is expected?
- Outgoing webhook to another tool. Which tool receives it, and what approval is required before sending?
- Ticket / task creation. Which tool, project, queue, or board?
- Calendar or meeting workflow. Which calendar system and permitted actions?
- Home / facility / IoT automation. Which controller and what actions are allowed?
- Other automation. Describe it.
For every automation above, should Sókrates act automatically, propose an action for human approval, or only produce a recommendation?
Answer:
What automations are explicitly out of scope for v1? Include any system where write access, customer-facing messages, payment actions, HR/payroll actions, or legal/compliance workflows are not allowed.
Answer:
6.5 MCP servers and customer tools
MCP servers are a standard way to expose tools and data sources to an agent. If your organization already runs any MCP servers, list them here. If not, use this section to identify the customer systems that would be useful as standard MCP-style tools in the future.
| Candidate MCP server / tool | Business purpose | Existing server? (yes / no) | Read / write / both | Data sensitivity | Auth owner | Network location (LAN / cloud / VPN) |
|---|---|---|---|---|---|---|
| Filesystem / document store | ||||||
| Git provider (GitHub / GitLab / Bitbucket) | ||||||
| Knowledge base (Confluence / Notion / SharePoint / Google Drive) | ||||||
| Ticketing / service desk / project tracker (Jira / Linear / Zendesk / ServiceNow) | ||||||
| Email / calendar (Google Workspace / Microsoft 365) | ||||||
| Database / warehouse (Postgres / SQL Server / Snowflake / BigQuery / DuckDB / other) | ||||||
| CRM / customer system (Salesforce / HubSpot / internal / other) | ||||||
| Observability / logs (Datadog / Grafana / Sentry / CloudWatch / other) | ||||||
| Internal API / custom tool | ||||||
| Other |
For any MCP server or tool with write access, who is the named approval owner and what actions are allowed without additional approval?
Answer:
Are there customer systems that must never be exposed through MCP or agent tools, even read-only?
Answer:
7. Support channel
How should our two teams talk during the pilot? We prefer a single primary channel with one documented backup.
- Primary support channel (Slack shared channel / shared email alias / phone / other): Answer:
- Backup channel (must be different from primary): Answer:
- Hours of coverage you expect from us (e.g. business hours Europe/Reykjavik, 24/7, follow-the-sun): Answer:
- Hours of coverage you can provide on your side for responding to our questions: Answer:
- Escalation owner on your side — the named human we escalate to if primary + backup both go silent (name + role + reachable number): Answer:
- Expected response time for non-urgent questions (hours / same business day / next business day): Answer:
- Expected response time for production-down incidents: Answer:
8. Approval owners (write actions)
Sókrates has two v1 workflows that propose actions rather than just answering questions:
- Curator tool — proposes edits to the unified operational graph (e.g. “these two customer records in CRM and accounting are the same entity; merge them in the Sókrates map”). The edit only lands on approval.
- Proactive weekly report — surfaces patterns and, where appropriate, suggests follow-up actions for a human to take (e.g. “these three deals have been in finance approval >14 days; consider escalating”). The report is informational; any action the report suggests is taken by a human in the source system.
Neither of these auto-writes to your source systems. They do, however, need a named human approver on your side.
-
Approver for curator graph edits (name + role + preferred channel for approvals):
Answer:
-
Backup approver for curator graph edits (so we are not blocked if the primary is on holiday):
Answer:
-
Recipient of the weekly proactive report (name + role + channel):
Answer:
-
Action owner for anything the weekly report suggests — the person accountable for deciding whether to act on the report’s suggestions (name + role):
Answer:
-
Named human, not a role or team. If you are tempted to write “ops” or “the finance team” — please nominate a specific person. We can always add a backup; we cannot work with an unnamed queue.
How to use this form
The Sókrates team shares this form with the prospect before the discovery call; returned answers feed directly into the pilot SOW template (T6.3 / #67 — link to be added once merged). Anything you cannot answer yet is fine — mark it TODO and we will work it out together on the call. Return the form to the email address or shared channel provided in the original invitation; if you do not have one, reply to whichever Sókrates contact sent this to you.