Free POC
Test on your real data, in your real processes. 361 connects as a separate layer on top of your existing systems; if you stop, the connections are removed and your systems keep running exactly as before.
How You Start
3 Easy Steps
Where Should You Start?
6 AI Entry Scenarios
Concrete AI scenarios you can test in your POC.
Say "Show this month's sales by department."
AI prepares the report instantly.
An order email arrives, AI creates a record automatically.
Triggers the approval flow, notifies you.
Unusual spending, fraud, or stock deviation.
AI alerts instantly and suggests action.
Invoices, contracts, PDFs — AI reads and enters them into the system.
Performs automatic validation and matching.
Sales forecasting, churn risk, demand planning.
Predict the future from past data.
Approval flows, notifications, escalations.
Start immediately with 20+ ready-made workflow templates.
Your Custom
2-Week Roadmap
Choose your industry, simulate the POC process.
Why
Free POC
Discover the value AI will bring to your business without taking any risk.
No schema or version changes to your existing system.
If you don't continue, the connection is removed and your system stays the same.
Not projects that take months.
A working AI solution in 2 weeks.
Not demo data — your own data.
Tested on your real business processes.
Measurable business value report.
Concrete data to help you decide.
The POC Is Free.
It Is Not Effortless.
You are not invoiced. In exchange, the POC needs your time, your access approvals and two decisions. We list them up front so the calendar does not stall halfway through.
Four roles, named before kickoff
- Process owner — whoever runs the in-scope work today. They supply the current baseline figure.
- Decision maker — the person who will call continue or stop at the end, and who signs off the success criteria.
- IT / security contact — the person who can act on network, identity and access requests.
- Everyday users of the process — the team that will run the flow inside their real work. The measurement comes from their usage.
Read access and a role map
Read access to the systems in scope is required. Database tools are read-only by design: SELECT, WITH, SHOW, DESCRIBE and EXPLAIN are allowed, while write and schema commands are blocked. If you prefer, a read-only lock can stay on for the whole evaluation — while it is engaged every modifying operation is rejected before it is sent.
A user list and role map is equally necessary, because the AI runs inside the permission context of the user who asked. Without role definitions, field-level filtering by role cannot be configured either.
Details: IT Review Pack.
Real data, and the fields you close off
- The POC runs on real data. A POC on demo data produces a demo measurement.
- The list of sensitive fields to hide from the AI comes from you. With role-aware field filtering, a closed field is never passed to the model at all.
- You choose which documents go into the knowledge base — and you confirm they are current. Load an outdated procedure and the AI will faithfully explain the outdated procedure.
- Your retention preference: out-of-the-box defaults are 90 days for general data, 30 days for conversation history and 90 days for logs, all configurable to your policy.
Depends on the deployment model
- SaaS — no server is needed on your side. If an internal system has to be reached, a secure path (VPN or a published endpoint) is required.
- Private cloud / on-premise — Windows Server 2019 or later, or Windows 10/11, with .NET Framework 4.8. Minimum 16 GB RAM and 8 CPU cores; 32 GB+ RAM and a CUDA-capable NVIDIA GPU are recommended for quality models and heavy document/OCR pipelines.
- Air-gapped — the local model is the only AI path, so hardware is not optional here. You also need extra disk space for model files and a defined transfer procedure for update packages.
The limits of all four: Deployment Models.
Three calls to make before kickoff
- Deployment model: SaaS, private cloud, on-premise or air-gapped.
- Model policy: whether cloud AI providers are enabled, or
localOnlykeeps everything on local models. With localOnly on, cloud models are not even listed and are categorically refused if requested. - Scope: the single process entering the POC. Picking two processes means halving two weeks; we advise against it.
Your own privacy process
On the platform side, role-based access control, row-level security, personal-data masking and an immutable audit trail come as standard. What stays with you is your organisation's own notice and consent process covering the users and data entering the POC — we cannot run that on your behalf.
If you have a security questionnaire, send it before kickoff. We answer each item at architecture level and explicitly mark the items we have no answer for. See the Trust Center.
Being honest about it: this list could be made shorter, but not more accurate. In enterprise POCs most delays come from pending access approvals rather than from the product. If the items above are ready, two weeks really is two weeks; if they are not, the calendar tracks the speed of your approvals.
Two Weeks
Stage by Stage
Every stage has an output, and no stage starts before the previous output exists. How long each stage takes depends on your deployment model and the speed of your access approvals — what is fixed is the order, not a day count.
-
0Before kickoff · Discovery
Scope, criteria and deployment model are written down
Which process, which data source, which users, what counts as success and what today's baseline is — all on one page. The deployment model and model policy (cloud providers or local only) are settled here too.
Output: a written scope and success-criteria note both sides have signed off.
-
1Week 1 · Connection
The environment comes up and connections are made
The POC environment is installed per the chosen deployment model. Users and roles are defined, read access to the data source is connected, and fields hidden from the AI are filtered per role. Nothing in your existing systems changes at schema or version level — 361 attaches as a separate layer on top.
Output: a reachable POC environment plus a connection inventory showing which system was reached with which privileges.
-
2Week 1 · First working flow
The chosen scenario runs end to end on real data
The in-scope scenario is built and run against your own data from start to finish. Governance is configured in the same stage: guardrail detectors (personal data, hallucination, prompt injection, cost), which tools drop to human approval, and the approval policy itself.
Output: a working flow plus a written guardrail and approval configuration.
-
3Week 2 · Measurement
Real users run the flow inside their real work
The measurement comes from real usage, not a demo session. The platform's own record is collected: agent run traces (steps, duration, tokens), operation logs, the audit trail, guardrail violations and cost records. If you want, traces and metrics stream into your existing observability stack over OpenTelemetry.
Output: raw measurement data pulled from the records agreed in the criteria.
-
4Week 2 · Review and decision
Was the criterion met — the answer is written down
Each criterion written at the start is walked through: if met, which record it was read from; if not met, why not. The deployment model, the measured usage units and the limits encountered are summarised in the same review. The decision is yours.
Output: a review presentation plus the measurement data needed for the continue-or-stop decision.
For two weeks the environment is yours: you can log in and look whenever you want — no need to wait for the closing review. By the end you will also know which deployment model fits you, seen in your own network rather than argued in theory — the limits of each model are here.
At the End of Two Weeks
What You Actually Get
The list of what is not delivered matters as much as the list of what is. Both are below.
A working POC environment
The in-scope scenario, running on your own data. In on-premise and private-cloud deployments the environment sits inside your own boundary; once installation is done, running the platform does not depend on us.
Configuration at definition level
The agent and automation definitions built, the role and permission mapping, the guardrail and approval policy, and the data-source connection definitions. All of it persists as configuration — if you continue, nothing is rebuilt from scratch.
A measurement report from the platform's own record
What the criteria written at kickoff came out as, and where each figure was read from. The source is the runtime record itself: agent run traces (steps, duration, tokens), operation logs, the audit trail and guardrail violations. Records, not a survey.
What connected to what, and how
The deployment model chosen, the connections made, the path your data took, which workloads ran on the local model versus a cloud model, and which limits were hit during the two weeks. Written to drop straight into your IT team's evaluation file.
Measured units that feed the commercial offer
User count, storage, record volume, AI token consumption and API calls — measured during the POC rather than estimated. The offer is built on those units, and the caps are set together with you. See Pricing.
Everything produced is exportable
Records and reports created during the POC export as CSV, Excel, JSON and XML; analysis output comes out as Excel, presentation and PDF. Your schema is readable through the core API and the relationship graph exports as JSON-LD. Details: Your Data Is Yours.
What the POC does not finish
- It is not a production rollout. Scope is one process and one scenario; opening the full module portfolio is outside the POC.
- No load or resilience testing. Recovery targets (RPO/RTO) are measured during the POC, but the commitment is given in writing in the service agreement — the POC output is not a commitment document.
- No migration of your existing systems. 361 attaches as a separate layer; no schema or version change is made in your existing ERP or business systems.
- No source code hand-over. What you receive is working configuration and exportable data.
- No audit or certification report. Management-system certificates are published in the Trust Center; the POC does not substitute for them.
- Pricing is not a POC output. The offer is prepared separately, once the measured units are known.
What stays with you if you stop
- The measurement report and the review presentation.
- The architecture note — including what you learned about your own environment.
- The exported copies of every report and analysis produced during the POC.
- A tested answer to which deployment model fits your organisation, seen in your own network.
Written at the Start
Not Argued at the End
Whether the POC succeeded is not settled by debate two weeks later. The criteria are written before kickoff and approved by both sides.
A criterion has three parts
- What is measured — which quantity in the process.
- Where it is read from — which record: an agent run trace, an operation log, the audit trail, or a field in your existing system.
- At what threshold it counts as met — a threshold you set, relative to your own baseline.
If one of the three is missing, the sentence is an aspiration rather than a criterion, and we do not write it as one.
We do not set the threshold
The comparison point is your organisation's number today — how many people, how long, and at what error rate the work runs right now. The process owner supplies it. We do not invent an industry-average figure and build a promise on top of it.
If today's number is not known yet, establishing it together is the output of the discovery stage.
Read from records, not impressions
Measurement comes from records the runtime already keeps: the step count, duration and token consumption of every run; what was asked, what came back and what it cost for every AI operation; guardrail violations and approval decisions.
These records are part of the runtime rather than a report bolted on afterwards, so no extra instrumentation work is needed. Details: IT Review Pack.
What we refuse to write as a criterion
- Unmeasurable statements such as "users were happy".
- Improvement expectations outside the process actually in scope.
- Criteria built on a capability your deployment model does not allow — for example a cloud-model comparison on a network with no outbound access.
- Quantities whose cycle is too long to observe in two weeks; those belong to the stage after the continue decision, not to the POC.
What if the criterion is not met? The report says "not met". The point of the POC is not to sell but to make the decision cheap: after two weeks you hold either a working flow or a concrete explanation of why this does not work on your data. Both are usable for a decision. Uncertainty is not.
Before the POC
Preparation Checklist
To walk through with your internal team before applying. Print it into your evaluation file — there is no file to download; the page itself is built to print.
A · Decision and scope
- Process owner and decision maker named.
- The single process entering the POC selected.
- Today's baseline for that process captured (duration, headcount, error rate, volume).
- Success criteria drafted with all three parts: what is measured, where it is read from, at what threshold it counts as met.
- Deployment model preference discussed: SaaS, private cloud, on-premise or air-gapped (comparison).
- Attendees and calendars for the closing review agreed.
B · Security and compliance
- IT / information security contact assigned and briefed on the POC.
- Your security questionnaire compared against the IT Review Pack; unanswered items flagged.
- Model policy decided: cloud AI providers enabled, or
localOnlywith local models only. - Outbound (egress) policy reviewed; if cloud models or external channels will be used, the approval path identified.
- Decision taken on whether the read-only lock stays engaged for the evaluation.
- Your privacy notice and consent process checked for coverage of the POC users and data (privacy policy).
- Incident notification contact and channel agreed (Trust Center).
C · Data preparation
- Systems to be connected listed, and the owner of the read access identified.
- Sensitive fields to hide from the AI (for example payroll and HR fields) listed per role.
- Documents for the knowledge base selected and confirmed to be current.
- User list and role map produced, stating which role may see which data.
- Use of real rather than test data confirmed.
- Retention preference set (defaults: 90 days general data, 30 days conversation history, 90 days logs).
- Export expectations clarified — which outputs are needed in which format (Your Data Is Yours).
D · Environment and access
- Environment prepared per deployment model: Windows Server 2019+ or Windows 10/11, .NET Framework 4.8.
- Hardware profile confirmed: minimum 16 GB RAM and 8 CPU cores; 32 GB+ RAM and a CUDA-capable NVIDIA GPU for quality models.
- If SaaS and an internal system must be reached, the secure path (VPN or published endpoint) planned.
- Identity integration or user provisioning method decided.
- If air-gapped: extra disk space allocated for model files and a transfer procedure defined for update packages.
- Confirmed internally that the server side runs on Windows — if your operating policy allows Linux only, settle this item first.
E · Measurement and reporting
- Agreement reached on the records the measurement will be read from: agent run traces, operation logs, audit trail.
- Accepted that token and cost caps plus alert thresholds will be configured during the POC.
- Decision taken on whether to stream into your existing observability stack over OpenTelemetry.
- Owner assigned for the human approval queue on risky tool calls.
- Team has discussed that the report may say "not met" — and that this is an acceptable outcome.
F · Final look before applying
- Any unticked item in A–E has an owner.
- For gaps that do not block kickoff, it is written down which ones close during week 1.
- The time the process owner and users can commit across two weeks is confirmed.
- Your own security checklist, if you have one, prepared to attach to the application.
An item you cannot answer yet is not a reason to postpone. Note it in the application and we will fill it in together during discovery. The list exists so nothing surprises you after the POC has started.
Apply
Now
What Happens
After the POC?
No sales pressure. The decision is entirely yours.
Monthly license + the AI Solutions you choose.
Gradual expansion at your own pace.
The connections are removed and the POC environment is shut down.
Your existing systems keep running exactly as they did before the POC.
All reports and analyses produced during the POC are yours to keep.
Evaluation report on us.
After the POC, the decision is yours.
No sales pressure, no coercion.
What technically happens if you stop: the connections that were built are removed and the POC environment is shut down; your existing business systems keep running as before, because no schema or version change was made in them during the POC. Before the environment closes you export your data as CSV, Excel, JSON and XML. If you request deletion of what remains, a 30-day cooling-off period runs; after it, deterministic anonymisation is applied and sensitive fields in the audit records are masked. Details: Your Data Is Yours.