Questions
Clear answers about Opynex, our operating model, technology choices, security approach, ownership, commercial structure, and enterprise procurement.
Opynex is an operational automation and intelligence company.
We identify operational friction inside businesses, redesign the processes behind it, and build systems that automate repetitive execution across teams, tools and business functions.
Our focus isn't automation for its own sake.
Our focus is the business outcome the automation creates.
Not in the conventional sense.
AI may be one component of an Opynex system, but we don't begin by asking where we can add AI.
We begin with the operation.
We identify where information stops moving, where people repeat predictable work, where systems don't communicate, where approvals create unnecessary delay and where operational capacity is being consumed unnecessarily.
Then we determine the appropriate architecture.
Sometimes that includes AI.
Sometimes deterministic automation is safer and better.
Often it includes both.
It means designing predictable business processes so they do not depend on someone remembering every next step.
Systems should handle repetitive execution.
People should handle judgment, strategy, relationships and exceptions.
The goal is not to remove humans from the company.
It is to remove unnecessary human dependency from predictable operations.
We start by understanding the operation before proposing technology.
A typical engagement follows five stages:
Diagnose → Identify → Architect → Implement → Operate
We examine the relevant process, systems, handoffs, decision points and bottlenecks.
We then determine which problems should be automated, which should be redesigned and which should remain human-controlled.
No.
In many cases, that's precisely the problem Opynex helps solve.
A company may know that onboarding takes too long, reporting consumes too many hours or departments are constantly coordinating manually without knowing what the technical solution should be.
You bring us the operation.
We help identify what should change.
Depending on the engagement, yes.
An operational discovery or assessment can be used to understand the process, identify friction and determine whether a larger implementation is justified.
The scope and commercial terms of any assessment are agreed before work begins.
No.
n8n may be used where it is appropriate, but Opynex is not defined by a single automation platform.
Architecture is selected according to the customer's requirements, infrastructure, risk profile, integration needs and operational objectives.
The objective is not to force your company into our preferred tool.
The objective is to build the appropriate operating system around your business.
Usually, no.
A major part of the Opynex proposition is making existing systems work together more effectively.
Depending on the environment, we can design integrations around CRM, ERP, finance, commerce, communications, support, productivity, database, API and other business systems.
Where replacement of an existing system would materially improve the architecture, we can identify that during discovery rather than assuming it from the beginning.
Potentially.
This depends on whether the system provides an appropriate API, database interface, webhook, export mechanism or other technically viable integration method.
We evaluate feasibility during discovery.
No.
AI is valuable when the process requires interpretation, classification, extraction, summarisation or other forms of probabilistic intelligence.
It is unnecessary—and sometimes inappropriate—for deterministic business rules.
We use the appropriate mechanism for the operation rather than inserting AI simply to call a system “AI-powered.”
Technically, many decisions can be automated.
That does not mean they should be.
Opynex architectures can incorporate human approval, confidence thresholds, deterministic validation, restricted actions and escalation paths where appropriate.
We design around appropriate autonomy, not maximum autonomy.
This depends on the architecture, provider configuration and contractual arrangement.
Opynex will not make a blanket claim that customer data is never used by any AI provider unless the actual provider configuration and contractual terms support that claim.
For AI-enabled customer deployments, the applicable architecture should identify what information is sent to which provider and under what conditions.
Customers with specific AI-data requirements should raise them during discovery.
Some implementations require access to APIs, accounts, service credentials or other systems.
The access required depends on the workflow.
Where technically feasible, access should be scoped to the minimum permissions required for the defined operation.
We do not need administrative access to every system simply because an automation touches part of your technology stack.
Customers retain their rights in Customer Data subject to the applicable agreement.
Where Opynex processes personal data solely on behalf of a customer, the relevant Data Processing Agreement can define the processing relationship and applicable responsibilities.
There is no single answer applicable to every Opynex implementation.
Data location depends on the architecture, customer-selected systems, Opynex infrastructure and third-party providers involved.
For enterprise engagements, relevant data flows and processing locations should be documented as part of the technical and data-protection review.
Opynex does not position customer data as an advertising product.
The precise permitted uses of Customer Data are governed by the relevant customer agreement and Privacy Policy.
GDPR compliance depends on the actual processing activity, roles, systems, safeguards and legal obligations involved.
We therefore avoid using “GDPR compliant” as a blanket marketing certification.
Opynex designs its processes and customer engagements with applicable data-protection requirements in mind and can establish appropriate controller/processor arrangements, contractual safeguards and technical controls where required.
Customers remain responsible for determining their own regulatory obligations.
We do not claim blanket DORA compliance.
DORA obligations depend on the regulated entity, ICT service relationship and applicable circumstances.
Where a customer is subject to DORA or another sector-specific framework, those requirements should be identified during procurement and incorporated into the relevant architecture and contractual arrangements where Opynex can support them.
Opynex does not claim ISO 27001 or SOC 2 certification unless and until the certification has been obtained and its scope verified.
Where certifications are not held, Opynex provides accurate information about implemented security controls and available documentation.
Opynex may rely on third-party providers depending on the service architecture.
Where those providers process personal data on behalf of Opynex in a processor relationship, applicable sub-processor requirements should be addressed through the customer agreement and Data Processing Agreement.
A current sub-processor register can be maintained once the production provider list has been confirmed.
Applicable incident-handling procedures depend on the service and customer agreement.
For enterprise deployments, responsibilities, escalation paths and notification requirements should be established before production operation.
Opynex does not promise a specific incident-notification deadline publicly unless that commitment is supported operationally and contractually.
Production automation should be designed with failure in mind.
Depending on the system, an Opynex architecture may include error handling, retries, alerts, logging, exception queues, human escalation and recovery procedures.
The exact controls depend on the importance and risk of the process.
Monitoring and ongoing maintenance depend on the service purchased.
A project implementation does not automatically include indefinite monitoring.
Managed monitoring, maintenance and continuous improvement may be provided through an Opynex Care or equivalent managed-service engagement.
Third-party systems evolve.
Where ongoing maintenance is included in the customer's service agreement, Opynex can investigate and remediate integration issues within the agreed scope.
Without an ongoing maintenance arrangement, remediation may require separate project work.
Our preferred enterprise architecture is designed to keep the customer appropriately in control.
The exact ownership model depends on the engagement.
This may include customer-controlled accounts, infrastructure, credentials and environments where appropriate.
Ownership and licensing are documented before implementation.
Ownership depends on the contract.
Customers retain their Customer Data and pre-existing intellectual property.
Opynex may retain its pre-existing frameworks, reusable components, methodologies and know-how.
Custom deliverable ownership or licensing is defined in the applicable SOW or MSA.
We make this explicit rather than leaving it ambiguous.
Yes, subject to the applicable contract.
Enterprise engagements should define termination, data return/deletion, credential revocation, transition responsibilities and any continuing licence or payment obligations.
Operational dependency should come from the value of the system—not contractual confusion.
Pricing depends on the problem being solved.
Opynex may offer standardized digital products as well as custom projects and recurring managed services.
Custom implementations are scoped according to factors including:
We prefer to price around defined scope and business value rather than selling undifferentiated development hours.
Yes, where appropriate.
Managed engagements may include monitoring, maintenance, issue resolution, workflow improvement and operational expansion.
The exact scope and service commitments are contract-specific.
We can design around measurable business outcomes and establish success metrics before implementation.
We do not fabricate or guarantee financial returns that depend on factors outside our control unless a specific contractual guarantee has been expressly agreed.
Our objective is to make the impact measurable.
Opynex can consider appropriate confidentiality agreements as part of qualified business engagements.
Terms must be reviewed before execution.
Where Opynex acts as a processor and applicable data-protection law requires an appropriate processor agreement, a DPA can form part of the contractual framework.
Yes.
For appropriate enterprise engagements, technical stakeholders should be involved before production deployment.
Relevant architecture, data flows, access requirements and operational controls can be reviewed with the customer's technology, security or compliance representatives according to the engagement.
Yes.
For regulated or data-sensitive operations, collaboration with the customer's legal, privacy, security and compliance stakeholders may be necessary.
Opynex designs the technical system.
The customer's appropriate advisers determine the legal and regulatory requirements applicable to its organization.
Potentially.
Requirements concerning hosting region, infrastructure ownership, data residency or approved technology providers should be identified before architecture is finalized.
Feasibility depends on the systems and providers involved.
Typical stakeholders include:
CEOs seeking operational leverage and scalable execution.
COOs dealing with process friction, coordination overhead and operational complexity.
CTOs evaluating architecture, integration, reliability and governance.
CFOs looking to reduce finance administration and improve operational visibility.
Operations leaders responsible for repetitive cross-functional processes.
Transformation and automation teams looking for implementation capacity and production-ready systems.
You don't need a technical specification.
Bring a business process that feels:
We'll start there.
Your Operations. Running Without You.
You don't need to know which workflow to build.
You need to know which part of your operation should no longer work the way it does today.
That's where Opynex starts.