The problem
Keep recording sales even when a store could not reach the central system.
A temporary connection failure could not be allowed to stop store operations. At the same time, the company still needed consistent settings and a reliable way to bring the day’s activity back into the central database.
People and constraints
Keep the office, call center, and stores connected without depending on a perfect connection.
- Each retail store operated three to five registers and its own commercial LED sign.
- Store users needed a straightforward transaction interface and reliable peripheral behavior.
- Transactions had to remain available locally when the connection to the central office was unavailable.
- Settings still needed to remain consistent across locations.
- End-of-day synchronization had to move recorded activity into the central database.
- The call center coordinated dispatch and collection pickup through an Access database and needed multiple workstations to submit fax requests through one shared service.
- Secure site-to-site connections had to let central systems reach the stores.
How I framed the problem
Separate the local transaction path from the central synchronization path.
The key requirement was continuity: capture the transaction locally first, protect the local record, and treat synchronization as a later network operation. That boundary kept a temporary connection failure from stopping store work while preserving one central data destination and configuration authority.
What the platform enabled
One connected operating experience across office, call center, stores, and field support.
The public case describes verified capabilities and deployment scope. Client identity, source code, record formats, synchronization mechanics, driver internals, network design, and access details remain private.
What I owned
Developed the software stack and carried it through site deployment.
- Visual Basic
- Visual Studio
- Microsoft Access
- Windows services
- Peripheral drivers
- Site-to-site VPN
How I tested it
Connectivity loss was an operating condition, not an afterthought.
I tested transaction capture with and without central connectivity, persistence of the local record, end-of-day synchronization, central configuration, site reachability, register and peripheral behavior, shared fax submission, and recovery after network interruption. Field support also required tracing failures across application, network, endpoint, telephony, driver, signage, and service layers instead of assuming every issue belonged to the transaction client.
Result
Built, deployed, and supported across several operating locations.
The platform and supporting site technology operated across a corporate office, call center, and several retail locations. Store staff could continue capturing transactions during a central-connectivity interruption and synchronize the recorded activity later.
What I learned
Design around the work people must finish, not the assumption that the network will always be there.
The important question was not whether the network was healthy; it was whether a temporary outage stopped someone from completing a transaction. A modern version would make synchronization health even more visible, test more recovery paths automatically, and give staff clearer guidance when a connection fails.