A retail platform, over time.

01

Why retail needed its own platform.

I first used the retail system as a seasonal employee. SBI supported retail alongside wholesale and manufacturing, but retail had its own requirements: a fast checkout path, practical stock records, useful reporting, gift cards and a credible route toward ecommerce.

One visible problem was payment entry. Cashiers entered the amount in the POS and again at the terminal. That was not just an inconvenience. It created another opportunity for a mismatch at the point where a sale, a payment and the day-end record needed to agree.

We first put Alice POS into production as an intermediate replacement. It gave us a working retail environment while I continued evaluating what a longer-term platform needed to do. NCR CounterPoint became the system that could carry retail further.

02

Implementing CounterPoint.

The implementation began with business requirements rather than a software installation. I evaluated the platform, worked through quotes and commercial choices, selected hardware and workstations, and made the configuration decisions needed to fit the retail operation. The integrator supplied CounterPoint product expertise, base application and database support, proprietary technical work and escalation. I owned what the system needed to accomplish for the business and whether the result worked in production.

We created new retail item records rather than automatically carrying legacy records into the replacement. I established opening inventory and designed the category and reporting hierarchy that would make the data useful later. Customers, gift cards, payments, staff access and day-to-day procedures all had to be considered as parts of one operating system rather than as isolated setup tasks.

The work also included acceptance. I tested workflows, followed issues through with the integrator, developed SOPs and trained staff. Go-live was not the moment the project ended; it was the point where the platform became accountable to real transactions, real stock and the people relying on it every day.

SBI remained useful for wholesale, manufacturing and crop planning. CounterPoint took responsibility for retail, where the business needed a more specialized operating model.

03

What CounterPoint became.

CounterPoint became much more than a register application. It was the retail operational core for point of sale, inventory, purchasing work, customer records, gift cards, payment processing, reporting, ecommerce connections, peripherals and the controls around those activities.

Not every product capability mattered equally. The important question was always whether a function supported a real retail process: receiving and selling stock, serving a customer, producing a label, reconciling a payment, answering an operating question or deciding what to buy next.

That breadth is why the system needed business ownership. A technically successful installation would not be enough if the categories did not support reporting, the payment path added risk, staff did not have usable procedures or the information could not support a purchasing decision.

04

From implementation to system ownership.

There was never a point where CounterPoint was finished. Once it became a core system, application upgrades, Windows and workstation changes, payment generations, hardware refreshes, user access, configuration, reporting and connected services all became business-system decisions.

My role was to recognize a change before it became a disruption, clarify the requirement, coordinate with the integrator when product-specific work or escalation was needed, test the result and decide whether it was ready for the people who had to use it. That often meant retraining, revising an SOP or changing the surrounding workflow as well as changing a technical setting.

Troubleshooting followed the same pattern. I could investigate the data and the operating path, build diagnostics where needed, reproduce an issue and give the vendor a useful description of what had actually happened. The integrator remained responsible for its software, database support and proprietary services; I remained responsible for the operating environment around them.

05

A Canadian payment-terminal migration.

One payment migration made the dependency chain especially visible. The existing IPP320 platform had a December 31 retirement deadline. A replacement required coordination across the merchant environment, Moneris, Tender Retail, NCR, a required CounterPoint release and the integrator's configuration work.

Certification and confidence testing were still incomplete as the deadline approached. CounterPoint 8.5.7.1 was required for the replacement path but had not yet been released. A contingency involving standalone external terminals was considered while the integrated path was delayed.

I opposed treating standalone terminals as an equivalent answer. Integrated payment entry was one of the reasons we had implemented CounterPoint: the POS should hand the amount to the terminal instead of asking a cashier to enter it twice. Returning to manual entry would recreate cashier error and reconciliation risk at the exact control point the system was intended to improve.

The decision also had cost and operational consequences: terminal rental, Tender Retail licensing, upgrade work and the burden of a changed checkout process. I asked questions about the certification chain and technical assumptions, evaluated the contingency against the business requirement and participated in testing and acceptance rather than simply accepting a vendor workaround.

06

Learning the Canadian payment environment.

Canadian terminal behaviour became a recurring area of work because issues could appear first in a smaller local configuration. Over time I became closely involved with the integrator in reproducing problems, validating configurations and testing the paths that would be used in production.

That did not make me an NCR payment engineer, and I do not present it as a formal vendor title. It did make me a practical business-side resource: someone who understood why an integrated payment path mattered, could explain what staff were seeing and could help distinguish a configuration question from a product or certification dependency.

The useful output was evidence. A reproducible problem, a tested terminal path or a clear acceptance result gave the integrator and vendor something concrete to act on. It also gave the business a basis for deciding whether a change was safe to introduce at the tills.

07

Reporting became operational infrastructure.

The reporting structure was part of the implementation, not a later add-on. Categories and item organization determined whether retail performance could be understood after the sale. CounterPoint's SQL-backed data and Crystal Reports gave that structure an operational life beyond the checkout screen.

I worked with SQL and reporting tools to produce operational and management views, investigate issues and support the questions that arise when stock, pricing or sales patterns do not look right. Reports were useful because they connected transactions to decisions, not because they were technically elaborate on their own.

That created an important loop in my work. I helped define the retail data structure, maintained the system producing the data and later used its reporting for hard-goods purchasing decisions, including adjusting commitments and trying new products. Other departments continue to make plant-buying decisions.

08

CounterPoint became connected.

The platform accumulated connections because retail work does not stop at the till. Shopify provides the ecommerce storefront, Mailchimp supports customer communication and the accounting integration carries its own handoff. The integrator supplies those Shopify, Mailchimp and accounting integrations; they remain vendor software and vendor-supported connection points.

My responsibility is the business environment around those connectors: storefront operation, ecommerce workflows, configuration, testing, diagnosis and the practical question of whether information is arriving where staff and customers need it. I built and configured the Shopify storefront, and I operate and troubleshoot the combined environment without claiming authorship of the connector itself; the connector itself is vendor software.

The same environment includes label output, SQL and Crystal reporting, payment services and custom diagnostics or internal tools. Those tools help trace a question to the part of the process that needs attention. They are not substitutes for the vendor platform; they make the surrounding operation more observable and manageable.

09

The system changed because the business changed.

Some changes were technical: new payment hardware, application releases, workstation compatibility or a connector update. Others began in the business: a different customer programme, an ecommerce need, a new reporting question, a revised checkout process or a product and category decision.

Gift cards are a small example with a larger systems consequence. We moved gift-card management into CounterPoint and replaced magnetic-stripe cards with custom-printed barcode cards. The change affected the retail workflow, the physical card, staff practice and the system record together.

This is the distinction between maintaining software and owning a business system. The work was not to keep CounterPoint unchanged. It was to keep retail operations coherent as the business, its customers and the surrounding technology changed.

10

The current retail environment.

CounterPoint remains the retail operational core. It sits within a broader environment that includes Shopify, Mailchimp, integrated payments, SQL and Crystal reporting, label output, accounting handoff and targeted internal tools. Each element has a different owner, support path and operational purpose.

I still maintain the business side of that environment: I investigate failures, work with the integrator when vendor intervention is required, test changes, support staff and adapt procedures as the operation evolves. I still work on the system, and I also rely on it to decide what we buy. The platform's value comes from those relationships being understood and maintained, not from any one application being treated as self-sufficient.

The original implementation matters because it established a capable retail foundation. The longer story is the years of decisions required to keep that foundation aligned with the business that depends on it.