From first enquiry
to an owned next step.

Define what should happen after someone presses send

A website-to-CRM integration turns an accepted form submission into records and work the team can act on. It should answer four questions: who contacted us, what are they asking for, who is responsible and what happens next? Copying an email address into a list answers only the first question.

For a fictional consultancy, the intended outcome might be a contact, an opportunity describing the enquiry and a follow-up task. Agree which information belongs on each record and how they connect. Decide whether the response is assigned to one person or a shared triage process, then give that process a real owner.

Meibo’s dedicated enquiries endpoint creates or reuses a contact by email and creates a linked deal and follow-up task as one atomic intake operation. The response returns contact_id, deal_id and task_id. This is the contract to test for an intake integration, rather than reconstructing the sequence as unrelated browser requests [1].

Put a server route between the form and the CRM

The browser submits to your website’s endpoint. Your server validates the input, checks the configured abuse protection and calls the CRM using a secret scoped to enquiry creation. The browser receives a controlled outcome from your server. It never needs the workspace key.

Treat the website endpoint as public, even if the form itself is only linked from one page. Set body-size limits, validate field types and lengths, and apply appropriate request throttling and bot checks. A browser origin check can help enforce your intended form flow, but it is not authentication for requests from arbitrary clients.

Keep the key in server-side secret configuration and use enquiries:write for Meibo intake. Separate production from test credentials and give someone responsibility for rotation and failure alerts. A public form should not inherit record-reading or general editing permissions simply because a broader key was convenient during development.

Map the information the endpoint actually accepts

The current Meibo intake contract accepts name, email, subject and message, plus an optional owner. It uses strict validation. Do not add a company, campaign or UTM field to the payload and assume the API will silently store it. Decide how additional information is supported before collecting it for an integration [1].

If attribution matters, distinguish the business requirement from the available destination. You may need a separate approved mapping or a clearly labelled part of the enquiry message. Avoid presenting narrative text as a structured reporting field. Keep any stored submission data limited to what the workflow needs and document who can access it.

Meibo’s owner option accepts a valid team record ID, or the documented Agency team value. A teammate’s email address is not interchangeable with their record ID. If the selected owner becomes unavailable, make the failure visible or define a supported fallback; do not quietly assign the enquiry to an unrelated person.

{
  "name": "Alex Morgan",
  "email": "alex@example.com",
  "subject": "Website project enquiry",
  "message": "We would like to discuss a new website."
}

Use one submission ID across network retries

Generate a unique submission ID for one logical enquiry and retain it while retrying that same payload. Meibo requires an Idempotency-Key of 8 to 128 letters, digits, underscores or hyphens. A UUID is a suitable format. Generating a fresh key inside every retry defeats the purpose [1].

When the same workspace submits the same key and parsed payload again, Meibo returns the previously created record IDs. Reusing that key with a different payload produces a conflict. If the visitor meaningfully edits the enquiry for a new submission, treat that as a deliberate new operation rather than silently changing the body under an old key.

Keep submission identity separate from contact identity. One person can submit two legitimate enquiries and should not lose the second because their email matches an existing contact. Conversely, one timed-out submission should not create two opportunities merely because the visitor clicked send again. Meibo’s intake contract handles contact reuse and submission replay as different decisions.

Make the form’s states honest and useful

While submitting, show a visible pending state and prevent accidental repeated clicks without clearing the message. On success, confirm the enquiry was received and explain the real next step. Only promise a response time if the team has agreed and can support it. Avoid suggesting that a meeting is booked or a person has already reviewed the message.

On a validation error, identify the relevant field and preserve the other values. On an uncertain network failure, retain the submission identity and offer a retry. The visitor should not need to retype a long brief because your server did not receive the final response. Keep status messages accessible to assistive technology as well as visible on screen.

A CRM save and an acknowledgement email are separate outcomes. Do not mark an accepted enquiry as failed merely because an optional email provider is unavailable; that could encourage a duplicate submission. Track email delivery independently and make the promised confirmation behaviour explicit.

Test the human handoff, not just the payload

After a test submission, open the CRM as the person who should respond. Confirm they can find the contact, understand the request and see their assigned task. Check that the deal is in the expected intake state and that the links lead to the correct records. A successful server log does not establish any of these user-facing outcomes.

Repeat with an existing email address, an unavailable owner and a second genuine enquiry from the same contact. Test a timeout and a replay using the same submission ID. The expected result is one operation for a retry and separate work for a separate enquiry, with no ambiguous ownership.

Measure the time from accepted enquiry to the first meaningful response using a definition your team can reproduce. Do not confuse a form acknowledgement with a human reply. A simple review of unassigned or untouched enquiries can be more useful than adding another automation before the intake process is stable.

Launch with a recovery route and an owner

Decide what happens if the CRM is unavailable. Your server may reject the submission with a clear retry state, or durably accept it into a queue that an operator monitors. These are different service promises. If you tell a visitor their enquiry is received after queueing, make sure the queue survives restarts and failed items cannot disappear silently.

Log a correlation or submission ID and a redacted error category. Avoid copying entire messages into general application logs. Establish who checks the failure queue, how they recover a record and how they verify that a manual recovery will not duplicate a previously accepted operation.

The worksheet below captures field meaning, destination and acceptance checks. Complete it with the person who handles enquiries, not just the developer. Run the entire path on the actual website and destination workspace before presenting the connection as ready for customers.

Common questions.