<p>Measure the human effort needed to finish the same work, at the same quality. That is a more useful test of operational AI than the speed at which it produces a draft.</p>
<h2>Start with a finished outcome</h2>
<p>Choose one unit of work: a supplier document accepted against an order, a payment reconciled, a correct offer sent or a delivery exception resolved.</p>
<p>Use the same start and finish in both processes. An accepted record and an AI draft are different outcomes. Include the normal task mix, from clean digital records to the awkward cases your team actually handles.</p>
<h2>Count the work people still do</h2>
<p>Include reading, data entry, matching, checking, exception handling and corrections. Count the effort of other teams when it contributes to the same outcome.</p>
<blockquote>Less human handling and faster turnaround are two different benefits. Measure each separately.</blockquote>
<p>A task can need little staff time while waiting hours for a supplier. Removing that wait and reducing hands-on work require different changes.</p>
<h2>Compare like with like</h2>
<p>Twenty minutes of human handling reduced to two gives a 10× handling-time ratio. The calculation is straightforward; the evidence behind the two numbers matters more.</p>
<figure data-editorial="productivity"><figcaption>Compare human handling time per completed task.</figcaption></figure>
<p>Report the task count, observation period and quality criteria with the ratio. Include exceptions in the average, and show the range when difficult cases materially change the result.</p>
<h2>What we built for China Motor</h2>
<p>We built China Motor’s custom ERP and CRM platform to connect importer operations, dealer sales and aftersales. AI agents read operational documents and connect the information to business records. Bank-transfer information supports reconciliation, while dealer teams can prepare offers, contracts and invoices from their phones.</p>
<p>For a document workflow like this, extraction speed is only one step. The useful measure is the effort needed to check the document, match it to the right record and complete the next action, including the exceptions that still need a person.</p>
<p><a href="/case-studies/china-motor-ai-automotive-platform">See how we connected documents, finance, logistics and dealer sales at China Motor →</a></p>
<h2>Put quality and running costs alongside time</h2>
<p>A workflow that needs constant correction has not released the capacity its headline suggests. Keep these checks together:</p>
<table><thead><tr><th scope="col">Measure</th><th scope="col">What to include</th></tr></thead><tbody><tr><td>Human effort</td><td>Review, exceptions and corrections across the complete task.</td></tr><tr><td>Accepted quality</td><td>Accuracy, missing information and work returned for correction.</td></tr><tr><td>Operating cost</td><td>Model usage, software, infrastructure, support and integration maintenance.</td></tr><tr><td>Reliability</td><td>What happens when a supplier document or external interface changes.</td></tr></tbody></table>
<h2>Decide what the released capacity is for</h2>
<p>More customer conversations, faster exception resolution, better planning or greater transaction volume: name the outcome the team wants. Specialists still own unusual cases and consequential decisions.</p>
<h2>Set the baseline before the pilot</h2>
<p>Agree the scope, quality checks and observation period first. Compare again once the workflow is in regular use, separating measured results from expected improvements.</p>
<p><a href="/contacts">Discuss a measurable first workflow with us →</a></p>


How to measure AI productivity in an ERP workflow



<p>Aftersales depends on coordination between the customer, the vehicle record and the people providing the service. A custom CRM can connect bookings and service activity with the history already created during the sale.</p>
<p>That continuity becomes more important when a business works with both internal workshops and external multibrand providers. The customer expects a coherent service even when several organizations take part.</p>
<h2>Make a booking the start of a defined process</h2>
<p>A booking needs a customer, a vehicle, a reason for the visit and a service provider capable of handling the work. Availability alone is not enough if the appointment requires particular expertise or preparation.</p>
<p>The platform should carry the relevant information into the booking. Staff should not have to reconstruct the customer or vehicle history from separate files before deciding what needs to happen.</p>
<p>An AI agent can help organize information from a customer request or supporting documents. The service workflow determines how that information is checked and used.</p>
<h2>Define the handoff to the service provider</h2>
<p>An external provider needs the information required to perform its task, along with a clear route for reporting progress or requesting a decision. The importer or dealer needs visibility into the status relevant to the customer.</p>
<p>Define which records are shared, who can change them and how updates return to the platform. This helps maintain continuity across company boundaries without giving every participant access to the entire customer record.</p>
<h2>Connect updates to useful communication</h2>
<p>A customer needs to know when a booking is confirmed, when preparation is required and when the expected completion changes. A service adviser needs to know when a provider is waiting for information or a decision.</p>
<p>These communications should follow the recorded state of the work. A prepared message should be based on current information and sent through the appropriate workflow. If the state is uncertain, the system should make the outstanding question visible to the responsible person.</p>
<h2>Preserve the service history</h2>
<p>After completion, the relevant service record should remain connected to the customer and vehicle. A later conversation can then start with context: what happened, who performed the work and which follow-up remains open.</p>
<p>Feedback should also have a place in the process. A repeated concern or unresolved issue needs an owner and a response. Collecting a rating without connecting it to action misses part of the opportunity.</p>
<h2>Evaluate continuity from the customer's perspective</h2>
<p>Useful measures include booking completion, time spent finding history, response time when plans change and unresolved follow-up. Review differences between internal and external service routes to see where the handoff needs attention.</p>
<p><a href="/case-studies/china-motor-ai-automotive-platform">China Motor's platform</a> extends its importer and dealer workflows into bookings, internal and external multibrand service coordination and timely communication. Aftersales becomes part of the customer relationship supported by the platform.</p>
<p><strong><a href="/contacts">Discuss your aftersales workflow with Perspective Unity</a>. We can help connect the participants, records and actions needed to deliver a consistent service.</strong></p><p><small>Written by the Perspective Unity team. Workflow diagrams are editorial illustrations.</small></p>

Keep the customer relationship connected after vehicle delivery



<p>A dealer CRM is useful when a salesperson can answer the customer's question and complete the relevant action using current information. That may mean checking availability, preparing an offer, issuing a document or following up on a service request.</p>
<p>Mobile access matters because much of this work happens away from a desk. The opportunity is to make the workflow complete on the device the person is using.</p>
<h2>Start with the question the customer is asking</h2>
<p>“Can I get this vehicle?” depends on more than a catalogue entry. The answer may involve a specific configuration, an allocation, an incoming delivery and the conditions for reservation.</p>
<p>Connect the customer conversation to those records. The salesperson needs to understand whether the information is confirmed, expected or still being checked. This supports an answer that reflects the operation behind the sale.</p>
<h2>Carry the information into the document</h2>
<p>Once the customer is ready to proceed, the information should flow into the offer and subsequent documents. Re-entering vehicle, customer and commercial details in separate files creates extra work and opportunities for inconsistency.</p>
<p>A mobile workflow can assemble the document from the relevant records, apply the approved template and route any decision that requires authorization. The user reviews what will be sent and completes the action.</p>
<p>The same principle applies to contracts, invoices and notifications. The exact steps depend on the document and the business rules. A few well-designed actions can replace a sequence of searching, copying, formatting and sending.</p>
<h2>Keep the conversation and next action together</h2>
<p>A communication history helps the next person understand what the customer was told. Follow-up should be associated with the relevant request, offer or sale, rather than remaining a private reminder in one person's inbox.</p>
<p>AI assistance can help prepare summaries or identify information to review. The system still needs clear ownership of the response and a record of what was actually communicated.</p>
<h2>Give managers context for performance</h2>
<p>Activity counts alone do not explain sales performance. A team may be responding quickly but lack the requested stock. Another may have suitable vehicles but unresolved follow-up.</p>
<p>Connect KPIs to demand, availability and the stages of the customer relationship. Managers can then distinguish a supply constraint from an execution issue and decide where to intervene.</p>
<p>Feedback adds another dimension. Customer concerns, repeated questions and service outcomes can identify where the process needs improvement. The system should help the business act on that information.</p>
<h2>Make everyday adoption the test</h2>
<p>Measure how long it takes to prepare and send a correct offer, how often users leave the CRM to complete a task and how reliably the next action is recorded. Review those measures alongside customer response and document quality.</p>
<p>In <a href="/case-studies/china-motor-ai-automotive-platform">China Motor's platform</a>, dealers use mobile workflows for commercial documents and communications, with visibility into availability, deliveries, KPIs and sales-team performance.</p>
<p><strong><a href="/contacts">Discuss your dealer workflow with Perspective Unity</a>. Bring the steps your salespeople repeat and the information they have to chase.</strong></p><p><small>Written by the Perspective Unity team. Workflow diagrams are editorial illustrations.</small></p>

A dealer CRM should help the salesperson complete the next step



<p>Vehicle data becomes useful when its relationships are correct. A brand, model, variant, specification, accessory or colour describes part of a product. An individual vehicle adds its own identity, location, allocation and operational history.</p>
<p>AI can help process the large volume of supplier information behind those records. A custom platform must also maintain the structure that lets sales, logistics and finance interpret the data consistently.</p>
<h2>Establish the product hierarchy</h2>
<p>Supplier files may use different naming conventions for the same concepts. A model description can contain a trim, a powertrain or a market-specific package. A colour code may be more reliable than its translated name.</p>
<p>Define the relationships the business needs before automating imports. Which identifier establishes a product? Which attributes can change over time? Which configurations are compatible with an accessory?</p>
<p>AI can propose classifications and associations. The platform needs explicit rules for accepted identities and a review route for ambiguous records.</p>
<h2>Treat changes as changes</h2>
<p>A new specification file may correct an earlier value or introduce a new variant. Importing it as a fresh catalogue without comparison can create duplicates or alter information used in an existing offer.</p>
<p>The process should show additions, revisions and conflicts. Preserve enough history to understand which specification or commercial data was used for a transaction. A later catalogue update should not silently rewrite the meaning of a document already sent to a customer.</p>
<h2>Connect catalogue records to individual vehicles</h2>
<p>An individual vehicle record should link to the relevant configuration while retaining its own identity and history. Users need to distinguish what the product generally is from what has happened to this particular vehicle.</p>
<p>This is important for stock search, reservations, documents and service. A dealer should be able to understand both whether a configuration is offered and whether a particular vehicle is available for the intended transaction.</p>
<h2>Separate location, allocation and accounting state</h2>
<p>A vehicle can be physically held at one location, allocated to a dealer and recorded in a particular accounting warehouse. These are related facts with different meanings.</p>
<p>Receiving or releasing a vehicle changes part of that picture. The platform should record the evidence and the corresponding movements without assuming that every operational event has the same accounting effect.</p>
<p>Clear distinctions make discrepancies visible. They also let teams investigate the actual question: where the vehicle is, who it is committed to or which record requires reconciliation.</p>
<h2>Put the information where people use it</h2>
<p>Catalogue quality affects more than an administrator's import screen. It shapes search, offer preparation, availability views, order planning and the accuracy of documents.</p>
<p>Measure how much manual correction remains after an import and whether sales and operational teams still maintain separate versions. The useful outcome is trusted product and vehicle information that carries into daily work.</p>
<p><a href="/case-studies/china-motor-ai-automotive-platform">China Motor's platform</a> uses automation to process extensive automotive product data and follow vehicle movements in their physical and accounting context.</p>
<p><strong><a href="/contacts">Talk to Perspective Unity about your catalogue and stock workflows</a>. We can help define the data relationships and checks that make automation useful.</strong></p><p><small>Written by the Perspective Unity team. Workflow diagrams are editorial illustrations.</small></p>

Why vehicle catalogue automation needs more than data extraction



<p>Tracking a delivery is useful when the status change helps the next participant act. An updated arrival date may affect a carrier booking, a customs task, an inspection slot and the promise made to a customer. A custom platform can connect those consequences to the same delivery record.</p>
<p>Automotive logistics is particularly demanding because each participant sees only part of the process. The importer needs a way to combine those views without making every person follow every conversation.</p>
<h2>Represent the stages and responsibilities</h2>
<p>A shipment can involve sea freight, port handling, customs clearance, inland transport, warehousing and final delivery. Inspection, damage assessment and document preparation may run alongside those movements.</p>
<p>Define the stages using evidence and responsibilities. What establishes arrival? Who confirms receipt? Which document is needed before the next step? Who acts when the expected evidence is missing?</p>
<p>This gives an update a meaning beyond a colour on a dashboard. It connects the reported state to the work that is possible or required.</p>
<h2>Preserve the source and freshness of information</h2>
<p>A live view can combine carrier feeds, partner updates, documents and internal events. Those sources have different update frequencies and levels of certainty.</p>
<p>Show when information was received, where it came from and whether it is expected or confirmed. An estimated arrival should remain distinguishable from a completed receipt. A manager can then act on the information without mistaking an old estimate for a recent observation.</p>
<p>AI agents can help interpret updates from varied messages and documents. The resulting state needs to remain connected to the underlying evidence.</p>
<h2>Notify the people affected</h2>
<p>Sending every update to every participant creates another information burden. Notifications should follow responsibility and impact.</p>
<p>For example, a change in arrival may require a transport coordinator to reschedule collection. A missing document may need a response from the supplier or customs representative. A dealer may need a revised customer-facing delivery expectation.</p>
<p>Each notification should identify the affected shipment or vehicle, explain the change and show the next action. The platform should record whether the issue is still open, so the team can follow unresolved work rather than repeatedly asking for status.</p>
<h2>Connect damage and document exceptions</h2>
<p>A damage report can affect movement, insurance handling, preparation and the customer's delivery. Keep the report, images, assessment and decisions associated with the vehicle and the people handling the issue.</p>
<p>The same principle applies to homologation, registration and other required documents. Recording a document and confirming the relevant operational step are different actions. The workflow should show which has occurred and who can make the next decision.</p>
<h2>Make management visibility actionable</h2>
<p>A useful management view highlights where the plan has changed: a delayed stage, an unresolved responsibility or a vehicle that cannot progress. Managers need to see the consequence and the available options, with access to the underlying detail.</p>
<p><a href="/case-studies/china-motor-ai-automotive-platform">China Motor's platform</a> connects delivery information with transport, customs, inspection, damage and dealer workflows. The purpose is coordinated action across the network.</p>
<p><strong><a href="/contacts">Talk to Perspective Unity about your delivery process</a>. We can map the participants, evidence and handoffs that your platform needs to support.</strong></p><p><small>Written by the Perspective Unity team. Workflow diagrams are editorial illustrations.</small></p>

A shipment update should tell the next participant what to do



<p>A purchasing plan needs to connect demand with the supply already available and the cash required to obtain more. An AI-enabled business platform can bring those inputs together, investigate changes and help managers compare feasible options.</p>
<p>The decision still depends on the company's priorities. Protecting a committed customer delivery, increasing product availability and conserving cash can lead to different choices. A useful planning system makes the consequences visible.</p>
<h2>Distinguish commitments from expectations</h2>
<p>A confirmed customer order, a dealer stock request and a sales forecast represent different levels of certainty. Treating them as one demand total can obscure the reason for buying a quantity.</p>
<p>Keep the sources distinguishable. Managers should be able to see which proposed purchases cover committed orders, which support dealer inventory and which depend on a forecast. The plan should also show the effect of cancellations or changes in requested configurations.</p>
<p>AI can help summarize these inputs and identify changes. The records and planning rules need to retain their business meaning.</p>
<h2>Count supply that can actually cover the demand</h2>
<p>Stock in a warehouse may already be allocated. An incoming shipment may arrive after the customer's required date. Two variants with similar descriptions may not be acceptable substitutes.</p>
<p>An illustrative example: 20 confirmed orders, 10 suitable unallocated vehicles in stock and 5 suitable vehicles arriving before the required date leave a gap of 5. If those incoming vehicles are already committed elsewhere, the gap is larger. The arithmetic depends on correct allocation and timing.</p>
<p>The platform should let a planner follow a proposed quantity back to these assumptions. A summary without that explanation is difficult to challenge or trust.</p>
<h2>Place the cash commitments on a timeline</h2>
<p>The relevant question is when cash is required and when funds are expected to be available. A supplier deposit, a final payment, transport costs and other known charges may occur at different stages.</p>
<p>Keep actual payments separate from expected receipts. The plan should show which assumptions would need to hold for a purchase scenario to remain feasible. If a customer receipt is delayed, a manager needs to see the effect before the next commitment is made.</p>
<h2>Compare alternatives explicitly</h2>
<p>A planning view can compare ordering now, reducing the quantity, changing the mix or moving part of the order to a later period. Each option should show the affected demand, delivery timing and financial commitments.</p>
<p>AI can help explain differences and draw attention to conflicting assumptions. The business decides which trade-off to accept and who can authorize the commitment. The approved plan should retain the reasoning needed to understand later changes.</p>
<h2>Revisit the plan when facts change</h2>
<p>Planning should respond to changes in demand, stock, delivery dates and payments. The system can identify which assumptions are affected and direct attention to the decisions that need review.</p>
<p>In <a href="/case-studies/china-motor-ai-automotive-platform">China Motor's custom platform</a>, planning connects order quantities to cash flow and dealer and customer needs. This is one example of an ERP capability built around the operating decisions of a distributor.</p>
<p><strong><a href="/contacts">Discuss your purchasing workflow</a>. We can help identify the data, assumptions and decisions a useful planning system needs to connect.</strong></p><p><small>Written by the Perspective Unity team. Workflow diagrams are editorial illustrations.</small></p>

What should a distributor order when demand and cash are both constrained?

<p>A workbook can be a database, a process manual and a set of business rules at the same time. Replacing it with software starts by separating those jobs.</p><h2>Find the rules, including the overrides</h2><p>Follow an actual order or report through the files. Identify who enters the information, which formulas affect a decision and where the result is copied next. Ask about hidden columns and manual corrections. An override may represent an exception the business still needs.</p><p>In <a href="/case-studies/marketing-agency-erp-development">ZMatic’s ERP project</a>, understanding the dependencies between spreadsheets informed the data model and migration. The replacement connected customer history, orders, reporting and client self-service.</p><h2>Do not turn every tab into a screen</h2><p>Decide what the record represents and which system owns it. An illustrative example: after an approved order changes to a partial delivery, the application needs rules for the remaining quantity, status, documents and information sent to finance. Storing the rows does not define that behavior.</p><p>Write the exceptions into the requirements with the roles allowed to handle them. The people using the workbook can confirm whether the proposed behavior preserves the rule or deliberately changes it.</p><h2>Move the data and the responsibility</h2><p>Keep the original files. Map identifiers, choose which history to move and list incomplete or conflicting entries. Assign someone to resolve them rather than filling gaps with guessed values.</p><p>Rehearse the import and check totals, relationships and complete tasks. Agree when the new system takes over and how problems will be reported. If both remain in use, specify which one owns each record.</p><p>That is the starting point for <a href="/custom-erp-development">custom ERP discovery</a>: understand the business inside the files before designing their replacement.</p>

When spreadsheets become an operating system

<p>A count of screens can describe the interface. It will not tell you how much history must move, which integrations must keep working or how the business will switch to the new version.</p><h2>Ask for work you can examine</h2><p>An estimate should distinguish investigation, design, implementation, integrations, migration, testing and rollout. Under each area, ask what is known, what is assumed and what still needs access or a technical check.</p><p>A range should explain its uncertainty. If an undocumented API is responsible for a large part of that range, ask which investigation would narrow it. A fixed price needs a defined scope and a clear agreement about changes.</p><h2>Include the transition</h2><p>Discuss data cleanup, migration rehearsals, reconciliation, training, temporary operation and rollback. Give those activities an owner. Moving a database and moving a business to the new system are related work, but they are not the same task.</p><p><a href="/case-studies/merp-prep-software-modernization">MERP/PREP</a> combined a web, mobile and backend rewrite with DevOps and migration. The delivery team reports a cutover without service interruption and 90% lower AWS costs afterwards. Those project outcomes illustrate the scope; they are not a price or savings forecast for another platform.</p><h2>Clarify the cost after release</h2><p>Separate hosting and third-party services from maintenance, support coverage and continuing product development. Ask what the engagement includes and what needs a separate arrangement.</p><p>We do not publish a universal modernization price because the existing software and transition requirements differ. <a href="/pricing">Our pricing approach</a> explains how we establish the scope, and <a href="/digital-transformation">our modernization work</a> covers the change around the code.</p>

What actually shapes a modernization estimate?

<p>A software demonstration shows what a platform can do. Your implementation has to show what it can do with your records, exceptions and existing systems.</p><h2>Give both options the same examples</h2><p>Prepare a short evaluation pack: a normal order, an amended order, a partial delivery and a record with missing information. Choose cases from your own operation and remove sensitive data as needed.</p><p>Ask each supplier to walk through them. Record the difference between the following answers:</p><ul><li><strong>Available as standard:</strong> Does the demonstrated behavior match your rule?</li><li><strong>Configurable:</strong> Who configures it, and is that work included?</li><li><strong>Requires development:</strong> Who maintains the extension when the platform changes?</li><li><strong>Unsupported:</strong> Can the business accept a different process?</li></ul><h2>Compare the implementation work</h2><p>Both options need data preparation, migration, testing, training and support. Include the systems that stay, the integrations they require and the way a failed update will be investigated. A license price and a custom development quote rarely describe the same boundary.</p><p>For <a href="/case-studies/marketing-agency-erp-development">ZMatic</a>, interconnected spreadsheets contained rules that had to become ERP behavior. That is a reason to investigate fit carefully; it does not establish that every spreadsheet-based operation needs a custom system.</p><h2>Look at ownership after launch</h2><p>Ask who can change the system, export the data and support the integrations. Include recurring fees and the changes you already expect, such as a new approval rule or business unit. Record the contractual limits that affect a future move.</p><p>A packaged platform may fit. A custom system or a combination may fit better. The recommendation should explain that choice using your examples. <a href="/custom-erp-development">Explore our ERP approach</a>.</p>

Custom ERP or an off-the-shelf platform?



<p>Payment information often determines what can happen next in an operation. A team may need to know whether a deposit was received, which invoices were covered or whether an outstanding amount still needs attention. A custom platform can connect bank reconciliation to those business records.</p>
<p>The workflow begins with reliable transaction information and ends with a confirmed interpretation that the relevant team can use. Reading an incoming transaction does not authorize a system to initiate a payment.</p>
<h2>Keep evidence and expectations separate</h2>
<p>An issued invoice, a planned payment and a recorded bank transaction describe different events. The system should preserve those distinctions.</p>
<p>A promised transfer should not be displayed as received cash. An uploaded payment instruction may still need to be reconciled with the bank record. Teams should be able to see what is expected, what has been observed and what has been matched to a business obligation.</p>
<h2>Match against more than one field</h2>
<p>Payment references are not always complete. A payer may use an abbreviated company name, omit an invoice number or settle several invoices together.</p>
<p>A matching process can consider the reference, payer, amount, currency, date and open items. AI can assist with interpreting descriptions or proposing candidate matches. Explicit checks should determine whether the candidate is sufficiently clear to accept or needs a finance specialist's decision.</p>
<p>The person reviewing a proposal should see the evidence and the alternative matches. That is more useful than receiving an unexplained confidence score.</p>
<h2>Handle partial and combined payments</h2>
<p>One payment may cover part of an invoice. Another may cover several. An overpayment, reversal or fee difference can require a different treatment from a clean match.</p>
<p>Represent the relationship between transactions and obligations explicitly. A new import should not create a second receipt for the same bank transaction. A later correction should preserve what was previously recorded and the reason for the change.</p>
<p>These details matter because other workflows may rely on the result.</p>
<h2>Define what payment can unlock</h2>
<p>Once payment is confirmed, the platform can update the relevant record and notify the person responsible for the next step. The action should follow the business rule for that process.</p>
<p>For example, a received deposit may satisfy one condition for an order while delivery documents or another approval remain outstanding. Payment confirmation should not silently stand in for those separate requirements.</p>
<p>This is where integration between finance and operations becomes useful: people can see the relevant financial state alongside the other conditions governing the work.</p>
<h2>Assess the whole reconciliation process</h2>
<p>Measure the time spent reviewing imports, resolving unclear matches and correcting errors. Track the age of unmatched transactions and whether operational teams still need to ask finance for the same information.</p>
<p>The target is a dependable flow from bank evidence to business understanding. In <a href="/case-studies/china-motor-ai-automotive-platform">China Motor's platform</a>, reading bank-transfer information and performing reconciliations forms part of the wider automation of importer and dealer work.</p>
<p><strong><a href="/contacts">Discuss your reconciliation process</a>. We can examine the records, exceptions and operational actions that need to stay connected.</strong></p><p><small>Written by the Perspective Unity team. Workflow diagrams are editorial illustrations.</small></p>

Connect bank transactions to the work waiting on payment



<p>Yes. A custom platform can coordinate work with an existing ERP while parts of the operation move to a new system. Depending on available access, that connection can use APIs, structured files or RPA that interacts with the existing application's interface.</p>
<p>This approach lets a business improve a defined workflow before completing a larger replacement. It also requires a clear decision about which system owns each record during the transition.</p>
<h2>Choose the connection around the application</h2>
<p>Start by establishing what the current system supports. A documented interface may provide a reliable route for reading and updating records. A supported import or export can be appropriate for a scheduled exchange.</p>
<p>Where those options do not cover the required work, RPA may operate the application through its screens. Microsoft documents this pattern for applications without suitable APIs in its <a href="https://learn.microsoft.com/en-us/power-automate/guidance/rpa-sap-playbook/core-components">SAP RPA guidance</a>.</p>
<p>The presence of a robot does not make every integration simple. Permissions, interface changes, available environments and business rules still determine what can be automated reliably.</p>
<h2>Give the robot a bounded business task</h2>
<p>A useful task has a defined input, a permitted action and a result that can be checked. For example, it might create an approved record in an existing system and return that system's reference.</p>
<p>The workflow should know whether the record already exists. If the application becomes unavailable after a save, the next run must establish what happened before attempting another creation.</p>
<p>That confirmation is especially important when work crosses systems. A successful click is not enough to establish that the business transaction completed correctly.</p>
<h2>Separate interpretation from execution</h2>
<p>AI can help interpret a document, classify a request or prepare a proposed update. The action that changes an established system should follow defined rules and permissions.</p>
<p>This separation gives the business a place to review uncertain interpretation before it becomes an operational commitment. It also makes it easier to investigate a failure: was the source misunderstood, the action rejected or the result not confirmed?</p>
<h2>Keep the transition understandable</h2>
<p>As a workflow moves, decide which platform owns the customer record, the operational order, the accounting document and other relevant data. Ownership may differ by record type.</p>
<p>Avoid a situation where both systems can change the same information without a reconciliation rule. Show pending updates and failures to the responsible team. A temporary integration still needs an owner, support and a recovery procedure.</p>
<h2>Replace components when there is a reason</h2>
<p>Some parts of an established ERP may continue to serve the business well. Others may require an expensive workaround for every operational change. A phased approach lets the company assess these boundaries using real work.</p>
<p>This can apply in an environment containing SAP, Microsoft Dynamics NAV or Oracle, but the exact product, version, interfaces and contractual access must be assessed. It is not a blanket claim that every platform or module is interchangeable.</p>
<p>Our <a href="/digital-transformation">legacy application modernization services</a> cover assessment, implementation and the transition to the next version.</p><p><strong><a href="/contacts">Discuss a phased modernization with Perspective Unity</a>. We can identify a useful workflow, its current system dependencies and a practical integration path.</strong></p><p><small>Written by the Perspective Unity team. Workflow diagrams are editorial illustrations.</small></p>

Can you automate the work before replacing the old ERP?



<p>An AI document agent becomes useful when the information it reads connects to a business record and helps complete the next task. Extracting an invoice number is one step. Identifying the correct order, checking the amount and routing an unexplained difference are what make the result operationally useful.</p>
<p>For importers and distributors, that connection matters because information arrives through many formats: supplier spreadsheets, scanned documents, PDFs, email attachments and changes sent in free text. Each can contain information needed by sales, logistics or finance.</p>
<h2>Follow the document through the operation</h2>
<p>Consider a supplier sending a revised document for an existing shipment. Someone normally has to open it, identify the related order, compare it with the earlier version and inform the people affected.</p>
<p>An agent can assist with reading and comparison. The platform needs to establish which record the document belongs to, whether it is new or revised and which changes have business significance. A changed quantity can affect availability. A changed price can affect a commitment. A changed vehicle identifier may require investigation before anything is updated.</p>
<p>Designing that sequence makes the document part of a workflow rather than another file in a folder.</p>
<h2>Separate extraction from acceptance</h2>
<p>Readable text is not necessarily correct business data. A document may contain an ambiguous date, a missing reference or a description that does not match the product catalogue.</p>
<p>The workflow should distinguish what the agent read from what the system accepted. A reviewer needs to see the relevant source and the proposed interpretation together. That makes it possible to resolve a specific uncertainty without reading the whole document again.</p>
<p>Some checks can be explicit: a required reference exists, line amounts reconcile with the total, or a vehicle identifier matches an existing record. Other differences require judgment. The design should make that distinction visible.</p>
<h2>Handle duplicates and amendments</h2>
<p>The same document may arrive more than once, through different people or channels. A revised version may reuse the original number. Without an identity and revision strategy, faster processing can create duplicate work.</p>
<p>Define how the platform recognizes an existing document, records a revision and preserves the previous version. An amendment should make its consequences visible. It should not quietly overwrite a decision that has already triggered another action.</p>
<h2>Give each exception somewhere to go</h2>
<p>An exception queue should answer three questions: what is unclear, why it matters and who can resolve it. A missing supplier reference belongs to a different investigation from a bank transaction that cannot be matched to an invoice.</p>
<p>When a person resolves the issue, the process should resume from the appropriate point. They should not have to repeat the successful steps or enter the same information in another system.</p>
<h2>Measure completed work</h2>
<p>Useful measures include human handling time per accepted document, time to resolve exceptions, correction rates and the proportion of records that reach the next step without manual re-entry. Extraction speed alone misses the work that may have been pushed onto reviewers.</p>
<p><a href="/case-studies/china-motor-ai-automotive-platform">China Motor's platform</a> applies AI to varied documents and operational information within an importer and dealer environment. The wider lesson applies wherever documents trigger work across several teams.</p>
<p><strong><a href="/contacts">Discuss a document workflow with Perspective Unity</a>. Bring the document types, the records they affect and the next action your team needs to complete.</strong></p><p><small>Written by the Perspective Unity team. Workflow diagrams are editorial illustrations.</small></p>

What should an AI document agent do after it reads the document?



<p>AI can assist the team building a business system, and it can perform useful work inside the system once it is in operation. These are different capabilities, with different responsibilities and measures of success.</p>
<p>At Perspective Unity, we use both. Our own AI orchestrator and working rules support software delivery. Operational AI agents help clients handle documents, investigate discrepancies and coordinate business workflows.</p>
<h2>AI assistance during development</h2>
<p>Our team uses AI across analysis, prototypes, coding, tests and documentation. We have developed an orchestrator and an ecosystem of rules for how people work with it, review outputs and validate the work.</p>
<p>The experienced person remains central. AI helps accelerate code production. Understanding the operation, choosing the solution, validating its behavior and implementing it remain responsibilities of the people delivering the project.</p>
<p>A generated workflow can be technically plausible and still represent the business incorrectly. For example, the system may need to distinguish a dealer's allocation from a vehicle's physical location. Establishing that distinction requires operational understanding. The team must then check that the implementation preserves it.</p>
<h2>AI agents in everyday operations</h2>
<p>An operational agent can read an incoming document, identify relevant records and prepare a next action. Its usefulness depends on access to the right information and its connection to a defined workflow.</p>
<p>Consider an amended supplier invoice. The relevant task is broader than reading its total. The platform needs to identify the order, compare the amendment with the previous version and determine which quantities, commitments or documents are affected.</p>
<p>The agent can assist with interpretation and comparison. Business rules determine permitted actions and when a specialist needs to review the result. The record should retain enough context to explain what changed and why.</p>
<h2>Automation completes the connection</h2>
<p>Once an action is accepted, it may need to update another system, generate a document or notify a participant. That can involve an API, a structured import or a robot operating an existing interface.</p>
<p>The integration should confirm whether the action succeeded and handle retries without creating duplicate business records. A well-designed workflow connects interpretation, validation, action and confirmation.</p>
<h2>Measure the right outcome</h2>
<p>For development, faster code production is useful when the resulting software meets the agreed behavior and can be maintained. For operational agents, the measure is the business process: time spent, waiting, accuracy and the quality of the completed work.</p>
<p>Neither measure is captured by counting generated lines of code or extracted fields alone. A document-reading agent becomes valuable when the information it produces helps a person or process complete a meaningful task.</p>
<h2>One accountable delivery partner</h2>
<p>The client should not have to assemble these layers independently. Perspective Unity connects product design, engineering, AI assistance, integrations and implementation within the agreed scope.</p>
<p>Your team supplies business knowledge and decisions. Our team turns that knowledge into a platform, checks its behavior and prepares it for use. <a href="/custom-ai-business-platforms">Explore our custom AI business platforms</a>.</p><p><small>Written by the Perspective Unity team. Workflow diagrams are editorial illustrations.</small></p>

Two places AI can improve a custom business platform

<p>A product strategy should help a team say yes to one thing and defer another. A list of everything the software could do does not make that choice.</p><h2>Put the user and decision in the same sentence</h2><p>“Add a dashboard” does not say why it is needed. As an illustrative requirement, “let operations see which bookings need intervention before the next shift” identifies a user, a decision and a moment when the information matters.</p><p>Bring examples of the current work. Where does somebody wait, repeat an entry or ask another person for context? Check that the observation represents a recurring problem before expanding it into a roadmap.</p><h2>Make the trade-off explicit</h2><p>Choose a first scope that completes a task. List the dependencies and the capabilities left for later. For each proposed feature, record the problem it addresses and what evidence supports its priority.</p><p>Keep a short decision log. If new evidence changes the plan, the team should be able to see what changed and why, rather than reopening the same argument from memory.</p><h2>Choose the next evidence, not just the next feature</h2><p>An undocumented integration may need a technical check. A confusing interaction may need a prototype. Customer adoption needs evidence from customers and use. These are different uncertainties and should not be bundled into one promise that development will resolve them all.</p><p>Agree who owns the next decision and when to review it. <a href="/five-day-strategy">Our strategy work</a> defines that direction; <a href="/discovery">discovery</a> develops the detail needed to deliver it.</p>

A product strategy starts with a decision

<p>A rewrite can reproduce the obvious screens and still lose a rule the business depends on. Those rules may live in code, an export, an old spreadsheet or the knowledge of the person who handles exceptions.</p><h2>Build a baseline of behavior</h2><p>Record the important tasks, their inputs and expected results before changing the implementation. Include calculations, permissions, reports and integration messages. Ask what happens after a correction or an incomplete record, not only on the normal path.</p><p>In <a href="/case-studies/marketing-agency-erp-development">ZMatic’s move to a custom ERP</a>, the spreadsheet dependencies were part of the business knowledge that needed to be understood. The migration was more than a transfer of rows.</p><h2>Give each dependency a test</h2><p>Identify the systems and people consuming the current output. For a document workflow, that may include existing identity and permission rules: <a href="/case-studies/document-management-system-dms">ECONT’s DMS</a> retained sign-on and access supplied by the ERP.</p><p>Use those dependencies to define acceptance examples. A new screen may look right while a report or downstream system receives the wrong value.</p><h2>Rehearse the move</h2><p>Map identifiers, decide which history moves and keep unresolved records visible. Rehearse with representative data. Compare business totals and relationships as well as counts, then test complete tasks with the imported records.</p><p>Before release, agree which system becomes authoritative, who performs the checks and what would trigger a rollback. If both systems remain active temporarily, write down who owns each record during that period.</p><p>The <a href="/digital-transformation">legacy application modernization scope</a> needs to include this transition work alongside the replacement code.</p>

How to modernize software without losing the business rules

<p>An end-to-end team can take responsibility for design, engineering and release. It still needs decisions that only the founding team can make: which customers matter first, what they need and what evidence justifies the investment.</p><h2>Give the team a task to deliver</h2><p>Describe who will use the first release and what they must be able to finish. “A platform with a dashboard” is open-ended. A task with a beginning, an outcome and known dependencies can be scoped and tested.</p><p>Bring customer conversations, existing material and examples of the current workaround. Separate what you have observed from what you hope users will do.</p><h2>Keep the first release complete</h2><p>A smaller scope can serve fewer users or fewer use cases. It should still account for access, failed actions, external dependencies and support. Half a transaction can be a smaller build without being a useful product.</p><p>Name what is deliberately excluded. This protects the release from becoming a collection of every idea raised during design.</p><h2>Make reviews about decisions</h2><p>Review prototypes and working software against the agreed task. The delivery team tests the implementation; your team checks whether the behavior fits the intended operation. Neither activity alone proves demand.</p><p>After launch, connect feedback to a choice: correct a defect, change the flow, add a capability or reconsider the proposition. Agree who can make that choice and how it affects the scope.</p><p><a href="/end-to-end-development">See how we divide delivery responsibilities</a>, or start with <a href="/mvp">the question your first release needs to answer</a>.</p>

What an end-to-end team needs from a startup

<p>If an order is entered once in sales and again in operations, the first question is where the information stops travelling. Buying a new platform before answering that can leave the same handoff in a different interface.</p><h2>Follow one record across the business</h2><p>Choose an actual order, booking or document. Track who creates it, what changes, which systems receive it and who checks the result. Include the spreadsheet or email used when the main application does not have the answer.</p><p>Look for the rule behind the extra step. Someone may be checking a total because identifiers do not match, or copying a record because the receiving system needs a different representation.</p><h2>Decide who owns the information</h2><p>For each record, name the authoritative system and the fields other systems can change. Agree how to recognize a repeated message and who resolves an incomplete or failed update.</p><p>Our <a href="/case-studies/cupffee-ecommerce-crm-integrations">Cupffee integration work</a> involved Zoho product mapping and carrier calculations. Our <a href="/case-studies/document-management-system-dms">ECONT DMS</a> used ERP permissions and existing sign-on. Both involve connected systems, but their ownership and access questions differ.</p><h2>Give the first change a clear boundary</h2><p>Select a workflow that can be completed and checked. Include data preparation, permissions, tests, training and support in that scope. Define the starting measure for the problem you intend to improve, then review the result after release.</p><p>That gives a broad transformation programme an initial decision the business can examine. <a href="/core-business-solutions">Our business systems work</a> starts with those records and handoffs.</p>

Digital transformation starts in the work between systems

<p>Old software can be expensive to change and still contain business knowledge worth keeping. Its age tells you to investigate; it does not decide whether to replace it.</p><h2>Name the constraint</h2><p>Separate a slow user task from a slow development process. A page that loads badly, an integration that repeatedly fails and a product that takes months to change may need different interventions.</p><p>Describe the operation to measure and the conditions of the test. “Make it faster” leaves too much open. “Load a customer’s order history with this volume of records” gives the team something it can investigate and repeat.</p><h2>List what depends on the current behavior</h2><p>Include reports, scheduled jobs, exports, permissions and manual checks outside the application. Ask experienced users which exceptions the documentation leaves out. For every dependency, identify an owner and a way to check it after the change.</p><h2>Compare the transition, too</h2><p>Keeping the system means accepting some maintenance and limits. Improving it may remove a specific constraint. Replacing it adds migration and reimplementation work. A staged replacement also creates temporary responsibilities for data shared between old and new components.</p><p><a href="/case-studies/merp-prep-software-modernization">MERP/PREP</a> required a full rewrite across web, mobile and backend, with DevOps and migration in the same engagement. That scope followed the product’s needs; it is not the default recommendation for every older application.</p><p>A useful <a href="/digital-transformation">modernization assessment</a> should explain what to retain, improve, replace and retire, along with the evidence that could change the recommendation.</p>

Keep, improve or replace your existing software?

<p>A proof of concept, a prototype and an MVP answer different questions. Choosing the wrong one can produce an impressive demonstration without reducing the uncertainty that matters.</p><h2>A PoC tests a technical question</h2><p>Use a proof of concept when the unknown is whether an approach works under relevant conditions. For example, can an external service return the records you need with the permissions available to the application?</p><p>Write down the test conditions and success criterion first. Use representative inputs and record shortcuts. A successful API request does not establish error handling, monitoring, maintainability or readiness for production.</p><h2>A prototype tests an interaction</h2><p>A clickable prototype lets people try a task before the team implements it. Watch where they hesitate, what they expect a control to do and which information is missing. Test the task rather than asking whether they like the design.</p><p>Use the result to change the flow or clarify the behavior. A polished prototype does not, by itself, show that anyone will adopt or pay for the product.</p><h2>An MVP puts a limited product into use</h2><p>An MVP needs a defined audience and a complete first task. It can leave features for later, but it still needs the access, reliability and support required for that task. Decide which usage and business evidence will justify another release.</p><h2>End the experiment with a decision</h2><p>Record what worked, what failed and what remains unknown. The next step may be implementation, a narrower test or stopping that direction. Our <a href="/discovery">discovery</a>, <a href="/product-design">design</a> and <a href="/mvp">MVP work</a> start with the question the activity needs to answer.</p>

PoC, prototype or MVP: choose the question first

<p>This company update records Perspective Unity’s earlier feature by Clutch. We have kept its original publication date as part of the news archive.</p><p>For a current view of client feedback, read the individual engagements on <a href="https://clutch.co/profile/perspective-unity">our Clutch profile</a>. Look at the customer’s role, the work described and when the review was written.</p><h2>Use the projects to judge the fit</h2><p>Our <a href="/case-studies">case studies</a> describe the scope behind the names: custom ERP workflows for ZMatic, booking and field operations for ParkFly, workforce software for Decathlon Bulgaria, and a web and mobile platform rebuild for MERP/PREP.</p><p>If one resembles your situation, ask us about the starting point, the difficult dependencies and our responsibility in the delivery. Recognition can introduce a team; those details are what help you choose one.</p>

Perspective Unity featured by Clutch

<p>A software assessment should leave you able to make a decision. A long report that lists problems without explaining what to do next has not finished the job.</p><h2>Start with evidence already in the business</h2><p>Application access, spreadsheets, support issues, forms and reports give the review a starting point. Pick a real scenario and follow it through those sources before asking people to explain the entire operation in a workshop.</p><p>Keep the finding separate from the diagnosis. “The same customer appears twice in this export” is an observation. “The integration creates duplicates” is a hypothesis until the team has checked how those records were created.</p><h2>Show what a recommendation would preserve</h2><p>Assessment should not assume replacement. <a href="/case-studies/document-management-system-dms">ECONT’s document platform</a> used existing sign-on and ERP permissions. The new capability had to fit into that arrangement, not introduce a separate identity model.</p><p>For each proposed change, ask which problem it addresses, what stays in place and which dependency could prevent delivery. An integration, a process change or a targeted repair may be a better first scope than a new application.</p><h2>Ask for a decision you can review</h2><p>The output should name the options, the recommended approach, the evidence behind it and the assumptions still open. If the estimate depends on a third-party API or the condition of the data, the report should propose a specific check.</p><p>Agree the required depth before the assessment begins. Sometimes you need an options review; sometimes you need prototypes, architecture and detailed requirements. <a href="/consulting">Discuss the decision with us</a>, then define the work needed to support it.</p>

What a useful software assessment should produce

<p>A brochure website and a customer operations platform can both run in a browser. That does not make them the same development problem.</p><h2>Where a template earns its place</h2><p>For a site that mainly publishes information and takes enquiries, an existing platform or template may cover much of the structure. The remaining work still includes content, design adaptation, forms, accessibility checks, analytics and maintenance.</p><p>Ask who will edit the site and what changes they expect to make. A design that looks good on launch day is less useful if the team cannot update its own content.</p><h2>Where the work moves beyond the template</h2><p>A different problem appears when the website needs to share stock, bookings, customer records or permissions with other systems. The visual template tells you little about how those connections will behave.</p><p>In <a href="/case-studies/cupffee-ecommerce-crm-integrations">our Cupffee work</a>, the integration scope included Zoho product mapping and DHL and DPD delivery calculations. Product sizes and packaging quantities mattered behind the storefront. A comparison based only on page design would miss that work.</p><h2>Compare the same scope</h2><p>Ask both teams to show how their proposal handles your actual requirements. Separate what is included, what needs configuration, what needs development and what cannot be supported. Include licenses, migration, testing, maintenance and access to your data.</p><p>A standard platform, an extension and a custom application are all possible answers. Choose the one that fits the operating requirements and the changes you expect. If the difficult part is the workflow between systems, <a href="/core-business-solutions">start the discussion there</a>.</p>

Custom website or template: where is the work?

<p>Before estimating screens, agree what the first user must be able to finish. A product can look complete in a presentation and still leave the last step to an email or spreadsheet.</p><h2>Describe the task from beginning to end</h2><p>Who starts it? What information do they need? Who receives the result? For a booking service, taking a reservation is only the beginning: someone has to deliver it, handle changes and know whether the information is current.</p><p>That distinction mattered in <a href="/case-studies/custom-crm-platform">ParkFly Geneva’s CRM</a>. Customer bookings needed to connect to availability and mobile access for the team on the ground. The internal workflow belonged in the product scope.</p><h2>Bring examples, including the difficult ones</h2><p>Give the team representative records, current screens and documents. Show a normal task and one that goes wrong. An amended order or a duplicate customer often reveals more about the requirements than a list of feature names.</p><p>Keep three things separate: what the business knows, what it assumes and what the team needs to test. A prototype can clarify an interaction. A working integration can test a technical dependency. Neither proves that customers will buy.</p><h2>Agree who can decide</h2><p>Name the person responsible for priorities and the people who can confirm the business rules. Agree how the team will review progress, what acceptance requires and how a change affects the scope. Include access, data migration and support in the release plan.</p><p>Before committing to the build, you should be able to describe the first task, its boundaries, the dependencies and the evidence that will guide the next investment. <a href="/discovery">Our discovery work</a> turns that material into a delivery scope.</p>

Use the projects to judge the fit

More from the Blog