The problem
Sales and operations data lived in spreadsheets alongside a WordPress site. Adding a standard CRM meant a second platform, a second login, a second recurring bill and duplicated customer records.
What we built
Built a ten-module CRM as a native WordPress plugin on nine normalised database tables rather than post meta, keeping reporting queries fast as records grow. Added AI-assisted summarisation and drafting with agent review, plus an employee permission system scoping records by role.
The temptation when building a CRM inside WordPress is to store everything as custom post meta. It works in a demo. It degrades badly once reporting queries have to join across several meta keys and tens of thousands of rows.
We designed nine normalised tables with a dedicated prefix and proper indexes, and kept WordPress for what it is genuinely good at: authentication, roles, admin UI and content. The result queries predictably as the dataset grows and remains legible to whoever maintains it next.
The AI layer was scoped narrowly to the repetitive language work – summarise the interaction, draft the follow-up, extract the next action – with the agent reviewing before anything saves.
Building a CRM on post meta works until roughly [N] records. Then it stops, and migrating is more expensive than doing it right.