How to choose your first customer data project

Start with the last decision that got stuck

A request to connect all customer data is difficult to finish because it does not name a decision. Start with a recent moment: the budget review where nobody could explain which leads signed, the sales call that repeated a customer's answers, or the handover that stalled between two teams.

Write down who needed the answer, what they did instead and what would have changed if they had known it. A report that makes a meeting look complete is different from information that changes a budget or a follow-up. The first project should earn its place in an existing decision, with a person responsible for using it.

Compare a few candidate questions

Choose questions that recur often enough to be useful and have source records your team can inspect. A commercially important question with no accessible evidence may need groundwork before a build. A question your existing CRM already answers reliably may need a clearer report rather than another platform.

Compare each candidate using the same criteria. Include the effort people spend preparing the answer today, but avoid turning every estimate into a promised saving. Name what you know and what still needs checking. The best first scope is often the one your team can judge clearly, rather than the one with the longest list of integrations.

1. Name the decision and the person who owns it.
2. Describe how often the question comes up and what happens without an answer.
3. List the records that would support a defensible answer.
4. Check who can provide access and explain those records.
5. Agree what action the answer would help someone take.

Write the result in language people agree on

Consider a sales example: people who booked a call and then signed a contract within 30 days. This is an illustrative starting rule, not a claim about your business. Your teams still need to agree which booking and signature events count, which system records them, and how customer records are linked.

A CRM stage and a received payment describe different business events. Choose the one the decision needs and keep the distinction visible. Specify the period, known gaps and source update timing. If an event arrives late, the team should understand how that affects the answer instead of treating every change as a disagreement.

Decide how you will accept the first result

Before building, select examples the business understands. Include a customer who should qualify, one who should not and one with an uncertain match or missing record. Trace each back to its original system. A useful acceptance check explains both the answer and the limits of the evidence behind it.

Record the current way of answering the question so you have a baseline. After the first result is available, observe whether the owner can complete the same decision and explain the count. Measure preparation effort and unresolved questions if they matter to the job. A connected source alone does not establish that the business has made progress.

Use the result before expanding the project

Bring the answer into the next real meeting or handover. Ask who used it, what they checked and what they did next. If the team still returns to a spreadsheet, find out what the spreadsheet provides: a missing definition, a familiar view, an exception or a person who can explain the number.

Expand when you understand the first result's place in the work. The next scope might add a source, a team or another outcome. With DataGlue, the first conversation starts from that decision and its records. The architecture review maps the proposed build; scope and price are agreed before work begins.