Website to CRM integration brief

Define sources, fields, retries, failures and acceptance. Download a specification template and review an illustrative completed example.

Download the brief template See a completed example

Describe one enquiry journey

A useful brief defines the trigger, the record to create and the person who acts on it. Use one anonymised example to agree fields, retries, failures and acceptance, then choose the connection method.

Source and trigger: Website URL, form and transfer event. For example, successful form validation rather than every button click. List every phase-one form.
Destination and outcome: CRM, record type, pipeline, initial stage and owner. Define when to create or reuse a contact.
Phase-one boundaries: One form, multiple sites, orders or attachments? What stays manual? Scope two-way sync and historical migration separately.

Map the fields

For each field, specify its source, CRM destination, requirement, format and handling of missing or invalid values. Verify actual field names and permissions in the selected CRM.

Contact: Phone or email from the form. Agree validation and customer matching. A matching contact alone does not make an order a retry.
Enquiry content: Task description and agreed order fields. Define length and unsupported-format handling; do not silently discard content.
Source: Page, form code and allowed campaign fields. Transfer necessary values without copying secret URL parameters.
Event identifier: One identifier for an accepted submission and its technical retries. A new enquiry receives a new identifier. Agree where its link to the CRM record is stored.
Stage and owner: Project rules determine these values, rather than visitor-supplied text. Define handling of an unavailable stage or employee.

Separate a retry from a new enquiry

A retry after a delayed response should not create an extra deal. A new enquiry from an existing customer follows its own agreed rule. Cover the case where CRM creates a record but confirmation is lost; reconcile the result before creating it again.

Temporary failure: Agree durable pending storage, retry interval and limit. Exhausted attempts need a manual handling owner. Do not tell a visitor that data is saved unless confirmed.
Invalid fields or access: Do not retry the same invalid request indefinitely. Record a safe reason, assign correction and define how to resume.
Reconciliation and monitoring: Record time, event identifier, result, attempt number and the CRM record link on success. Agree retention, access and data scope. Never log keys or tokens.

Example: a service enquiry form

An illustrative brief for one form. Names, contacts and rules below are examples, not customer data or a completed deployment. Verify values and available capabilities before launch.

Task: After validating the Service enquiry form, accept the request and transfer it to the selected CRM. Phase one is one-way website-to-CRM transfer; payments, files and old records are excluded.
Fields: Name: Test customer; email: client@example.com; task: Service website needed. Map to contact name, email and a new deal description. Verify fields and formats before configuration.
Route: Website source, agreed sales pipeline and New enquiry stage. The process owner assigns the manager. These are illustrative labels, not API codes.
Retries: Resend demo-enquiry-001 with the same identifier; expect one deal. A new event with the same email creates a new deal linked to the existing contact.
Failure and recovery: In a test environment, disable CRM receipt. Keep the enquiry in agreed pending storage. After recovery, reconcile and transfer without an extra deal. The owner can see the error and outcome.

Download the completed example

A real order reference: the DOROGA form creates a record with New status and Website source. Fuel reservations, supplies and cash are separate logic. The case shows the interface with demonstration data.

DOROGA: website and order CRM

Verify six acceptance scenarios

New enquiry: one record with agreed fields, source, stage and assigned employee access.
Invalid required field: a clear error, no invalid deal and no false acceptance confirmation.
Retry of the same event: one deal; the repeated transfer result is traceable in the log.
New event from an existing customer: apply the agreed contact rule without losing the new task.
Temporary failure and lost CRM response: the enquiry is traceable, results are reconciled and recovery creates no extra record.
Team handover: instructions, necessary access, owners, error monitoring and support terms are delivered.

For each scenario, define inputs, expected outcome and the acceptance owner. Simulate failures in a test environment rather than interrupting production.

Questions about the brief

Do I need to know the API methods?

An initial brief can describe the source, action and result. The supplier checks the implementation method, fields and CRM constraints. Add verified methods in a technical appendix.

Is “no duplicates” a sufficient requirement?

No. Retrying one submission and receiving a new task from the same customer need different rules. Specify contact reuse, new deal creation and event identity.

Do we need custom middleware?

Not always. Check native forms and existing connections first. Custom development is needed when they cannot cover the agreed data, route and failure handling.

Who receives error alerts?

Assign a technical owner and a person who can handle the enquiry manually. Agree the channel, escalation conditions and recovery process.

Should I attach production data and a token?

Use an anonymised example for discussion. Arrange production access separately with necessary permissions. Keep credentials out of public briefs, browser code and error logs.

Is this a completed client integration?

The example is illustrative. It demonstrates a brief and acceptance expectations. The DOROGA case separately verifies website order creation, not every rule in this example.

Check your CRM requirements

The initial BYstudio review is free. Send the website URL, CRM name and an anonymised example of the intended result. We review existing connections and changes needed. A complete specification is not required for the first enquiry.

Website-to-CRM connection options

Reliable enquiry intake

Ready-made CRM or custom software

Documentation for the technical appendix

Check each CRM against its current documentation. Bitrix24 documents form configuration, contact matching and REST limits. Contact matching and preventing a repeated event are separate tasks.

Documentation checked on 21 October 2026. The illustrative rules above are proposed requirements, not defaults guaranteed by every CRM.