Custom CRM Development Cost in India (2026): Features, Pricing & What Changes the Budget

A custom CRM is a customer relationship management system designed and built around one business’s own sales process, records and rules, rather than a subscription product that the business configures to fit. It still does the job every CRM does: it records each enquiry, contact and account in one place, with a named owner, a current stage and a next step against each. The difference is who decides the shape of those records and the logic that moves them.

In practice the word “custom” covers a very wide range of work, and much of the confusion about cost starts here. At one end is a focused system for a single sales team: leads arrive from a website form and a few other channels, move through one pipeline, collect calls and notes, and close. At the other end is a system several departments depend on, with custom objects for projects, contracts or service requests, approval chains, integrations with accounting and operations, and years of historical data brought in from older tools. Both are custom CRMs. They are not remotely the same project, and they should never be priced as if they were.

It helps to separate three kinds of work that buyers often merge into one quote:

• Configuration — setting up stages, fields, users and rules inside an existing platform, using the options it already provides.
• Customisation — extending an existing platform with scripts, add-ons or connected apps where its standard options stop.
• Custom development — designing the data model, interface, permissions and logic from the ground up, so the system does what the process requires and nothing it does not.

Each has a different pricing structure, a different kind of ongoing cost and a different answer to the question of who controls the system later. A quote only makes sense once you know which of the three you are buying, and a vendor who blurs them is making your comparison harder than it needs to be.

There is no responsible one-price answer to what a custom CRM costs in India, because two systems that are both called a CRM can differ enormously in the work they need. Any single figure quoted without seeing your process is either a floor for the smallest possible build or a guess dressed up as a benchmark. What can be answered precisely is what the budget follows: scope.

Scope sits at the centre of every CRM estimate, and five decisions surround it — users and roles, the data model, workflows, automation and integrations — with data migration added whenever there is existing data to bring across. Change any one of them and the estimate moves. Add a second sales team with its own visibility rules, and permissions work grows. Add an approval step before a quote is sent, and workflow logic, notifications and audit history grow with it. Connect accounting, and you inherit that system’s data rules as well as your own.

So the honest structure of a CRM price looks less like a product price and more like an engineering estimate. It usually contains these parts:

• discovery and scoping, which turn the sales process into a written specification;
• design of the interface and the data model;
• build of the modules, roles, workflows and automation in scope;
• integrations and data migration, each estimated against the real systems and data involved;
• testing, deployment and handover;
• hosting, support and maintenance after launch.

When you compare quotes from different vendors, compare them line by line against that structure. A lower number frequently means a line has been left out rather than delivered more efficiently. Migration and integrations are the lines most often missing, and they are also the lines most likely to surprise a buyer halfway through a build.

The same logic explains why seat counts are a poor guide. A subscription platform charges per user because its cost is spread across many customers. A custom build costs what the system requires to design, build, test and run, and adding one more salesperson to a well-designed role changes very little. Adding one more role changes a great deal more.

Branditify publishes a starting price rather than a package: a Branditify CRM build starts at ₹40,000 and sits in the “Standard system” band, while custom software development starts at ₹60,000 for a project. Both figures are entry floors — the minimum focused scope for that kind of work — and every real build is priced from its agreed scope.

The CRM figure is the starting point for a system shaped around a sales pipeline. The CRM and sales systems Branditify builds cover lead capture, pipeline ownership, customer and account records, follow-ups, quotes and clean handover, fitted to how a team already sells.

The ₹60,000 figure is the entry point of the custom software development service, which becomes the more relevant reference when the “CRM” is really a wider operational tool with a sales process inside it.

Neither figure describes what a multi-team CRM with several integrations and a large migration will cost, and neither is presented that way. They tell you where a focused first scope begins. The full list of published starting prices, with the scope notes behind each, sits on the pricing page.

The rest of this guide explains what moves a budget up from a starting point, so you can decide which of those things your business actually needs and which can wait.

Custom CRM development makes sense when a configured platform cannot fit the process, the integrations or the ownership the business needs; when a platform can fit all three with its standard options, configuring it is usually the more sensible first step. The decision is worth making explicitly, because it changes what you are pricing and what you will be paying for later.

When configuring a platform is the better call

Configuration wins when your sales motion resembles the process the platform was designed around: enquiries, a pipeline, deals and contacts. The integrations you need already exist as supported connectors. Your team is willing to adapt some habits to the tool. And a recurring per-user subscription is an acceptable way to pay, with the vendor’s roadmap deciding what changes next. In that situation, custom development buys very little that configuration cannot, and a mature platform brings polish that a new build takes time to earn.

When custom development earns its cost

Custom development starts to make sense when the gap between process and platform becomes structural rather than cosmetic. The signs tend to look like this:

• The records you track are not really deals — they are site visits, admissions, policies, service contracts or project bids — and the platform forces them into a shape that loses meaning.
• Approvals, pricing rules or handovers between teams need logic the platform can only approximate with workarounds that someone must maintain.
• A core system such as accounting, an ERP, an operations tool or an internal database has to stay in sync, and no supported connector does what you need.
• You need control over where data lives, how access is granted and how the system changes, rather than accepting a vendor’s terms and release schedule.
• The team spends more effort working around the tool than working the pipeline, and adoption has stalled because of it.

The middle route buyers overlook

There is a third option: keep a platform for what it does well and build the custom part around it — a quoting module, an integration layer, or a portal that feeds the CRM. This can be the right answer, but it carries its own cost: two systems to maintain, and an integration that must keep working as both sides change. Price the integration and its upkeep honestly before choosing this route on the assumption that it is the cheaper one.

Before any vendor conversation, it is worth reading how a custom CRM compares with the major off-the-shelf platforms on fit, control and total cost structure.

Six scope decisions move a CRM budget more than any others: users and roles, the data model, workflows, automation, integrations and migration. Each can sit at a simpler or a larger scope, and each carries one question worth asking early, before anyone estimates anything. The table after this chapter sets them side by side; what follows explains why each behaves the way it does.

Users and roles

A simpler scope is one team with a few roles, such as reps, a manager and an admin. A larger scope is several teams with layered permissions: branch or regional managers, a finance team that sees commercial terms, perhaps partners who see only their own records. Ask early who sees and edits which records, because that answer shapes the data-access design, the interface each role opens on and the testing needed to prove the rules hold.

Data model

A simpler scope tracks leads, contacts and deals, the records almost every sales team shares. A larger scope adds custom objects linked across departments — projects, contracts, service requests, bookings or assets — each with its own fields, stages and relationships. Ask early which records the business really tracks, as opposed to the ones it could track, since every object added reaches into screens, reports, permissions and imports.

Workflows

A simpler scope is one pipeline with simple stages that a record moves through in order. A larger scope has multiple pipelines with approvals, conditional stages and handovers between teams. Ask early where handoffs and approvals happen today, because formalising them in software is valuable only where the business genuinely relies on them.

Automation

A simpler scope covers reminders and assignments: an owner set when an enquiry arrives, a follow-up created when a quote goes quiet. A larger scope runs rules across teams and channels, with escalations and messages that leave the system. Ask early which steps must never be automatic, because those exclusions define the safe edges of every rule.

Integrations

A simpler scope connects email and website forms. A larger scope reaches accounting, ERP, telephony or messaging, often in both directions. Ask early which systems must stay in sync, and confirm what access each one actually provides before anyone estimates the work.

Migration

A simpler scope is a clean import from spreadsheets the team already keeps tidy. A larger scope means cleaning years of records from several tools, with duplicates, gaps and conflicting histories. Ask early who owns data cleanup, because the decisions it requires can only be made inside the business.

The six decisions compound rather than add. A second team with layered permissions also needs its own pipeline views, its own automation rules and its own reports. A new custom object also needs import rules, integration mapping and access control. That is why a CRM budget cannot be assembled by pricing features in isolation, and why the questions in the right-hand column are where honest scoping begins. Scope sets the budget, and these six questions set the scope.

Roles and permissions affect a CRM budget because every distinct job the system opens on needs its own view, its own rules for what can be seen and changed, and testing to prove those rules hold. The number of people logging in matters far less to a build than the number of distinct roles and how finely visibility has to be drawn.

A common and sensible baseline has three roles. A sales rep works their own and assigned records, the activities and contacts on those accounts, and their own follow-ups and tasks. A sales manager sees the whole team’s pipeline, ownership and reassignment, stalled deals and stage ageing across owners. A founder or admin has broader visibility and manages users, roles, and stage or field configuration where that has been scoped. This shape is well understood, and it is a reasonable foundation for a first release.

What makes permissions expensive

• Visibility by territory, branch, product line or customer segment, rather than by owner alone.
• Field-level restrictions, such as commercial terms visible to some roles and hidden from others on the same record.
• Shared ownership, where two teams work one account with different responsibilities.
• External users, such as channel partners or franchisees, who must see only their own records.
• Audit requirements that record who viewed, changed or exported what, and when.

Each of these is legitimate, and many businesses need at least one. Each also multiplies the cases that must be designed and tested, because a permission rule that fails quietly is worse than no rule at all: people trust it.

Different desks, same pipeline

Roles also change what the interface opens on. A rep needs today’s follow-ups and the enquiries nobody has touched yet. A manager needs to see where the pipeline is stuck and whose workload is uneven. A founder needs what is close, what is large and what needs a decision. Designing these views is real work that belongs in the estimate, but it is often where adoption is won, because each person opens the system on their own job rather than on a generic list of records.

The data model is the largest structural decision in a custom CRM, because it defines which kinds of record exist and how they relate, and therefore what every screen, report, rule and integration has to handle. A simple model costs less to build and less to change; a model that mirrors several departments costs more everywhere downstream.

The baseline set is familiar: leads, accounts or companies, contacts, opportunities, activities such as calls, messages and notes, quotes and proposals, tasks and follow-ups, and stage history. Most sales-led businesses can run on that set with a considered list of custom fields. The card on a pipeline board is only a summary; the record underneath it is what makes the system useful.

Where the model grows

The model grows when the business tracks things that are not deals. A real estate developer may need units, site visits and bookings. A training institute may need courses, batches and admissions. An equipment supplier may need installed assets, service contracts and renewals. Once those objects exist, each needs its own fields, its own relationships to accounts and contacts, its own permissions and usually its own stages.

Relationships matter as much as objects. One contact belonging to several accounts, one opportunity involving several products, one account with a parent company and branches: each is simple to describe and non-trivial to build well, because every list, filter, report, import and integration has to respect it.

How to keep the model honest

The discipline is to model what the business actually tracks and acts on, not everything it could conceivably record. A useful test for every proposed object or field is three questions: who enters it, who uses it, and what decision changes because it exists. Fields that fail the test become clutter, and clutter is one of the quieter reasons salespeople stop keeping a CRM up to date. A lean, well-related model is cheaper today and easier to extend in a later phase.

Workflows move a CRM budget in proportion to how many distinct paths a record can take and how many points need a human decision. One pipeline with simple stages is a modest build; several pipelines with approvals, conditional stages and handovers between teams involve substantially more logic, interface and testing.

A stage is more than a column on a board. In a well-built CRM each stage carries its own requirements: a named owner and a first contact at New; a recorded requirement, a decision maker and a timeline at Qualified; a version-controlled quote, the date it was sent and a booked follow-up at Proposal; recorded objections and revisions at Negotiation; an agreement, a delivery owner and a written handover at Won. Enforcing those requirements, rather than merely displaying them, is where workflow scope really lives.

What adds workflow scope

• Separate pipelines for different products, channels or customer types, each with its own stages and fields.
• Approvals for discounts, non-standard terms or quotes above a limit the business sets, with an approver, a recorded decision and a route back when something is rejected.
• Quote and proposal handling with versions, what changed between them, internal sign-off and the date each version went out.
• Handover from sales to delivery, onboarding or customer success, carrying the agreed scope, contacts, documents, commercial status and promised dates.
• Rules that stop a stage change until the information that stage requires exists.

Before deciding how much of this the CRM should formalise, find out where handoffs and approvals really happen today — in a message thread, on a call, in a spreadsheet someone emails round. Formalising a handoff the business already runs well can save real friction. Formalising one nobody follows is expensive and changes nothing, because the team will route around it.

A won deal deserves particular attention. When the record simply closes, everything sales learned disappears with it. When it hands over to a named next owner with the accepted scope and the dates the customer was promised, the CRM protects the relationship after the sale as well as before it. That handover is often a small addition to scope with an outsized effect on how the business delivers.

Automation moves a CRM budget by the number of rules, how conditional they are and how many teams and channels they cross. Reminders and assignments within one team are a modest scope; rules that route work across teams, send messages on external channels and escalate through management are a larger one, and each needs handling for the cases where something goes wrong.

The rules that repay their cost first are usually the chasing people forget. Assign an owner when an enquiry arrives and create a first-contact task. Create a follow-up when a quote has had no response for a configured period. Raise a deal on the manager’s exception list when nothing has been logged against it. Stop a won deal from closing until a delivery owner is attached. Each follows one shape — trigger, condition, action, owner — and writing every proposed rule in that shape is the fastest way to scope automation accurately.

Which steps should never be automatic

The early question in automation is not what to automate but what must never be automatic. Sending pricing to a customer, changing agreed terms, marking a deal lost, messaging a customer from a personal account, or reassigning a senior account are usually decisions a person should make. A good scope names these exclusions as clearly as the rules themselves, and nothing should run by default until it has been agreed with the people accountable for the outcome.

AI-assisted features

AI-assisted features can be scoped into a CRM where they are genuinely useful: summarising a long account history, suggesting the next action on a stalled deal, identifying stale opportunities earlier, drafting a follow-up for a person to review and send, or surfacing anomalies in the pipeline. Treat each as its own line in the scope, with its own cost and its own rule about what a person must check. They assist a salesperson; they do not sell, qualify or close on their own, and none of them should be assumed to be included.

If the automation you need reaches beyond the CRM — into support, operations or internal tools — it is often cleaner to plan it as a dedicated AI agents and automation scope than to bolt it onto the CRM estimate later.

Integrations change a CRM budget less predictably than any other driver, because the cost depends on what the other system allows, not only on what the CRM needs. Email and website forms are generally the simpler end; accounting, ERP, telephony and messaging integrations sit at the larger end, because they involve two-way data, matching records and handling failures.

Every integration should be confirmed against the access that system actually provides — an API, a database, an export or another available route — before it is estimated. No integration should be assumed from another product’s marketing page, and no vendor should promise one before checking.

Capturing enquiries

Website forms are usually direct capture into the CRM. Email enquiries can be forwarded or connected. Calls and walk-ins are logged by the team. Ad and lead sources can be brought in where an export or API exists, and existing files can be imported. Every captured record should keep the source it came from, which is what makes source reporting trustworthy later.

Email and calendar

Logging emails against the right account, and booking meetings that appear on both the CRM record and the salesperson’s calendar, are the integrations a team notices most in daily use. The scope questions are practical: is it one-way logging or two-way sync, which mail and calendar systems the team runs, and how personal or confidential messages are kept out of shared records.

WhatsApp and messaging

WhatsApp and other messaging channels can be connected to a CRM where the platform supports it, through the access that platform provides for business use. The scope depends on what that access permits: capturing enquiries, logging conversations against a record, or sending approved messages from inside the CRM. Conversations on a salesperson’s personal phone are a separate matter, and a scope should say plainly what will and will not be captured.

For the follow-up side of messaging, the guide to a WhatsApp lead follow-up system explains how that flow is usually structured before it is connected to anything.

Telephony

Telephony matters for teams that sell by phone. An integration can log calls against a record, attach the outcome, and create a follow-up task once the call ends. Where the business uses a calling system with available access, this is scopeable; where calls happen on personal mobiles, logging usually stays a manual step, and the CRM should make that step quick rather than pretend it is automatic.

Accounting, ERP and operations

Connecting the CRM to accounting and billing, ecommerce, support or operations systems lets a won deal become a customer and invoice record, or lets sales see delivery and fulfilment status on the same account. These are the heaviest integrations because both systems hold overlapping data. Someone must decide which system is the source of truth for each shared field, how duplicate records are matched, and what happens when one side is unavailable or rejects an update.

When the CRM is one part of a wider operational system, it is worth understanding how ERP and operations systems are scoped, because the boundary between the two affects both budgets and both maintenance plans.

Reporting affects a CRM budget by how far it reaches: pipeline reporting built on the CRM’s own records is a contained scope, while cross-system analytics and executive reporting are a separate dashboard project. Deciding which of the two you need keeps the CRM estimate from absorbing work that belongs elsewhere.

Reporting that belongs inside the CRM answers the questions a sales team asks about its own pipeline:

• pipeline by stage — what is open, and where;
• lead ageing — how long records have sat untouched;
• owner activity — what each owner has moved;
• conversion by stage — where deals actually stop;
• source — which channels produce work;
• stuck opportunities — nothing logged, nothing next;
• forecast, where scoped, from stage and expected close date.

What moves reporting cost is rarely the chart itself. It is the data behind it: whether stage history is recorded reliably, whether close dates are kept current, whether sources were captured at entry, and whether records brought in during migration are clean enough to report on. A forecast built on close dates nobody maintains is an attractive screen with no decision value, so the workflow rules that keep data current are part of the reporting scope too.

When reporting has to combine the CRM with finance, operations or marketing data, treat it as a separate dashboards and analytics build with its own scope rather than an extension of the CRM.

Migration is often the least visible and most underestimated line in a CRM budget, because its cost depends on the condition of your existing data rather than on the new system. A clean import from well-kept spreadsheets is a small scope; cleaning years of records from several tools is a project in its own right.

The usual sources are spreadsheets, an existing CRM export, contact databases, historical opportunities, and customer and account lists. What decides the outcome is the data itself:

• Data quality — blank, stale and inconsistent records.
• Format — how each export is structured, and whether that structure stayed consistent over time.
• Duplicates — the same account under several names, or the same contact in several sheets.
• Field mapping — which old field becomes which new one, and what happens to fields with no equivalent.
• History — whether activities, notes and stage changes came with the export, or only the current state.

Who owns data cleanup

Ask early who owns data cleanup, because the answer changes the estimate. A developer can build import scripts, deduplication rules and validation reports that flag problems. What a developer cannot do alone is decide which of two conflicting records is correct, whether a dormant account should come across, or what an old status label meant three reorganisations ago. Those decisions need someone inside the business with the knowledge and the authority to make them, and their time belongs in the plan.

A safer way to migrate

1. Take a representative sample of the real data before committing to a migration scope.
2. Agree the field mapping and the rules for duplicates, blanks and conflicts in writing.
3. Run a trial import into a test environment and review it with the people who know the records.
4. Decide what does not come across, such as leads dormant beyond an agreed point, and where that archive will live.
5. Freeze or reconcile the old tools during the final import, so records are not being edited in two places.

No migration should be promised as lossless before a sample of your actual data has been examined. A vendor who offers that promise without looking has priced a migration they have not yet understood.

APIs, mobile requirements and security each add scope in their own way, and each is cheaper to design in from the start than to retrofit. None of them should be assumed in either direction; each should be written into the scope at the level actually required.

APIs

A CRM needs an API of its own when other systems must read from it or write to it: a website pushing enquiries in, an operations tool pulling won deals out, or a reporting layer reading pipeline data. An internal API used by one known system is a contained scope. A documented API designed for several consumers, with authentication, limits and versioning, is a larger one. Ask which systems need access, in which direction, and who will maintain those connections after launch.

Mobile

Mobile access usually means one of two very different things. The first is responsive web: the same CRM working in a phone browser, with a compact view for the day’s tasks and calls. That is a normal part of a well-built CRM. The second is a native mobile app, with offline access, device features or push notifications, which is a separate build with its own design, development, testing and store releases. Decide which one field teams genuinely need before either is priced, and keep a native app as its own line rather than hiding it inside the CRM estimate.

Security and access

Security requirements should be scoped explicitly for each project: how users sign in, whether two-step verification is required, how roles are granted and revoked when people leave, where data is hosted, how backups and restores work, what activity is logged, and who can export records. Customer data is commercially sensitive, and a departing salesperson with an unrestricted export is a real exposure. If a specific certification or compliance standard applies to your business, name it at the start, because it changes the build and should never be assumed to be included.

Testing, deployment and maintenance belong in a CRM budget from the first estimate, because a CRM is a live system the sales team depends on every day, not a finished artefact. A quote that treats the build as the whole cost leaves out the work that keeps the system trustworthy.

Testing

Testing a CRM means more than checking that screens load. It means proving that each role sees only what it should, that automation rules fire under the right conditions and stay silent otherwise, that integrations handle failures without corrupting records, and that migrated data matches the agreed mapping. User acceptance testing with the people who will use the system — reps, managers and whoever owns the data — is where process gaps surface, and it needs time from your side as well as the vendor’s.

Deployment and rollout

Deployment covers the production environment, hosting, backups, the final data import and access for every user. Rollout covers the human side: training by role, a clear date when the old tools stop being the record, and someone accountable for answering questions in the first days of use. A CRM that launches without a cut-over date tends to run alongside spreadsheets indefinitely, and a system half the team ignores cannot give anyone a true picture of the pipeline.

Maintenance

After launch, plan for hosting, monitoring, security updates, bug fixes and small changes as the sales process evolves. Integrations need particular attention, because a change on the other system’s side can break a connection without any change to the CRM. Agree in advance what maintenance covers, how change requests are estimated, and who is responsible when a connected system changes. Maintenance is usually clearest as its own recurring arrangement rather than an unspoken expectation folded into the build price.

A phased build is usually the most sensible way to buy a custom CRM: release a focused first version the sales team uses daily, then extend it based on how the process behaves inside the system. A mature CRM is rarely designed correctly in one pass, because many of the most useful requirements appear only once people are working in it.

What a sound first release includes

• Lead capture from the channels that matter most, with the source kept on every record.
• One pipeline with stages that carry real requirements, not only labels.
• Accounts, contacts, activities, tasks and follow-ups held on one record.
• A small set of roles, typically rep, manager and admin, with clear visibility rules.
• The handful of automation rules that stop enquiries being forgotten.
• Basic pipeline reporting built on data the team is actually entering.
• A migration of current, active records rather than the full history.

What usually waits for a later phase

• Additional pipelines for other products, teams or regions.
• Approval chains and advanced quote handling.
• Heavy two-way integrations with accounting, ERP or operations systems.
• Historical data beyond what is needed to work current accounts.
• Forecasting and cross-system reporting.
• AI-assisted features, a native mobile app and access for external users.

Phasing is also a budgeting tool. It lets a business commit to a defined first scope, see the system in use, and fund the next phase with evidence from its own pipeline rather than assumptions made before anyone had logged a call.

Phasing does not mean building something disposable. The first release should sit on a data model and a permission structure that later phases can extend without rework, and that is the one area where extra design effort early generally costs less than changing the foundation later — a principle explained more broadly in the breakdown of what drives custom software development cost.

A useful CRM brief describes your sales process, records and constraints in enough detail that different vendors are estimating the same system. Without one, quotes differ mainly because each vendor has imagined a different project, and the comparison tells you nothing.

1. Map the sales process as it runs today. Where enquiries arrive, who picks them up, what happens at each stage, where approvals and handovers occur, and where things currently go missing.
2. List the records. Leads, accounts, contacts and deals, plus any objects specific to your business, with the fields that genuinely matter on each.
3. Name the roles. Each distinct job, what it needs to see and edit, and what it must not.
4. Write proposed automation as rules. Trigger, condition, action and owner for each, plus a separate list of steps that must stay manual.
5. List the systems to connect. Each with its purpose, the direction of data, and whether it offers usable access.
6. Describe the data to migrate. The sources, their rough state, how much history matters and who will own cleanup.
7. State the non-negotiables. Hosting, security, mobile needs, any compliance requirement and your expectations on ownership of code and data.
8. Separate the first release from later phases. Mark what must exist on the first day of use and what can wait.

Where you can, share a small, anonymised sample of real data with shortlisted vendors. Nothing makes a migration estimate meaningful faster, and a vendor’s reaction to it tells you a good deal about how carefully they will treat the rest.

The most useful questions before requesting a CRM quote test whether a vendor has understood your scope and priced all of it, not only the visible screens. Ask them of your own team first, then of every vendor you shortlist.

Questions for your own team

• Who sees and edits which records, and where does that differ from today?
• Which records does the business really track and act on?
• Where do handoffs and approvals actually happen?
• Which steps must never be automatic?
• Which systems must stay in sync with the CRM, and which one is the source of truth for each shared field?
• Who owns data cleanup, and how much of their time is available for it?
• What, specifically, would a configured platform fail to do for us?

Questions for every vendor

• What exactly is included in this estimate, and what is excluded?
• Were the integrations estimated against confirmed access, or on assumption?
• Was migration estimated from a sample of our data?
• How will roles and permissions be tested before launch?
• What does the first release contain, and what is deferred to later phases?
• Who owns the source code, the hosting account and the data once the system is live?
• What does maintenance cover after launch, and how are changes estimated?
• What happens to the estimate if scope changes during the build?

A vendor who answers these clearly, and who asks you similar questions before quoting, is estimating your CRM. One who offers a single figure before asking any of them is estimating a CRM in general — which is the one thing no business actually buys.