Map one handover between business tools. Define record ownership, matching, retries and reconciliation before deciding whether AI belongs in the workflow.
When staff copy information between systems, start by following one piece of work across the boundary. A list of installed applications does not reveal which record is missing, who owns it or what would count as a successful transfer.
The first useful deliverable is a handover specification: the trigger, the source record, the destination record, the permitted change and the person responsible when it fails. This can improve a manual process as well as guide an integration.
Map a completed job to an invoice draft
Consider a fictional repair business. A technician completes job J-218 in a scheduling system. Accounts needs an invoice draft in its billing system. The scheduling tool knows the work performed; billing holds the customer account and agreed payment terms.
“Job complete” does not necessarily mean “ready to invoice”. A disputed extra charge or an unsigned completion record may still need attention. Define the eligibility rule before making that status change a trigger.
| Information in this example | Handover rule to agree |
|---|---|
| Job identity | Retain J-218 as the reference linking the source job and invoice draft |
| Customer identity | Use a verified account mapping; stop if the match is ambiguous |
| Completed work | Transfer approved line items and quantities from the job record |
| Payment terms | Read the current billing account terms rather than overwrite them |
| Existing invoice | Find and reconcile a previous draft before creating another |
| Exception | Assign an owner and explain which evidence is missing |
This is an illustrative division of responsibility. Your systems may assign these fields differently. The important part is recording the decision so two integrations do not both claim authority over the same value.
Test delivery behaviour, not just field mapping
An event notification can be late, repeated or followed by a correction. Stripe’s webhook documentation, for example, explicitly discusses duplicate events and delivery without guaranteed ordering. That describes Stripe’s interface; check the actual delivery guarantees of each connector you use.
For the repair example, send the same completion event twice in a test environment. Confirm that accounts receives one intended invoice draft. Then deliver an older event after a corrected quantity. The integration should not silently restore the obsolete value.
A lost response also needs a defined outcome. If billing created the draft but the connection timed out, a retry should first establish what already exists. Keep a correlation reference that lets an operator follow the same job across both systems.
Reconcile what should exist with what does exist
An error log shows detected failures. It does not necessarily reveal an event that was never sent. Compare the set of eligible completed jobs with the corresponding invoice records, and investigate missing, duplicate or mismatched entries.
Choose a reconciliation interval that fits the invoicing process. Record the oldest unresolved item and who will act on it. “The connector is running” is a weaker operating measure than “every eligible job is accounted for”.
Keep access limited to the records and changes this handover needs. A billing integration does not automatically need the full contents of customer emails or unrelated employee records.
Decide whether a model adds anything
If the source already supplies approved item codes and quantities, a fixed mapping may be enough. A model could help interpret free-text technician notes, but its proposed line items need their own checks and should not bypass the approval rule.
Measure the complete handover: preparation, review, exceptions and corrections. Compare it with the current method before expanding to another boundary. Use integration services to assess the connection and process optimisation to settle the rules it must preserve.
