In this article
On Monday morning, the owner of a small renovation business opens the advertising dashboard. There are new inquiries. The team chat tells a different story: forwarded numbers, voice messages and the question, “Has anyone called this customer?” One salesperson assumes a colleague has taken it. The colleague assumes the opposite. By lunchtime, the customer has booked another company.
This is a teaching example, not a report about a particular business. It reveals a more useful starting point than “We need an AI-powered CRM.” The owner needs every inquiry to have a responsible person and a clear next step. That distinction is where useful software begins.
1. Find the moment when work breaks down
Before discussing design, ask a future user to show you a recent case. Ask them to open the actual inquiry and walk through what happened, rather than describing an ideal process. Where did the number arrive? Where was it copied? How did they know whom to call? Where did they record the agreement? When did they need to ask the team for help?
In our example, the gap is between receiving an inquiry and making first contact. The initial goal becomes: “A salesperson opens the list, immediately sees their unhandled inquiries and knows what to do next.” That is something you can test. It also follows the GOV.UK Service Manual principle of understanding users and their task before testing assumptions with prototypes.
2. Describe one journey in ordinary language
Choose a first workflow with five actions: an employee adds an inquiry → the system saves it → a salesperson is assigned → that person records the conversation → the inquiry receives a next step and a due date. For each action, ask what information should remain in the system afterward.
Adding an inquiry records a name, contact, source and arrival time. Assignment adds an owner. A conversation adds a note, a status and a next action date. Use understandable statuses such as New, In progress, Waiting for a response and Closed. Record the outcome of a closed inquiry separately: an agreement, a rejection or another result. Closed does not automatically mean a sale.
3. Decide what to leave for later
The wish list often includes calling, newsletters, reporting, AI scoring and a polished executive dashboard. Each might be useful. But until you know the team can reliably hand off a single inquiry, these additions distract from the core test.
Start with an entry form, an inquiry list and a detail view. Staff can enter fictional inquiries manually during testing, allowing you to validate the workflow before an advertising integration is ready. Manual entry can also be a deliberate launch choice if responsibility and transfer procedures are clear. Persistence, permissions and recovery from errors belong in the first version; they are essential foundations.
4. Show the journey on paper first
Sketch three screens: the list, the detail view and the form. Give a future user a task: “A kitchen-renovation inquiry has arrived. Take responsibility and record that you need to call tomorrow.” Do not tell them where to click. If they cannot find an action or interpret a status differently, you have discovered something useful while changing a drawing is still easy.
A paper prototype tests clarity, not reliability. Follow it with a small working journey: submit the form, save the record on the server, reopen it and find the same information. A beautiful screen that loses changes after a refresh has not passed.
5. Give AI a specific brief
“Build a modern CRM” leaves too many decisions to the tool. Provide the user, the workflow, constraints and acceptance criteria. Adapt the brief below to your process. It is a starting specification, not a promise that one prompt will deliver a complete, secure product.
Build the first version of an advertising-inquiry system for a small team. Salespeople see only assigned inquiries; the manager sees all inquiries and assigns owners. Store name, contact, source, arrival time, status, owner, note, next action and due date. Include an entry form, list and detail view. Persist data on the server. Enforce permissions on the server, not just by hiding buttons. If saving fails, explain the problem and preserve the entered text. Repeated clicks must not create duplicate records. Do not add calling or newsletters. First propose the implementation and test plan, then carry it out.
6. Test the inconvenient cases
Start acceptance testing with the normal journey: create a fictional inquiry, assign a salesperson, add a note and schedule a next step. Refresh and reopen it in another browser under the same account. The changes should remain. Then sign in as a different salesperson: the first person’s inquiry must not become accessible through a direct link or a server request.
- Click Save twice: only one record should be created.
- Omit contact details: the form should explain what to fix.
- Interrupt the connection while saving: entered text should remain and success should not appear prematurely.
- Sign in again: the note and due date should still be present.
- Enter a known number: warn about the match without automatically merging different customers.
- Let two employees edit the same record: newer changes should not be silently lost.
Use fictional contacts in these checks. Test backup and restoration separately: an Export button alone does not prove the team can recover lost information. Before accepting real inquiries, assign someone to handle access, errors and ongoing support.
7. Let actual work determine the next feature
After a pilot, look at specific situations. Are any inquiries unassigned? Can the team see who contacted the customer and when? Does each open inquiry have a next step? Do people still need to duplicate everything in chat? Those answers matter more than the appearance of a dashboard.
If the workflow works but manual entry consumes time, an advertising-source integration may be the next task. If people confuse statuses, fix the wording and process first. If they forget follow-ups, test reminders. Each new feature should address an observed problem, or the application will grow while the work remains unchanged.
You can begin today: choose one recurring task, watch a real person do it and describe the path from input to outcome. A useful first application does not need to look large. It needs to make one important working day easier to understand.
Revised following reader feedback.
Discussion
Which task would you automate first? Share an example from your work.
Reader-provided name; not verified by the editors.
Loading…