Back to contents
Free prototype
Practical analysis

Technical specifications for CRM: example structure and acceptance criteria

A good SOW describes who performs the action, with what data, and what should happen. It helps to compare estimates and accept the system after development.

Editorial team globall.dev ·

Purpose and boundaries of the first version

Write down the problem in an observable form: requests from the site do not fall into the general list, managers forget the next contact, the report is collected manually. Then determine the result: each accepted request is visible to the person responsible, the transaction has a next step, the owner receives a report from the saved data.

Separate the first version and possible development. Warehouse, accounting and automatic pricing can be adjacent tasks, but do not have to be included in the initial CRM. If you leave the boundaries implicit, different implementers will calculate different systems.

Roles and data

  • Roles: owner, director, manager, external contractor. Each requires read, edit, and upload permissions.
  • Entities: client, company, contact, deal, object, document, task. Indicate the connections between them.
  • Required fields: what is required during creation and what can be filled in later.
  • History: what changes are logged and who can see it.
  • Deletion: What can be archived and what data cannot be deleted from a completed order.

Example scenario description

New application from the site. The form conveys the name, contact and service. CRM creates a request, saves the page and source, and searches for an existing contact. If there is a match, the connection is proposed according to the agreed upon rule. The manager is assigned in turn and receives the task of contacting. If the external channel is not available, the request remains in the queue with a reason.

Criteria: re-delivery does not create a duplicate; an application without an optional field is accepted; a disabled employee does not receive an assignment; integration failure is visible in the report. Such a scenario can already be assessed and verified, in contrast to the requirement “the integration must work well.”

Integrations and data migration

For each integration, specify the service, data source, direction of exchange, frequency and available rights. Don’t assume that any messenger gives away the whole story. Capabilities are checked before assessment; sometimes a paid tariff or an official connection channel is required.

For migration, please attach an anonymized example of a table. Determine what to do with duplicates, empty contacts and non-existent responsibilities. The final import should be accompanied by a report: how many lines were transferred, which ones were rejected and why.

What is included in the acceptance

  1. Work of basic routes on a computer and phone.
  2. Access check via interface and direct requests.
  3. Handle repeated events and temporary integration failure.
  4. Uploading data and restoring a backup.
  5. Transfer of sources, instructions and access to the owner.

The estimate must refer to the agreed version of the technical specifications. Changes after the start are documented in a separate list with an impact on the period and cost. B CRM section You can watch a demo and submit the process for evaluation. You can start with a prototype, and then turn confirmed scenarios into technical specifications.

Let's discuss your task

Describe the process and result you need. We will show the prototype and agree on the development content, cost and deadline.

Get a prototype
According to your task

Solutions and practical materials

Your free prototype in 48 hours

Tell us what needs to be done. We will prepare an example solution for your business.

  • Prototype using your process as an example
  • Composition, price and period until the contract
  • We transfer the sources to the customer

Prefer to message us? Telegram @globalldev_ceo

Step 1 out of 5
What needs to be done?

You can choose several options.

IP Geolocation by DB-IP