Connecting Systems From First Inquiry to Delivery and Billing

Most firms run on several systems. A website form, a sales system, a project or delivery tool, an accounting tool, maybe a client portal or learning platform. Each works fine on its own. The trouble is in between. Someone retypes client details from one system into another. A signed deal sits for days before delivery hears about it. Finance invoices from a spreadsheet because the project data never reaches them.

Integrations close those gaps. Accumentum designs and builds them as part of our engineering and platforms work. This is the planning approach that keeps them reliable.

Pick a source of truth for each record

For every kind of record, decide which system owns it. Others can read or mirror it, but only one is the authority.

• Contacts and companies, usually owned by the sales system
• Engagements or projects, usually owned by the delivery system once signed
• Invoices and payments, owned by the accounting system
• Learner progress or portal activity, owned by the platform where it happens

Without this decision, two systems both try to own the same data and overwrite each other. That is how a corrected phone number reverts to the old one overnight.

Map events, not connections

It is tempting to think in terms of "connect system A to system B." It is more useful to list the events that should cause something to happen.

• An inquiry form is submitted, so a contact and an inquiry are created in the sales system with source details.
• A deal is marked won, so a project is created in the delivery system with the client, scope and team.
• A milestone is approved, so the accounting system is told what can be invoiced.
• A project closes, so the client portal archives it and the sales system records the outcome.

Each event becomes a small, testable piece of integration. If one fails, you know exactly what did not happen.

Fields and matching rules

For each event, list the fields that travel and their format in each system. Names, addresses, dates and status values are often stored differently. Decide how to translate them.

Matching rules prevent duplicates. Decide how the system recognizes that an incoming record is an existing client, for example by a company identifier or a verified email domain, and what to do when a match is uncertain. Sending uncertain matches to a person for review is usually safer than guessing.

Plan for failure

Integrations fail. A system is briefly unavailable, a field is missing, someone changes a setting. Good integrations expect this.

• Retry automatically when a system is temporarily unavailable.
• Alert a named person when a sync fails repeatedly.
• Log what was sent and received so problems can be traced.
• Avoid silent partial updates where half the data arrives.

An integration planning checklist

1. System list. Every system involved, its purpose and its owner.
2. Source of truth. The authoritative system for each record type.
3. Event map. Each trigger, what it creates or updates, and where.
4. Field map. Fields per event, with formats and translations.
5. Matching rules. How existing records are identified and uncertain matches handled.
6. Permissions. What each integration is allowed to read and change, kept to the minimum.
7. Failure handling. Retries, alerts, logs and a named owner.
8. Testing. Test cases for normal flow, duplicates and failures before launch.
9. Change process. How changes in one system are checked against integrations before release.

Security and access

Every integration holds a key to at least two systems. Treat those keys with care.

• Give each integration its own account or credential, not a person's login, so access does not break or linger when people leave.
• Grant only the permissions needed for the events it handles. An integration that creates projects does not need to delete invoices.
• Store credentials in a secure place with limited access, and rotate them on a schedule.
• Avoid moving sensitive client information through systems that do not need it.
• Keep a list of every integration, what it touches and who owns it.

Build, configure or connect

Some handoffs can be handled by connectors that the systems already offer. Others need custom work, especially when the logic is specific to how your firm operates or when several systems must stay consistent. The event and field maps make this decision clearer. Simple one way events with standard fields often suit existing connectors. Events with business rules, matching logic or several destinations usually need something more deliberate.

When systems change

Integrations break most often when someone changes a field, a status value or a setting in one system without knowing another system depends on it. Add integration checks to your change process. Before renaming a status or removing a field, check the integration list. After any significant change, run the test cases again. This habit prevents the slow, silent failures that erode trust in the whole setup.

Where to start this month

List every handoff between systems that happens by copying, retyping or forwarding today. For each one, note how often it happens, how often it goes wrong and what a mistake costs in time or client trust. Pick the handoff that scores worst and map its event, fields and owner in detail. Build or configure that one connection, add monitoring and run it for a month before starting the next. A single dependable integration teaches your team more about what good looks like than a large program that tries to connect everything at the same time.

Start with the most painful handoff

Do not try to connect everything at once. Pick the handoff that causes the most rework or delay, often inquiry to sales or won deal to delivery, and build that first. Measure the time and errors it removes, then move to the next one. Each working integration builds trust in the next.

See our operations platform project for an example, or request a Digital Growth Assessment for an outside view of where data gets stuck in your business.