Registering a client's branch visit: from a QR code to a deal in Bitrix24

A client walking into any of 39 branches has to land in the CRM right away — with a verified phone, consent for a credit bureau inquiry and no duplicates. The client's old applications piled up next to new ones, and the one-time code was generated and checked right in the browser, so verification was a formality.

The form opens on a phone via a QR code, the whole branch goes online through a single NAT, and some external checks are paid and unstable — a failure of any external service must not lose the visit.

• A bilingual RU/KZ form via QR code: dictionaries of 39 branches and 18 sources, validation of the individual ID (IIN), phone and amount, a car pre-appraisal by make, model and year
• The contact is found by IIN and phone or created; the client's latest open deal is updated and the rest are moved to the "Duplicate" stage
• Phone-owner verification, a consent code for the credit bureau inquiry and generation of the consent document; if the service is unavailable — a manual paper-signature branch
• A server-side one-time code instead of a browser one: valid for 5 minutes, 5 entry attempts, resend no more than once per 60 seconds
• Handing the client off to the internal credit system fire-and-forget, two-stage accounting of paid requests and an end-to-end visit_request_id across all steps
• Incident review of July 25, 2026: only 2 of 34 save attempts went through — browsers held old JS cached for 30 days; static assets were versioned and IP limits removed