How to brief a custom customer relationship management system before you build

1. State the business problem and test whether custom is necessary

A customer relationship management system should help people manage customer work consistently. The project brief explains where the current process fails and what a better process must achieve. It should describe how people work and make decisions, as well as the information they need. A list of desired screens or a request to replace every spreadsheet leaves too many of those questions unanswered.

Start with observable problems. Enquiries may wait without an owner, quotations may be difficult to find, or delivery staff may receive incomplete handovers. Describe an example of each problem and its consequences. Avoid vague statements such as needing more automation unless you can explain which action should happen and why.

Then consider the alternatives. A clearer process, better configuration of an existing product or a small integration may solve the problem. Custom development becomes a more useful option when important workflows or constraints cannot be met reasonably by suitable existing tools. Ask for that comparison during discovery, rather than treating custom as a decision already made.

Write down the boundaries of the first release. A system that manages enquiries and handover need not also replace accounting, scheduling and stock management. List the systems that will remain and how the new work should connect to them. This helps suppliers distinguish essential integration from an ambitious replacement programme.

Finish the opening brief with an outcome that can be checked. For a fictional service business, every new enquiry might need a named owner, a next action and a visible handover when accepted. That defines useful behaviour without prescribing the database or interface before the team has investigated the work.

Our custom CRM work for Northern Ireland businesses begins with the workflow and the problem the system needs to solve.

2. Map the customer journey with the people doing the work

Bring together people from sales, administration, delivery and support. Ask them to walk through recent types of work using fictionalised examples. What arrives first? Who decides whether it is suitable? What information is needed for a quotation? What happens when a customer changes their mind? The differences between people's descriptions often reveal requirements.

Map stages in language the team already uses. Received, assessing, quoted, accepted and handed over may be enough to begin. For each stage, name the owner, entry condition, required information and next possible actions. Keep the definitions short enough that staff can use them during a busy day.

Pay attention to waiting. A record can be waiting for a customer, supplier, internal approval or appointment. Those situations may require different reminders and different visibility. A generic pending status hides why work is not moving. Decide which distinctions affect an actual decision and avoid creating statuses only to make the diagram look complete.

Exceptions deserve space in the brief. An enquiry can be duplicated, reopened, transferred to another team or closed without a quotation. A customer can have several concurrent opportunities. If the system assumes one ideal route, staff may return to private spreadsheets as soon as reality becomes more complicated.

Review the map with the people who will use it, not only the project sponsor. Ask them to identify missing steps and unnecessary repetition. The purpose is to agree a workable process before automating it. Copying a confusing process into software can make its weaknesses harder to change later.

Use a workshop exercise that follows one enquiry across the whole process. Give each team a fictional record and ask what they need to receive before they can act. Record every point where someone says they would telephone a colleague or check a spreadsheet. Some of those checks may be sensible human judgement; others may show missing information or unclear ownership. Do not automate all of them indiscriminately. Decide which handovers need a shared record, which need an approval and which can remain a conversation with its outcome noted.

• For each stage, record the owner and required information.
• Show waiting reasons and the next expected action.
• Include rejected, duplicate, reopened and transferred work.
• Check the map with sales, administration and delivery users.

3. Define records and the meaning of each important field

List the main things the system needs to represent: organisations, contacts, enquiries, opportunities, quotations, tasks and documents, for example. These are not necessarily separate screens. They are the records the team needs to connect. Decide how they relate before building a form that mixes everything into one long entry.

Distinguish an organisation from its people. One company may have several contacts, several locations and several opportunities. A contact may change jobs while the historical work still belongs to the original customer. Explain the real situations your team encounters so the design does not depend on an assumption that each customer has just one email address.

Create a small field dictionary. For each important field, include its purpose, format, whether it is required, who may change it and where it comes from. A date for the next action should have a shared meaning. If one team treats it as a promise to the customer and another as an internal reminder, a dashboard will not resolve the disagreement.

Use examples to expose ambiguity. Is customer value the amount quoted, invoiced or paid? Does closed mean rejected, delivered or simply no longer being pursued? Agree definitions before asking for reports. Otherwise the project can deliver technically correct calculations that answer different questions from those the business intended.

Minimise unnecessary collection. A field should have a reason to exist and someone responsible for its accuracy. Collecting extra information because it may be useful someday increases entry effort and creates more to manage. Guidance from the Information Commissioner’s Office on data protection by design supports considering necessity and privacy from the start, throughout the system’s life.

4. Describe permissions as actions and boundaries

A role list is a starting point, but labels such as admin and standard user are too broad to price or test confidently. Describe what each role can see and do. A salesperson may manage assigned opportunities, a team leader may reassign work and finance may need selected billing information without editing sales notes.

Make scope explicit. Does a user see all customers, only a team or only assigned records? Can they export information, delete a record, view sensitive notes or change an approved quotation? These actions can have different consequences and should not be bundled together simply because they appear on the same screen.

Include administrative work. Someone needs to invite users, remove access, correct mistakes and investigate problems. Define which actions require an audit record and what that record should show. For example, the business may need to see who changed an opportunity owner and when, particularly if an enquiry is left unanswered.

Consider absence and staff changes. How is work reassigned when someone leaves or goes on holiday? What happens to their tasks and historical activity? The system should support continuity without requiring colleagues to share a personal login. Include this scenario in demonstrations and acceptance checks.

Use fictional examples to test boundaries. Ask a user from one team to try viewing another team's restricted record through search, a saved link and an export. The expected result should be written down. A hidden menu item is not the same as a complete access rule, and a permissions matrix is useful only when its behaviour is verified.

5. Specify automation and integrations, including failure

An automation requirement should explain a trigger, conditions, action and exception. When a suitable enquiry is assigned, for example, create a task recording the next action for the owner. If no owner can be assigned, send the enquiry to a visible review queue. That description is more useful than asking for automatic follow up without explaining who is responsible.

For every integration, identify the authoritative source of each field. An accounting tool may own invoice status while the customer relationship management owns opportunity stage. Decide whether information travels in one direction or both. Updates in both directions require clear rules for conflicts and duplicate records. Name the business owner who can resolve uncertain cases.

Explain timing in terms of user need. Does an update need to appear immediately, within an agreed interval or during a scheduled import? Different answers affect design and monitoring. Avoid requesting immediate updates for every field without considering whether the business gains anything from it.

Failures are part of the requirement. A receiving system may be unavailable or reject a record because information is missing. Specify how staff discover the problem, where the failed item waits and who can retry it. Retrying should not create duplicate invoices, tasks or customers. Include a reference that helps the team investigate the original attempt.

Keep a human route for unusual work. Automation can save repetitive effort, but staff need to understand what has happened and how to recover safely. A visible activity record, clear status and documented override process can be more valuable than adding another rule that only the original developer understands.

Where the requirement is a focused portal or connection to an existing system, discuss it through our custom development service rather than assuming that the whole system must be replaced.

6. Treat data migration as a separate piece of work

Data migration is the process of moving existing information into the new system. It requires decisions about quality, meaning and retention, not just a file upload. Inventory the sources: spreadsheets, current customer relationship management exports, shared documents and records held by individual teams. Identify which sources are authoritative and which contain overlapping information.

Choose what actually needs to move. Active customer work may deserve a detailed migration while older information can be retained through an agreed archive. The choice depends on operational needs and the organisation's information responsibilities. Do not copy everything automatically simply because storage is available.

Agree rules for duplicates, incomplete records and conflicting values. Two entries with the same email address are not always the same customer relationship, and similar company names are not sufficient proof of a match. Identify cases that can be handled consistently and cases that need review by someone who understands the customer history.

Run a trial using representative data and reconcile the result. Check record counts, relationships, dates, ownership, attachments and selected examples from each source. A successful import message does not prove the information is usable. Staff should be able to follow a migrated opportunity through to its contact and relevant documents.

Plan the final changeover. Decide when the old system stops accepting edits, how changes made shortly before the move are captured and what happens if the migration must be repeated. Name the person who will decide whether to proceed or stop, and specify when that decision is needed. Keep the original information available in an appropriate controlled form until the agreed checks are complete.

• Inventory sources and identify the authoritative records.
• Agree what moves, what stays archived and what is removed.
• Document duplicate and exception handling rules.
• Trial the migration and check relationships, not just totals.
• Define the changeover window, final checks and recovery plan.

7. Build a hypothetical brief covering enquiries through to handover

Consider a fictional business where enquiries arrive by email and telephone. Sales staff prepare quotations, while a separate delivery team schedules accepted work. The main problem is that delivery receives incomplete information and sales cannot easily see which enquiries still need attention. This is a planning concept, not a delivered Podium customer relationship management or a claim about client results.

The first release covers contacts, enquiries, quotations, tasks and a handover for accepted work. Accounting remains in the current accounting product. Each enquiry has an owner and next action. Sales can record a quotation and its status. An accepted opportunity enters a handover queue only when the agreed information is complete.

The team defines required handover information: customer contact, agreed scope, relevant location, approved quotation reference and any delivery constraints. The delivery team can return an incomplete handover with a reason. That creates a visible task for sales, rather than a separate email conversation whose outcome never reaches the record.

Permissions follow responsibility. Sales can edit the opportunity and submit a handover. Delivery can accept it and add scheduling information. The team leader can reassign unresolved work. Sensitive notes have a separately agreed access rule. These are requirements to investigate and test, not assumptions that every customer relationship management should use the same roles.

A trial with fictional records should include a straightforward enquiry, a duplicate, a rejected quotation and an accepted job with missing information. The demonstration then shows how the system handles ordinary exceptions. The business can assess whether the workflow makes responsibilities clearer before asking for additional dashboards or automated messages.

The fictional sponsor can turn the example into a compact scope statement. Included: enquiry capture, ownership, quotations, next actions and delivery handover. Excluded for the first release: accounting replacement, stock control and customers managing their own information. Dependencies: access to approved source data and confirmation of the accounting integration route. Open questions: who resolves duplicates and which documents need migrating? This structure lets suppliers identify assumptions without presenting the concept as a fully designed product. It also makes later scope discussions more concrete because both sides can point to the original boundary.

8. Write acceptance criteria and a usable pilot plan

Acceptance criteria describe observable behaviour that must be present before work is accepted. Tie them to tasks and business rules. A new enquiry appears in the unassigned queue if no owner is chosen. A user cannot approve a handover with missing required information. A failed integration creates a visible issue without losing the original record.

Include reporting definitions. If the dashboard shows overdue enquiries, explain which date is used and which statuses are excluded. Test a few known fictional records and calculate the expected result manually. This checks meaning as well as arithmetic. A polished chart can still mislead if the team disagrees about what belongs in it.

Plan a pilot with representative users and a limited scope. Choose people who perform the actual work, including someone who handles exceptions. Give them practical tasks rather than asking whether they like the screens. Record where they hesitate, what information they cannot find and which work still escapes into email or spreadsheets.

Include accessibility in these tasks. Guidance from the World Wide Web Consortium recommends planning responsibilities across the project. Check whether users can complete important actions with their usual tools, understand validation messages and recover from mistakes. Training should explain the process, while the interface should avoid making people memorise hidden rules.

Agree how pilot findings are prioritised. Separate defects against the agreed behaviour from useful new ideas and genuine scope changes. Name the person who decides whether the first release is ready. A pilot becomes difficult to finish when every observation automatically expands the build without an explicit decision about necessity.

• An enquiry cannot disappear without an owner or review route.
• A duplicate can be identified and resolved using agreed rules.
• Restricted records remain inaccessible through direct links and exports.
• Required handover information is checked before submission.
• Reports match agreed definitions on known example records.

9. Complete the brief with operation, ownership and exit

A customer relationship management becomes part of the business's daily operation, so describe what happens after launch. Who helps a user, corrects a record, updates a rule or investigates an outage? Include support hours, responsibilities, escalation routes and the difference between routine administration and development work. An informal promise of help is not a complete operating plan.

Ask for training materials built around the actual workflow. New staff should learn how to receive an enquiry, maintain a next action, handle a duplicate and complete a handover. Include administrator guidance and a record of important business rules. A video tour of every menu can be less useful than a short set of task instructions.

Agree ownership and access for source code, hosting, backups, deployment, domains and subscriptions with other suppliers. Clarify licence terms and what the business receives at handover. A new supplier needs enough information to operate the service, not merely a folder of application files. Document known limitations and unresolved issues honestly.

Test data export before it becomes urgent. Decide which records, relationships and attachments the business must be able to retrieve and in what usable form. Ask how restoration and recovery will be demonstrated. An export that loses the connection between a customer and their opportunities may be insufficient for a later move.

Podium's custom customer relationship management service page provides the commercial context for discussing a brief in Northern Ireland. Bring your process map, record examples, existing systems and unresolved questions. The first useful decision may be an adaptation, integration or discovery exercise. A good brief helps establish that choice before the business commits to a full custom build.

Before signing, ask the proposed team to demonstrate how it would hand the system to another competent maintainer. The answer should cover documentation, access, configuration, deployment, backups and the location of decisions about business rules. No supplier can eliminate every future transition cost, but clear records make the dependencies visible. Ask the same question about data: can the business retrieve a meaningful sample of related records and attachments? Treat an unsuccessful demonstration as something to resolve in the scope, while it is still straightforward to clarify responsibilities.

• A named product owner and acceptance decision maker.
• Documented support, training and administrative responsibilities.
• Business access to the accounts and services required to operate.
• A migration, release and recovery plan with clear ownership.
• Usable data export, handover documentation and known limitations.