webapp Case study

CRM Operator PWA

Sales and support staff were working out of a desktop admin that assumed they were sitting down. The people who actually needed it were standing at a counter with a customer, which is a different tool.

Back to projects All case studies CRM operations showcase

The business problem

A CRM that only works at a desk is a CRM that gets updated later, from memory, or not at all. The in-person side of the business needed order entry, customer lookup and follow-up handling to happen at the moment of the conversation, and the WordPress admin is not usable that way on a phone.

What I delivered

a2-crm-plugin, a modular WordPress CRM currently at version 3.2.17, focused on in-person store operations.
Operator inboxes with assignment, unread state and handoff, so a follow-up belongs to someone specific rather than to everyone.
In-person order forms with editable payment and source dropdowns that can be managed from inside the modal, so a new payment method does not require a developer.
A manual product insertion action for the cases the catalogue does not cover, which in a jewellery shop is more common than it sounds.
Internal reporting built on the same data, so the numbers management sees come from what operators actually recorded.
Configuration held in a gitignored config file with credentials preferred in environment variables or wp-config constants.

Technical approach

Modular structure rather than one large plugin file, because a CRM accretes features and the ones that arrive later must not require touching the ones that work.
It runs on WordPress's own database layer and capability system rather than introducing a parallel auth model, so access control is the one the site already has.
Vanilla JavaScript on the front end. A CRM used from a counter on variable connections is not the place for a framework payload.
Editable dropdown lists are stored as data rather than defined in code, which is what keeps ordinary operational change out of the deployment path.
Credential material is kept out of the repository entirely, with the sample config committed and the real one ignored.

Result and evidence

Store staff record orders and follow-ups at the counter, in the conversation, rather than reconstructing them afterwards. The plugin is in maintenance and has been iterating on in-person workflows through the 3.x line.

Commercial value

The value of a CRM is entirely a function of whether it gets updated. Making it usable at the point of the interaction is what decides that, far more than any feature it has.

implementation-brief.readme

Readable implementation brief

implementation_brief {
  project: "CRM Operator PWA"
  plugin: "a2-crm-plugin v3.2.17, modular WordPress CRM"
  stack: "PHP, vanilla JS, WordPress DB layer, MySQL"
  focus: "in-person store operations at the counter"
  features: "operator inbox, assignment, unread state,
             in-person order form, manual product insertion"
  operator_config: "payment and source dropdowns editable
                    from the modal, stored as data"
  auth: "WordPress capabilities; no parallel auth model"
  secrets: "config.php gitignored; env or wp-config constants"
}

What this project shows

Version 3.2.17 with a maintenance status says more than a feature list does. This is software that has been in real use long enough to have been shaped by it.

Letting operators manage their own dropdown values is a small decision that removes a standing stream of developer requests. I look for those.