AM-IT CRM: one system from first enquiry to final invoice

AM-IT needed two things at once: a website that explains the work and produces enquiries, and a system to run everything that follows. Without one, an enquiry would start in an inbox, become a proposal in a document, a project in a task tool and an invoice in accounting software, with the history split between them and retyped at every step. Off-the-shelf tools covered parts of this, but not the way AM-IT works: proposals that turn into projects with milestones, milestones that turn into invoices, and money that has to be reported on three different bases — what was agreed, what was invoiced and what was actually received.

We built it the way we recommend clients do: in thin slices, in the order money flows through the business, and only one slice ahead of real need. The public website came first, then the content system behind it, then lead capture, the sales pipeline and proposals, then projects and finance. A written domain dictionary defines every record, status and permission before code is written. Two decisions from it shape the whole system. A lead is not a separate table but a deal at an early stage, and a client is a company at a later lifecycle stage, so converting one into the other never loses history. And every project stays permanently linked to the deal it came from, so the full sales history is always one click away. Financial records are protected in the database itself, not only in the interface. Once an invoice is issued, its key fields cannot be edited and it cannot be deleted; payments cannot be altered; a sent proposal is frozen. Corrections happen the way an accountant expects: through credit notes, voids and reversals that leave the original record intact.

AM-IT's website and CRM run as a single application. Website enquiries arrive in the CRM as deals with their source and landing page attached, and the same records carry through proposals, projects and invoicing without being retyped. Corrections to financial records leave a full history rather than overwriting it. More than 900 automated tests run on every change. Lead capture, the pipeline and proposals are live; the projects and finance modules are built and going through acceptance testing before they carry live financial records.

Keeping money correct was the hardest part. Contract value, invoiced value and cash received happen on different dates and are easy to mix up in reports, so every figure in the system states which of the three it is. Rules such as "an issued invoice cannot change" are enforced by database triggers as well as by the application, and automated tests confirm the database rejects edits that would rewrite financial history. The system is also built so it could serve more than one organisation later without a rewrite: every record carries its organisation and all data access goes through one scoped layer.