How to Document CRM Requirements Before Development: Interviews and Artifacts

Why it's important to document CRM requirements before development

'Vague requirements' are not just a lack of documents but phrases like 'make it convenient', 'like in the old system', or 'let the manager decide'. That feels flexible at the start but later becomes endless clarifications, contested changes and different versions of 'how it should work' among sales, service and management.

CRM often fails not because of code but because of expectations. If sales expect a deal to be entered in 3 fields while compliance requires mandatory checks and approvals, the system will annoy someone either way. Without agreed rules up front, the implementation team will make ad-hoc decisions and complaints will come from every side.

Some things are hard to solve 'on the fly': which stages and statuses are standard, who and when can edit a customer card, which fields are mandatory, what counts as a lead and a successful deal, and which reports are the source of truth for KPIs.

Documenting requirements early saves time not on 'writing an RFP' but on approvals. When rules are recorded and confirmed by process owners, any change becomes easier: you can see what is being changed, who is affected and which reports will 'shift'.

Practical example: a manager says 'we need a conversion report', while marketing measures conversion from lead to meeting, sales — from meeting to invoice, and finance — from invoice to payment. Until you define terms and counting points, the report will always be 'wrong'. First agree on terms, rules and metrics, then discuss interfaces and automations.

Participants: who should attend interviews and why

To document CRM requirements, it's more important to invite not 'everyone a little' but those who actually know the work and can take responsibility. Otherwise you'll collect wishes that no one can confirm later, and the project will stall during approvals.

A typical minimum set:

• process owner (sales, service, marketing, procurement) — sets rules and the criteria for 'correct';
• business unit leader — confirms priorities and resolves conflicts;
• key users (1–2 people) — show how things work in reality and where data is lost;
• IT/security/integrations — point out constraints for accounts, access and exchanges with ERP/telephony;
• analyst/methodologist — records agreements and turns them into clear artifacts.

Immediately separate roles: who makes decisions and who advises. A simple rule: each block (process, data, reports) should have one owner who gives the final 'yes'. Others can argue and suggest, but should not dilute the outcome.

Also appoint a data owner (reference data, card quality, mandatory fields) and a reports owner (KPI formulas and slices). For example, in a maker company selling to government and offering service, the commercial director may own the funnel and forecast while the service head owns inquiry statuses and SLAs.

To avoid 'everyone agrees but no one is responsible', record during the meeting: who owns the decision, who approves, the deadline and how the result is considered accepted (minutes, process diagram, report mockup).

Preparation for the interview: what to collect before the first meeting

It's better to come to the first interview not with an abstract 'we want to automate sales' but with a small folder of facts.

Start with measurable goals: 'reduce lead processing time to 1 hour', 'eliminate duplicate customers', 'see sales forecast by stages', 'get a service requests report without manual consolidation'. Phrases like 'increase efficiency' do not help decision-making.

Next, gather the team's current artifacts: regulations and instructions, email templates, proposal examples, deal cards, Excel sheets, screenshots of reports, website form samples, examples of requests from messengers.

Before the meeting, define the boundaries of the first phase. For example, include sales and service in the MVP, while marketing automation and complex BI dashboards move to phase 2. This significantly reduces scope creep risk.

What to prepare:

• 3–5 project goals in simple sentences;
• the list of departments and channels included in the first phase;
• a list of problems with examples (lost leads, duplicates, manual reports);
• current documents and sample deals, requests and reports;
• the format of documentation: meeting minutes, process diagrams, requirements table.

If you have B2B equipment sales and a service team, bring 2–3 real cases: from lead to delivery and from request to ticket closure. These are easiest to use to quickly document requirements and find bottlenecks that would otherwise surface during development.

Interview structure with the business: a step-by-step scenario

Run interviews as a review of real departmental work rather than a discussion of 'what buttons are needed'. One moderator asks questions, the other records facts: who does what, when, and what result is expected.

1) Start with the goal and the measurable result

Ask: what is the department's goal for the next 3–6 months and how will you know things improved? This could be lead processing speed, share of closed deals, data quality or reduced losses at stages.

Record constraints immediately: deadlines, mandatory rules, what must not change (for example, contract form, approval steps, compliance requirements).

2) Walk through the customer's journey step by step

Ask participants to walk the full path from first contact to closure: where the request comes from, who accepts it, how it's qualified, how it is handed over, and how the outcome is recorded. Follow the steps as they happen today.

At each step ask the same clarifying questions: what is the input (email, call, form, file, verbal agreement), who executes and who approves, what should be the output (created lead, filled card, invoice, task), where delays occur and why, and what you do when the process deviates.

Example: a manager says leads are 'sometimes' tracked in a spreadsheet if they lack access or fields. This is not a minor detail but a signal: you need to specify permissions, mandatory fields and an offline scenario.

3) Align terms and close open items

Agree definitions: how a lead differs from a deal, what an inquiry is, who counts as a client, what 'closed successfully' means. At the end collect open questions and assign owners so disputed points don't get postponed.

Mandatory artifacts: processes and scenarios

To build and verify requirements you need tangible artifacts, not vague 'make it convenient' notes. Artifacts turn interview conversations into rules: what we do, who does it, in what sequence and what we count as the result.

Process maps for key flows

Start with process maps for main streams: sales, service, marketing. You don't need to map the entire company. 5–10 steps per flow with clear start and end points is enough.

Example (sales): lead created -> qualification -> proposal -> approval -> contract -> delivery/acceptance.

For each map add events and statuses: what starts a stage, what a pause means (and how to record it), and what constitutes completion. Without this, CRM quickly becomes a bunch of cards where everyone tracks statuses differently.

Work scenarios: standard and exceptions

One standard scenario per process is the minimum. Projects are usually broken by exceptions, so document 3–5 frequent deviations alongside the standard case: date change, return to a previous stage, re-approval, duplicate lead, service request without a contract number.

Make scenarios testable and concise: 'step -> result -> what we record in CRM'.

Also document:

• SLAs and escalations (reaction and handover times, who decides on overdue items);
• quality control points (mandatory fields, checks, reasons for rejection or return for rework);
• transition rules (which statuses are available, who can move them, which conditions are required).

If these are not documented beforehand, the implementation team will do 'as they understand' and business will argue not about details but about the whole logic at acceptance.

Mandatory artifacts: roles, rights and data

If roles, permissions and data are not described before development, CRM quickly becomes a 'shared notebook'. Some people see too much, others cannot work, and reports don't add up because fields are filled inconsistently.

Roles and access matrix

Create a simple matrix: role -> tasks -> required objects. Remove the 'everyone can do everything' default and assign who is responsible for results at each step.

Describe rights as actions: read, create, edit, delete, export. Also note visibility of fields and records (for example, a manager sees only their deals, the head sees department-wide data, security sees passport fields in read-only mode).

The document should at minimum include: list of roles and tasks, object access (leads, customers, deals, inquiries), export and bulk operation restrictions, and visibility rules (by department, region, or project).

Data structure, reference data and quality

Next, record card structures: which fields exist on lead, customer, deal and inquiry cards, and which are mandatory at which stage. It's useful to separate 'operational data' from 'reporting data' so managers aren't forced to fill unnecessary fields.

Reference lists and unified classifiers prevent chaos. If 'lead source' is typed manually, in a month you'll see 'instagram', 'Instagram', 'insta'.

For data quality define rules: mandatory fields, uniqueness checks (phone, email, BIN/IIN), deduplication and who may merge duplicates. Example: when creating a customer the CRM warns about a phone match, but only a senior manager can merge records.

Mandatory artifacts: reports, KPIs and integrations

Reports, KPIs and integrations are often remembered too late, when 'everything is almost ready'. Then numbers don't match, management loses trust in CRM, and implementation becomes endless rework.

First create a reports catalog. Important is not the name but three answers: who views it, how often and what decision is made. The commercial director may check the funnel weekly, service head may track overdue items daily, and finance may reconcile paid invoices monthly.

Then make a 'metric passport'. Every number needs a formula and rules: what counts as 'deal in progress', how conversion is calculated, which statuses are 'successful', which period and which slices are needed (manager, region, product, channel). Separately document the data source: CRM, telephony, website, ERP. Otherwise two departments will bring two 'correct' reports.

A useful artifact for operational panels is a list of signals that require action today: overdue tasks, deals without a next step, ticket backlog, share of cards missing mandatory fields. This clarifies what the system should highlight.

Document integrations with short cards: what we send, where, when and which system is authoritative in case of conflict. For example, leads from the website go to CRM, telephony calls create activities and recordings, and ERP sends payments and shipments for revenue reporting.

It is convenient to have separate artifacts: reports and dashboards register (owner, frequency, decision), KPI passport (formulas, slices, period, source), integration map (objects, directions, triggers, errors), logging requirements (who changed what, status history), and data quality rules.

Logging is often critical: you need to know who changed a deal status, deleted a contact or corrected an amount. This reduces disputes and helps support find root causes faster.

How to agree and 'freeze' requirements without bureaucracy

To record requirements without drowning in approvals, agree on simple rules: what is in the first version, how results are accepted and how changes are made.

Start with MVP prioritization: 'must have', 'nice to have', 'later'. Teams won't try to cram everything into the first release and the business will understand what they'll get on time.

Approve in one document or meeting minutes: function priorities for the first release, acceptance criteria for key scenarios (what counts as 'done'), constraints on timeline/budget/security/data storage, change procedure (who initiates, who estimates, who approves), and a single list of open decisions with status and decision date.

The list of decisions is especially important. Any disputed question (for example, 'how to count a repeat sale' or 'who can change a deal status') is logged with options and the chosen answer. Oral agreements are forgotten after a month; this list closes the topic.

To make the 'freeze' not feel like a ban, set a clear window for changes: for example, collect new wishes weekly, evaluate impact on timelines and either move to the next release or change the current plan with explicit approval.

Example: a company with sales and service agreed that the first version must include a customer card, funnel, service tickets and two manager reports. Everything else is postponed until those scenarios pass acceptance checks.

Common reasons projects fail because of vague requirements

CRM projects rarely fail due to 'bad development'. More often the team interprets the needs differently and this is discovered too late.

First cause — mixed goals. Teams try to cover everything without choosing 2–3 key processes (for example, sales and service) and measurable outcomes (lead handling time, conversion, SLA). Each department pulls the system in its own direction and there are no priorities.

Second cause — no data owner and input rules. If you don't agree who manages reference data, mandatory fields, phone format, duplicate rules and stages, cards become garbage and reports lose credibility.

Third cause — reports and KPIs were not defined early. The team configures fields and stages and a month later business asks for a funnel 'as in Excel' and it turns out required values were never collected. Fixing this requires process changes and data migration.

Ignoring exceptions is another common problem. Returns, rescheduling, multiple legal entities, repeat inquiries, different contract types and duplicates may seem rare but they break status logic and automations.

Integrations are often left 'for later'. Without agreed sources of truth (email, telephony, ERP, website), manual input appears and versions conflict.

A bad sign — verbal approvals. This looks like: business expects 'what's convenient for managers', IT expects 'what's quickest to implement'; departments use different terms for the same thing; no one can show an example of an ideal card or report; decisions are made without minutes and owners.

Simple example: sales asks to 'add deals' but doesn't specify prepayments, partial shipments or returns. It works in tests but in production teams use workaround spreadsheets and stop using CRM.

Short checklist before starting development

Before handing CRM to development or implementation, check that requirements are recorded so the team won't guess.

• The goal is clear and measurable: success metrics are chosen (lead handling time, conversion by stages, share of overdue tasks, service response time) and a baseline is set.
• For each key process there is a simple diagram and a list of exceptions: returns, duplicates, non-standard discounts, reassignment, disputed inquiries.
• Roles and rights are described at the action level: who sees deals, who can edit fields, who closes tickets; owners of reference data and quality rules are assigned.
• Mandatory reports and formulas are agreed: exactly what is counted (revenue, margin, plan vs actual), by which dates and with which filters.
• Integrations are documented in one place: source and receiver, direction, frequency, error handling, and business and IT owners.

Also check acceptance: 10–15 main scenarios (lead -> deal -> invoice, inquiry -> resolution -> closure) should have pass/fail criteria. And agree how changes are made after sign-off (who initiates, who estimates impact on timelines and reports, where the new version of requirements is stored).

Example: documenting requirements for sales and service CRM

Imagine a company with sales and a service unit. Leads come from the website and telephony, and some service requests land in a shared mailbox. The goal is simple: no request should be lost and managers should see the funnel and service load.

Start by documenting requirements through one end-to-end scenario and several typical exceptions. In the interview describe 'how it is now', then 'how it should be', and agree what will not be done in the first phase.

Record the process chain: lead -> qualification -> deal -> contract -> service request. For each step specify input (where the data came from), output (what we count as the result) and the transition criterion (when we move forward). For example, a call lead is qualified if contact, need and timing are recorded.

Then fix roles and responsibilities. A manager owns leads and deals, the head approves discounts and sees reports, the service operator accepts tickets and assigns engineers, accounting has read-only access to contracts and payment status.

To avoid 'it stays verbal', produce artifacts: sales and service process diagrams with stages and transition rules, a roles-and-permissions matrix, field lists for entities (lead, deal, contract, inquiry), mockups of 3–5 key reports and their formulas.

Critical integrations are listed separately: telephony (customer card on call), email (auto-create ticket), accounting system (payment statuses and documents).

Final result: the team has agreed artifacts and acceptance criteria. For example: 'a call creates a lead with a source', 'an inquiry cannot be closed without a reason', 'the overdue report refreshes daily'.

Next steps: from requirements to implementation and support

After documenting requirements, it's important not to lose them during the handover. Collect all artifacts in one package (processes, roles, data, reports, integrations) and run a final confirmation session. There you don't brainstorm again but verify: 'this we do in the first version, this we don't'. The result is one approved document and a list of open questions with deadlines.

Then prepare a clear implementation plan: pilot in one team or region with success criteria, role-based training, data migration with cleansing rules and owners, go-live and 2–4 weeks of enhanced support.

Simultaneously decide infrastructure and support responsibilities: who manages access, backups, monitoring, integrations and incident response at night or on weekends. If this is undefined, launch can stop over 'small things' like unavailable email or unstable telephony.

If you need a contractor for implementation and system integration, sometimes it's easier to work with a team that covers infrastructure, integrations and support in one bundle. For example, GSE.kz (gse.kz) as a system integrator delivers complex IT projects and provides 24/7 support, which is useful for corporate CRMs with critical integrations.

After launch assign a business-side product owner for CRM and set an improvement cycle: who accepts change requests, how changes are prioritized, how often updates are released (for example, monthly), and how effects are measured by KPI. That way CRM stays a living system, not a one-off project.