Разработка
CRM на заказ

Start by defining the work the CRM must do.

Development starts with the process: where an enquiry comes from, who makes the decision, which documents are required, when a commitment arises and what marks completion. We examine not only the normal route but also returns, cancellations, partial payments, reassignment and collaboration across departments. These situations determine the real complexity of a system.

The design deliverables include role descriptions, process maps, a data model, prototypes of key screens and an integration list. For every scenario, we define inputs, permitted actions and expected results. Instead of asking for a “convenient client card”, we specify a verifiable task: the manager can see contacts, contracts, open enquiries and outstanding balances in one place.

The first release covers a complete working route, for example: client → project → work items → payments → report. Inventory, purchasing or partner portals can follow later if the core process can already work without them. This sequence lets the team use the system and provide feedback before the entire automation programme is complete.

Any entity, with explicit relationships and rules.

A custom CRM can represent much more than contacts and deals. Entities may include properties, equipment, leasing applications, insurance policies, projects, contractor work, delivery routes or service requests. Each object has fields, statuses, relationships, a change history and its own access rules.

We design relationships before screens. One client may have several legal entities and dozens of contracts. Several contractors may work on a project, while a single payment may cover several work items. A separate payment-allocation entity records these relationships explicitly and allows the system to verify that allocations do not exceed the transaction amount.

Critical constraints are enforced in the database and server-side logic: an external transaction ID must be unique within its source, a work item must belong to a project, and required details must be checked before a document is issued. Money is stored with fixed precision or in minor currency units. Currency, time zones and rounding rules are agreed separately.

Example project CRM model. A client has multiple projects; a project has multiple work items. Allocations connect work items and payments.

Moving to another stage means checking its conditions.

A status describes an object’s state; a transition defines an action. Before approving an application, the system checks its documents, the employee’s authority and the outcome of the previous stage. A button must not change the status when a required condition is missing. Validation runs on the server even if the interface already hides the unavailable action.

Approvals can be sequential, parallel or conditional on deal parameters. For example, applications above an agreed limit go to the finance director, while a non-standard contract goes to legal. Each decision is saved with its author, timestamp and comments. If an item is returned for revision, we define which approvals must be obtained again.

Overdue stages can trigger reminders and escalation to a manager. Transitions that initiate financial operations or issue documents are protected against repeated execution. When several users edit an object, its version is checked so one employee cannot overwrite another’s decision.

1. 01ApplicationDetails and owner
2. 02ReviewDocuments and conditions
3. 03ApprovalAuthorised decision
4. 04ContractApproved version

Access depends on the action, the object and its context.

A role defines a set of permissions, but many companies need more detail. A sales manager may see only their clients, a team lead their department, a finance specialist payments for several legal entities, and a contractor only assigned work. Additional restrictions depend on record ownership, department, status and individual fields.

Permissions are checked on every server request: opening a card, searching, exporting, downloading a file or editing a record. Hiding a column in the browser does not protect data. Restricted amounts must be excluded from API responses, and a document link must verify that the user can access that particular file.

External portals have separate data scopes. Clients see their contracts, suppliers their requests, and partners the enquiries assigned to them. Administrative operations and permission changes are logged. Critical actions may require re-authentication or a separate approval.

Example access matrix. Actual roles and restrictions are agreed for each project.

Budgets, commitments and cash movements are tracked separately.

Contract value, expected costs and payments already made answer different questions. Forecast profit is contract revenue less budgeted costs. Cash balance is receipts less paid expenses. These figures must not be confused: a profitable project may still need temporary funding.

A receipt or debit is linked to a project, contract and specific work item through allocations. One payment can be split across several purposes, while a work item can be paid in instalments. Amounts and directions are validated within one database transaction. If any part fails validation, the entire set of changes is rolled back.

Financial rules depend on the industry and contract. In the construction example, 5% is retained from an accepted RUB 8m milestone: the RUB 7.6m payment and RUB 400,000 retention are tracked separately. Wholesale dispatch is allowed when existing debt plus the new order, less receipts, falls within the credit limit. For the hotel group, a 30% deposit is one check-in requirement. Preparing a document does not mean money has been received or debited: payment is confirmed by a separate event.

Imports should be repeatable and controlled.

A bank connection depends on the available interface, account type and permissions granted. One bank may provide an API, while another may only support statement files. Before estimating the work, we check fields, available history, transaction statuses, authentication methods and the limits of the particular connection.

A transaction is identified by the combination of connection, account and external ID. Re-importing the same period must not create new payments. If the source updates a known transaction, permitted fields are revised under agreed rules and the history is retained. Unconfirmed transactions are excluded from actual-payment calculations.

Payment reference, counterparty and project allocation are different pieces of information. Automatic allocation is only appropriate with a reliable match and an explicit rule. Ambiguous transactions go to a review queue. The user can see the source, import date, original reference and why the transaction needs attention.

1. 01SourceAPI or statement
2. 02ValidationStatus and external ID
3. 03RegisterNew and known records
4. 04AllocationProject and work item

Define the authoritative source for every field.

We connect the CRM to websites, 1C, telephony, email, delivery services, electronic document exchange and industry systems. Having an API does not mean an integration is ready: objects, field mappings, identifiers, transfer directions and error-handling rules still need to be agreed.

We identify the authoritative system for each data type. For example, the CRM controls the project stage, 1C controls posted accounting documents, and the bank confirms the transaction. If a field may be edited in several systems, conflict-resolution rules are defined in advance. Otherwise the next synchronisation could overwrite a correct value.

An external service can be slow or temporarily unavailable. Long-running exchanges are handled by background jobs, with errors tracked separately from the user’s action. The interface distinguishes “saved in CRM”, “waiting to be sent” and “accepted by the external system”. Retries are designed to avoid creating a second document.

The exchange contract matters more than the protocol name.

For an API, we document endpoints, data formats, authentication, access restrictions and error responses. Validation checks required fields, permitted values, currency and related objects. Lists support filters and pagination so the client application does not have to load the entire database.

Retrying a request must not repeat a financial action. Depending on the operation, we use a unique external identifier or an idempotency key. The same key with different content produces a conflict; an exact repeat returns the result of the action already completed. The guarantee is enforced by server logic and storage constraints.

Event notifications are verified using a signature or an agreed authentication method. We record the event ID, receipt time and processing result. Secrets are kept out of the browser and logs. The example below illustrates a possible custom CRM contract; it is not a published BFD CRM API.

POST /api/v1/payment-allocations
Authorization: Bearer <token>
Idempotency-Key: allocation-demo-001
Content-Type: application/json

{
  "payment_id": 142,
  "allocations": [
    {"work_id": 58, "amount_minor": 9000000}
  ],
  "currency": "RUB"
}

201 Created — allocation saved
409 Conflict — version or key conflict
422 Unprocessable Content — invalid amounts or fields

One contract, multiple versions and a clear history.

Contracts, invoices, completion certificates and proposals are generated from CRM data using approved templates. Templates separate company details, client details and deal parameters. When a document is created, the values used are saved so a later change to the client’s address does not alter a file that has already been approved.

Each document version has an author, date and status. Drafts can be edited; an approved version can be superseded while its history is retained. Approval routes, numbering, signing rules and electronic document exchange are designed separately. Electronic signature integration requires checking the selected provider’s capabilities and agreeing on the workflow.

Files are kept outside public access, with type and size checks and download permissions. Large attachments can use object storage with temporary links. Retention, deletion and backups must cover attachments as well as CRM records.

1. 01TemplateApproved structure
2. 02DataSnapshot of details
3. 03VersionAuthor and changes
4. 04OutputFile or EDI transfer

Each participant gets their own working interface.

An internal CRM can become the centre of several portals. A client submits a request and follows progress; a supplier responds to a purchasing enquiry; a contractor accepts a task and uploads the result; a partner tracks referred enquiries. These interfaces share a data model while exposing different actions and information.

For each portal, we define which data users create, which requires review and which is read-only. The design must account for several employees from one company, invitations, reassignment and revoking access when a relationship ends. Notifications must not reveal restricted information in an email subject or push message.

Mobile interfaces are designed around real tasks: finding a contact, confirming a site visit, attaching a photo or changing a status. A PWA or dedicated application can be added where needed. Offline work requires separate local-storage and conflict-resolution logic and is estimated independently of a responsive web interface.

Every metric needs a formula and a source.

A report starts with a management question. Which projects need attention? Where are approvals delayed? How much money is needed next week? Each metric has a defined period, filters, inclusion rules and treatment of cancelled transactions. Different employees need a shared understanding of terms such as “revenue”.

Summary figures link to their underlying records: a debt total leads to contracts, costs to payments, and overdue tasks to the people responsible. Report access follows permissions on the source records. Exports are checked separately because a download can expose far more data than a single screen.

For large volumes, we use prepared aggregates and background calculations. The screen shows the reporting period and when the data was updated. If a report takes time, the user starts a job and receives a file when it is ready rather than keeping the page open.

An assistant works within the user’s data permissions.

A custom CRM can include document recognition, draft replies, conversation summaries, knowledge-base search and initial enquiry classification. A useful scenario has a clear input, output and review method. For example, the system extracts company details from a file and proposes values for a record, which an employee confirms.

Model outputs are not treated as reliable by default. Important facts should show their source; the original document is retained, and users can correct the result. Payments, permission changes and sending legally significant documents require a separate controlled action rather than an unrestricted model command.

Before connecting a provider, we decide which information may be sent, how long history is retained and how request costs are tracked. Search across internal material must enforce the same permissions as the CRM: a chat must not reveal information hidden from that employee in the record. Suitable local deployment options can be considered for restricted environments.

Test the migration before switching the live system.

We collect data from the previous CRM, spreadsheets and accounting systems, then map fields, reference lists, statuses and relationships. Duplicate-handling rules are defined carefully: the same company name does not always identify the same counterparty, and a shared phone number may belong to a receptionist. Ambiguous records are flagged for review.

A trial import runs in a separate environment. We reconcile object counts, amounts, relationships, dates and sample records. A mapping between old and new identifiers allows the migration to be repeated and errors traced to their source. A successfully uploaded file does not prove that the data was migrated correctly.

At launch, we agree on the cutoff for changes in the old system, the final export and reconciliation. If changes cannot be paused, we design a transfer of updates made in the interim. The recovery plan must account for records users have already created in the new CRM; simply restoring the old database could lose them.

1. 01MapFields and reference data
2. 02CleanDuplicates and exceptions
3. 03ValidateTrial import and reconciliation
4. 04SwitchFinal migration

Add complexity in response to requirements and measurements.

We use Laravel for server-side logic and Vue or another agreed tool for rich interfaces. A relational database stores connected entities and constraints. The specific database, hosting approach and infrastructure are selected after assessing data, integrations and operations. The technology in an existing CRM may differ from the architecture chosen for a new project.

A modular structure separates sales, projects, finance and documents within one application. This is often more practical than splitting a young system into many services. Queues handle long-running work such as reports, imports, notifications and data exchange. Caching and a search index can be added as needed.

Performance requirements are expressed in numbers: record volumes, concurrent users, import frequency, file sizes and acceptable response times. Before scaling, we measure database queries, background-job duration and resource use. More server capacity does not replace appropriate indexes or bounded response sizes.

Check both access protection and the ability to restore operations.

Protection includes authentication, server-side access checks, secure secret storage, session controls and logging of significant actions. Depending on the requirements, we add multi-factor authentication or corporate sign-in. Administrative functions are separated from everyday employee tasks.

The audit log records who performed an action, what was affected and when it happened. For critical changes, we retain previous and new values while excluding passwords, tokens and unnecessary personal information. The log should help reconstruct events rather than become another unprotected copy of the database.

Backups cover the database, files and required configuration. We agree on acceptable data loss in time terms and the target recovery time. Copies are kept separately from production with restricted access. Regular restoration tests confirm that backups are usable and the recovery procedure is understood.

A module change is tested across the workflows it affects.

We test not only a new button but the full process affected by the change. Updating payment allocation affects the transaction’s unallocated balance, work-item payments, project economics, filters and reports. An impact matrix helps select the right checks rather than discovering a broken existing workflow weeks later.

Automated tests cover calculations, access rules, status transitions and integrations. Critical user journeys are also checked through the interface. Negative cases are examined separately: repeated imports, insufficient permissions, incomplete applications, cancellations and simultaneous edits.

Work takes place in separate branches with change review. Before release, we deploy to a test environment and verify migrations and agreed workflows. A production release has a version number, change list and recovery plan. Rolling back code and rolling back data are different tasks; migrations need a safe procedure defined in advance.

The system remains manageable after launch.

At handover, we define the source-code deliverables, access credentials, deployment instructions, environment-variable documentation and backup procedures. Documentation covers architecture, the data model, APIs, roles and key business rules. Rights transfers and use of third-party components are governed by the contract.

Users need instructions for their tasks: creating a client, approving a document, correcting an allocation or generating a report. Administrators need guidance on access, queues and reference data. The technical team needs setup, update and troubleshooting instructions. A single general-purpose file rarely serves all three audiences.

After launch, we collect feedback and monitor errors, response times and integration queues. New requirements follow the same cycle of assessment, design, testing and release. Support response times, service hours and availability requirements are agreed separately according to the CRM’s role in the business.