Follow a request through delivery
A service business usually needs to connect enquiry, qualification, proposal, project work and follow-up. Building every possible CRM module at once can obscure that core path.
Start by tracing one real service request. Identify the owner at each stage, the information they need and the event that permits the next stage. Distinguish a sales status from a delivery status: “proposal accepted” does not mean “project complete”.
A useful first module set
| Module | Minimum useful record | Boundary to define |
|---|---|---|
| Enquiries | Contact, source, need, owner, next action | Duplicate and spam handling |
| Clients | Organisation and authorised contacts | Which team can access the client |
| Projects | Scope reference, state, responsible person | Who can approve scope changes |
| Tasks | Assignee, status, due context | Reassignment and completion rules |
| Communication | Thread or message linked to the record | Retention and private notes |
| History | Actor, action, object and time | Who may inspect the audit trail |
Billing, resource planning and document automation may be valuable later. Add them when a specific workflow and owner are clear. Do not label a generic notes field as a complete financial system.
Make the next action visible
A lead list becomes operational when every active enquiry has an owner and a next action. An impressive dashboard cannot compensate for records that no one is responsible for handling.
Show overdue or unassigned work using agreed definitions. Avoid metrics that reward status changes without checking actual outcomes. A closed lead should carry a reason, not disappear from history.
Verify boundaries with two accounts
A manager and a client should not see the same records by default. Test record ownership, attachments and search results under separate accounts. Put the rules on the server as well as in the interface.
Discuss business systems around a complete request-to-delivery workflow, then expand the module set after the team has used that path.
A practical question
Should billing be part of the first CRM release?
Include it when a defined billing workflow is essential to the first operational journey. Otherwise agree the handoff to the existing billing system and avoid presenting a generic amount field as an accounting module.