written · 3 min read
Automating around broken processes
At LinkedIn, account research meant pulling information from over 25 different sources, including systems, dashboards, offline material and external content, before a customer call. Automating that first pass has saved more than 65,000 GTM hours a year. I also wonder how much of the surrounding work could be removed. If people spend part of every review reconciling the same conflicting numbers, an agent can speed that up. It may also make the problem easy enough to live with that nobody fixes it.
Take a renewal review where the CRM, usage dashboard and finance spreadsheet show different contract values. Someone preparing it manually might notice the difference and ask a manager which number to use. An agent could follow its instructions to prefer one source and put a single figure in the brief. The reader may never see the disagreement. The person writing the instructions has made a choice that finance and sales may not have agreed on.
There may have been a good reason for the spreadsheet. Finance might have needed to track contract amendments the CRM couldn't handle. Even after the CRM adds that capability, people may keep using the spreadsheet because their reports depend on it. An agent built around the spreadsheet gives the team another thing to update when it eventually changes the process. Someone still has to arrange that work with finance and the people maintaining the CRM.
I'd follow one renewal through the process and ask why each review is there. If a standard contract goes to finance every month because two systems disagree, fixing the data could remove that review. An unusual term may still need someone from finance or legal to examine it. Sales may also have an incentive to favor a particular treatment when it affects the quarterly target, so an independent check can serve a purpose. Removing steps without understanding them could remove checks the company still needs.
Some disagreements are about what to do next. Sales might see declining usage as a reason to offer a discount, while customer success thinks the customer needs help with onboarding. Asking an agent for a recommendation won't settle that disagreement. Its instructions will favor some explanation or action, and the team needs to agree when that is appropriate. For cases where the evidence is unclear, the agent should show what it found and let someone responsible for the customer decide.
Once the team has agreed on the rules, parts of the work may be simple enough to handle in code. A fixed rule can select a contract field or calculate a price. A model could read the account notes and draft an explanation, with unresolved cases sent for review. The team can improve renewal reviews without first fixing every process connected to them. It does need to know where the remaining problems could affect the answer and when to stop the agent from making a recommendation.
The builder may be able to spot a recurring data problem without having permission to fix the system it comes from. If their job is to deliver more briefs, another workaround may be the only change they can make. Tracking the time people spend correcting those briefs would help their manager decide whether to keep doing that work. The manager could ask the team responsible for the source data what a fix would take and use the time records to make the case for it.