MR reporting software: what a manager should actually get from it

The reports that get used

A field manager has a narrow set of questions, and a reporting system earns its place by answering them without being asked twice.

• Call average — visits per working day per MR, against the company standard. The first number anyone looks at, and the easiest to inflate if check-ins are not verified.
• Coverage — what proportion of the assigned doctor list was actually seen this cycle, and which names were missed. More useful than call average, because it exposes an MR meeting the same easy ten doctors repeatedly.
• Doctor-wise frequency — how often each doctor was met against the frequency their potential grade calls for. This is where under-servicing of high-potential doctors shows up.
• Tour plan compliance — planned beat against actual movement, so deviation is visible without a phone call.
• Expense against budget — claimed travel and daily allowance per MR against the territory norm, with outliers surfaced rather than buried in a monthly total.
• Missed and late filing — who is filing DCRs on the day versus reconstructing the week on Sunday night. A leading indicator of every other number going soft.

Why the reporting hierarchy decides everything

Every number above is meaningless until the system knows who reports to whom. The standard Indian pharma structure runs MR → ASM → RSM → ZSM → NSM, but almost no company runs exactly that: divisions share territories, some roles are skipped, some managers carry their own doctor list alongside a team, and acting arrangements cut across the chart.

If the software cannot represent the real hierarchy, the rollups are wrong in a way that is hard to see and easy to act on. A manager who sees a team average that silently excludes two MRs will make a decision on it.

Ask specifically whether reporting levels can be added, renamed and reordered per company, whether a manager can hold both a team and a personal customer list, and how the system handles an MR who moves territory mid-cycle — that last case is where most reporting engines quietly double-count or drop a month.

Verified versus reported activity

The difference between a report a manager trusts and one they quietly discount is whether the underlying activity was verified at the point it happened.

A call average built from typed entries is a record of what an MR says they did. A call average built from geo-fenced check-ins — where the app required the MR to be physically within a set radius of the clinic, at a recorded time, with an optional photo — is a record of where they were. The numbers look identical on the dashboard. Only one of them survives a conversation with the MR.

This is worth being precise about rather than overselling: GPS verification proves presence at a location at a time. It does not prove a meeting happened or that it was productive. What it removes is the specific failure where a month of reports describes visits that did not occur.

Reports that change without a developer

The reporting requirement that arrives six months after go-live is the one that tests the product. A new division wants a different cut; the national sales manager wants expense broken down by beat rather than by MR; a compliance review wants a report that nobody specified at purchase.

If every new report is a vendor change request scheduled into a release cycle, you will stop asking. Ask instead whether an administrator can define a new report — its dataset, columns, filters and who may see it — from the admin interface, and whether a new customer inherits the full report catalogue without setup work.