Why the Front Line Ignores AI’s Advice
When front-line staff ignore AI’s advice, the usual problem is that the advice isn’t tied to their quotas and bonuses. Model accuracy comes second.
The system tells a sales rep to visit Dr. Zhang, but this quarter the rep’s bonus depends mainly on a few other hospitals, so of course the rep doesn’t go. Many projects that push AI recommendations to front-line staff end this way, and the post-mortem usually blames the model for being inaccurate.
My experience is that for AI to work on the front line, both ends have to be built together: headquarters’ allocation of resources at one end, and the front line’s daily execution at the other. And one has to sit inside the other. Build only one end and it usually doesn’t take hold.
Excel and the quarterly meeting in between
Take pharma. The CRM that reps use is a system of record. After visiting a doctor, they log an entry: who they saw, which product they discussed, for how long. Reps fill it in largely because the company checks. As a consultant I led a CRM rollout for a multinational pharma company. Getting the system live wasn’t hard. Getting people to fill it in properly was.
At the other end is sales operations at headquarters. Analysts export data from the CRM and other systems, work it into reports in Excel, and bring those to the quarterly meeting.
There’s almost no direct connection between the two ends. Headquarters’ allocation decisions reach reps layer by layer, through emails, meetings and whatever managers pass on. What really happens with reps each day travels up through hand-entered records and reporting up the chain, reaching headquarters months later and badly distorted.
A rep’s day
Each day, a rep is really making a series of decisions. Who to see today, and what to talk about? Preparing properly for one visit takes twenty or thirty minutes, going over what this doctor said last time, what concerns they raised and how their prescribing has changed. Most of the time nobody has that long. What to record afterwards? Right after the visit, turning a conversation into a dozen or so CRM fields is the part of the job reps find most tedious, so record quality is hard to keep up. Then comes the next step: whether to follow up with a paper, and when to come back.
What I’m trying to do with my AI CRM is have the system prepare a first answer for each of these decisions. Before the visit, a briefing is already prepared, and two minutes of reading is enough before going to see the doctor. After the visit, the rep speaks into their phone, and the system turns that into a structured record: updates to the customer profile, the doctor’s objections, compliance flags and a draft follow-up email. For what happens next, the system lines up the next step, and the rep accepts or vetoes it.
There’s a side benefit. Reps no longer fill in the CRM for its own sake. They get on with their own work, and the record comes along with it.
For the headquarters end I also built a product, called a CIU, which handles the periodic allocation decisions: who covers which customers, how much to invest, how performance is measured. Where it came from is explained in Annual Planning Is a Compromise.
One end sits inside the other
It’s easy to think of the two ends as two separate products, one for reps and one for headquarters. They’re closer to one sitting inside the other.
Headquarters sets the boundaries and the defaults: which doctors this rep covers, roughly how much to invest in each this quarter, what the current priorities are. These are allocation decisions, and not a good fit for an algorithm on the rep’s side to settle on its own.
Within those boundaries, the front line decides how to carry it out: out of the hundred-plus doctors a rep covers, whom to see first this week, what to discuss, and through which channel.
Then what actually happened, including what was vetoed, flows back to headquarters: which doctors the rep really saw, how they responded, which recommendations were turned down and why. When many reps veto the same kind of recommendation, it usually means some assumption at the allocation level is out of date. That’s the signal headquarters needs most and has always found hardest to get.
What happens if only one end is built
Build only the front-line end and you get Dr. Zhang from the opening. The recommendation engine is a separately purchased module, never connected to quotas, territories or bonuses, and however often it pushes advice, nobody listens. Quite a few of the NBA (Next Best Action) projects pharma companies have run in recent years got stuck here. They often came with a second problem as well: to give the model data to work with, reps were asked to fill in a few more fields. Their workload went up, and what they got back was advice like “consider visiting this customer soon,” which they already knew, because the data going in wasn’t very good to begin with.
Build only the headquarters end and you get a quieter failure. Headquarters uses a sophisticated model to work out the best coverage plan, turns it into slides and sends it down. Reps open the same CRM as ever, and nothing in it tells them to do anything differently today. The plan never gets past the slides.
A thought on choosing systems
My guess is that within a few years, systems of record and decision systems will split into two layers. The record layer will become standardized, with every vendor’s product more or less the same. The decision layer is where the real differences will be, and whoever can connect headquarters and the front line into a closed loop will have the edge there.
When I look at front-line AI tools now, the first thing I want to know is how their advice is tied to quotas and bonuses. If that hasn’t been thought through, then however many features a tool has, it will probably run into the same problem as the visit to Dr. Zhang.
