A guide by SevenLab
Adding AI to existing software is a decision about data access, process ownership and controlled changes, not just model selection. SevenLab is a custom AI development partner in Amsterdam for organisations in the Netherlands and Flanders. Use this guide to define an integration brief. Every named platform below is an assessment subject, not a confirmed SevenLab connector.
Start with the transaction, not the connector
Define one business event and the records it touches before requesting an AI API integration. For CRM and ERP work, identify which system owns customer identity, commercial terms and financial status. Separate reading information, proposing a change and executing that change. Ask your prospective partner to show where human approval belongs and how the workflow behaves when records disagree.
Illustrative scenario, hypothetical scope: a sales team wants information from Salesforce to produce an order draft for Exact Online. The buying question is not simply whether the systems can connect. Require a demonstration that customer matching handles duplicates, missing product codes create an exception and no order is written before approval. If reliable matching is unavailable, a reviewed export may be a better first scope than automatic writes.
- Map the trigger, source records, proposed output and accountable approver.
- Define which system owns each field before allowing updates.
- Include duplicate customers and missing product codes in the acceptance set.
Specify access and the actual AI service
For proposed Dynamics 365, SharePoint or Microsoft Teams integration, ask how user identity, document permissions and service credentials would work. Distinguish permission to retrieve information from permission to share an answer or alter a record. If your brief says to integrate ChatGPT into business software, require the proposal to identify the actual model service, API, data handling and authentication arrangement rather than relying on a product name.
Illustrative scenario, hypothetical scope: an employee asks a question in Teams and receives an answer based on SharePoint documents. Acceptance should cover an authorised user, an unauthorised user and a user whose access has just changed. Require source references, a defined response when retrieval fails and a test that restricted content does not appear in answers or logs visible to other users. Any proposed Dynamics 365 write action needs its own approval and permission tests.
- Request an architecture diagram showing identities, data flows and trust boundaries.
- Test restricted documents, revoked access and expired credentials.
- Record the proposed API and data handling terms for buyer approval.
Compare orchestration with targeted modernisation
Outsourcing Make automation, commissioning an n8n implementation and building a custom integration should be compared against the same operational requirements. Ask where execution would run, who would maintain credentials and how failed steps would be investigated. Do not select an orchestration approach only because a demonstration is quick to assemble. For legacy software modernisation, first establish whether the existing application offers a documented API, supported export or another maintainable interface.
Illustrative scenario, hypothetical scope: an older production system only provides an approved nightly file export. A staged integration could validate that file and prepare proposed updates elsewhere while the legacy application remains the system of record. Acceptance would require rejecting an unexpected file structure, identifying missing batches and preventing a repeated import from creating duplicate records. Replace the legacy component only if its constraints prevent the required workflow, rather than treating a full rewrite as the default.
- Compare Make, n8n and custom code on ownership, recovery and maintainability.
- Obtain evidence that the proposed legacy interface is supported and accessible.
- Test changed file structures, missing batches and repeat processing.
Buy evidence of recovery and operational ownership
Structure the proposal around discovery, a read-only trial, limited write access and operational handover. Each stage should have named deliverables and an explicit approval decision. Ask for interface documentation, deployment instructions, monitoring responsibilities and a process for changes to upstream systems. An integration is not ready for handover merely because the normal path works in a demonstration.
Illustrative acceptance exercise, hypothetical scope: an approved order is submitted, the receiving system accepts it, but the response is lost. The team must show how it checks the result before retrying and how an operator resolves an uncertain outcome. Acceptance requires evidence that a retry does not create a second business transaction, alerts reach the responsible person and processing can be paused without losing the audit trail. Use this exercise to clarify support responsibilities before signing.
- Agree stage gates and evidence before granting production write access.
- Run a lost-response test and verify duplicate prevention and reconciliation.
- Assign ownership for monitoring, incident response and upstream interface changes.