The logic between the systems
A business runs on decisions that live in nobody’s software. Which delivery day a customer belongs to. Whether this discount needs an owner’s approval or whether the representative can simply issue it. What happens when an order arrives for a quantity that is available at one location and not another. Which of two prices applies when a customer qualifies for both.
Ask where those rules are documented and the answer is usually that they are not. They live in the heads of two or three long tenured people, they get applied slightly differently depending on who is working, and they leave with those people when they retire. Every system in the company holds data. The logic connecting them is carried by staff.
Derive rather than enter
The single highest return pattern in this work is finding information a company types by hand that the system could work out for itself. A representative example: a distribution business assigned every customer a delivery route and delivery days as fields entered manually on the customer record. Hundreds of accounts, each set by hand, each occasionally wrong, and each quietly drifting as routes changed over the years. Examining the underlying route data showed something decisive, which is that every postal code mapped to exactly one route with fixed delivery days and no conflicts anywhere in the set. The route was never a value that needed entering. It had been derivable the entire time.
Converting that from entry to derivation changes several things at once. The value stops drifting because it is computed rather than remembered. Route changes become an update to one lookup table rather than an edit to hundreds of customer records. And the derived value becomes a check against what staff entered, flagging disagreements for review rather than blocking anyone’s work. The pattern generalizes well beyond routing: tax treatment, pricing tier, lead time, shipping method and account classification are all frequently entered by hand when they follow reliably from information the system already holds.
Approvals that actually govern
Most approval workflows fail the same way, which is that they notify rather than gate. A message goes out, the record advances regardless, and within a month everyone has learned the message can be ignored.
"An approval that does not hold the record is a courtesy, not a control."
Building these correctly means deciding several things explicitly. What thresholds require approval and what stays within a representative’s own authority. Who holds authority over each category of decision, since pricing, credit and scheduling are usually different people. What happens when the approver is unavailable, because a workflow with no escape path becomes a workflow people route around. And what gets recorded, since the value of an approval trail is being able to answer later why a particular price was granted. Done properly, the result is a business that can safely allow more autonomy at the edges, because the exceptions are governed rather than merely hoped about.
Exception handling is the real work
Automating a process that always runs the same way is straightforward and most companies have already done it. What remains unautomated is the work that varies. Rule-based automation executes correctly when inputs are complete, well-formed and anticipated, and it fails or halts when they are not. Real business inputs arrive incomplete and unanticipated with some regularity, which is why so many companies report that automation never reduced their workload as much as promised.
This is the specific gap AI closes. An order arrives with a product description that does not match any item code exactly but is obviously the same product to anyone who reads it. A customer requests delivery in a way that conflicts with their assigned schedule. Each of these requires interpretation rather than execution, and interpretation is what a language model is genuinely good at. Pagetrends builds these as narrowly scoped agents assigned to a single decision, operating against systems that reject invalid output, with a person retained on the approval path wherever the result touches money, inventory or a customer commitment. The agent interprets and proposes. The system validates. A person confirms.
Documenting the logic is half the value
An underrated outcome of this work is that the rules end up written down. A company that has moved its logic into the system has, as a byproduct, produced an accurate description of how it actually operates, which is frequently the first time that description has ever existed. That matters commercially. It removes the single point of failure represented by the one person who knows how pricing really works. It shortens onboarding for new staff dramatically. And it makes the business legible to a buyer, a lender or a partner, because an operation that can describe its own rules can be valued by somebody outside it.
Choosing the first process
The instinct is to automate the process that annoys people most. The better first target is usually the one that is high frequency, well understood and low risk, because it produces a visible result quickly and builds the confidence needed for the harder work. Derivations are often the right opening move for exactly this reason, since removing a data entry field that nobody enjoyed is an unambiguous improvement nobody has to be persuaded about. The processes involving money, credit and customer commitments come later, once the approval structure is in place and the team trusts the system’s judgment on smaller things.
How the engagement runs
Discovery, mapping and the substantial majority of the build happen through screen shared working sessions. Onsite is available when the work genuinely earns it and remains a deliberate decision rather than a standing assumption. The systems this logic runs between are covered in CRM integration for the customer facing side and ERP integration for the back office.