Timelines

It depends on the team you need and on what has to be in place first: the contract, access to your systems, security reviews and, for integrations, your partners’ test environments. We tell you what we need from you and when, and confirm a start date in the proposal. Discovery work can often begin while access is being arranged.

Link to this question

A prototype on your data comes first, so you can judge results before committing to the full build. The time to production depends on data access, security reviews, the integrations involved and how much the evaluation shows needs fixing. Access to data and approvals is often the longest step. We plan these early and give you a timeline after discovery.

Read more: AI developmentLink to this question

Users can try a prototype on your content early, before the full build. What takes longer is connecting sources with the right permissions, security and privacy reviews, and reaching the agreed quality on the evaluation set. We plan those steps from the start and give you a timeline once the sources and the job are clear.

Read more: Generative AI and LLM integrationLink to this question

The baseline and first validated model come early, so you can judge the value before the production work. Getting to production depends on data access, integration with the systems that use the result, shadow running beside the current process and any model-risk review. We give you a plan after the data review, with the decision points marked.

Read more: Machine learningLink to this question

We deliver in subject areas, so the first one, such as cash or sales, reaches users well before the whole platform is finished. Timing depends on access to source systems, data quality and how much reconciliation the figures need. We agree the order of subject areas with you and plan each one after the assessment.

Read more: Data engineering and analyticsLink to this question

The first document type, usually the highest-volume one, can go into a pilot before the others are built. The time to a pilot depends on access to sample documents and to the ERP interfaces, and on how many rules the process needs. We plan document types in order of value after mapping the process.

Read more: Intelligent automation and document AILink to this question

It depends on the scope of the first release, the integrations it needs and how quickly decisions are made on your side. We prefer a small first release that real users can work with, followed by regular increments, over a long build with a single launch at the end. After discovery we give you a release plan, and we report progress against it at every demonstration.

Read more: Custom software developmentLink to this question

It depends on the number of systems and flows, how well each system’s interfaces are documented, the state of your master data, and how quickly test environments and access are ready. Partner approvals, such as a bank or a marketplace, can set the pace too. After the assessment we give you a plan flow by flow, so the most valuable connection goes live first.

Read more: ERP integrationLink to this question

It depends mostly on the bank, not on the code. Each bank sets its own onboarding steps, test windows and approvals, and some need contracts or key exchanges before testing can start. The number of banks, payment types and countries matters too. After the mapping step we give you a plan per bank, and we start testing with whichever bank is ready first.

Read more: Bank integrationLink to this question

It is set largely by the gateway or acquirer: their test windows, the number of test cases and how many rounds it takes. We prepare the test scripts and evidence before the window opens, which shortens the rounds, and we plan the rest of the work around the provider’s calendar. We share that plan once the provider confirms its process.

Read more: Payments and POS integrationLink to this question

It depends on the quality of the partner’s API and documentation, whether it has a usable test environment, how quickly accounts and keys are issued, and how complex your data mapping is. Partner approval steps can set the pace. We give you a plan per partner after the inventory and start with the connection that removes the most manual work.

Read more: Third-party and API integrationLink to this question

That depends on the scope, the number of systems and teams involved, how quickly decisions are made, and how ready third parties such as banks or vendors are. After discovery we give you a plan with milestones and their dependencies, and we report against it throughout the project.

Read more: Project-based deliveryLink to this question

It depends on the size of the question and how quickly we can reach the people, documents and systems involved. A focused review of one system or decision is short; an assessment of a whole technology estate takes longer. We agree the scope and the date of the final readout before we start.

Read more: Technology and architecture consultingLink to this question

It depends on the number of business areas involved and how quickly we can meet their people and reach the data and systems. We agree the workshop schedule and the date of the final presentation at the start. The pace is set mostly by the availability of your teams.

Read more: AI readiness assessmentLink to this question

Yes. We go live in stages, starting with a pilot store, and run the new integration alongside the current process until the totals agree. Changes in stores are scheduled outside trading hours where possible, and each stage has a way back if something does not work as planned.

Read more: Retail and POSLink to this question

Each bank provides a test environment or a test process. We agree a set of test cases with the bank, covering each payment type, rejections and statements, run them, and keep the evidence. When the bank signs off, we go live with a small first payment run and compare the results before moving the rest.

Read more: ERP and banksLink to this question

We start with a pilot in a few stores and compare their totals with the current process every day. Once the totals agree, we roll out in groups, at a pace your store operations team can support. The old process stays available for each store until its new flow is proven.

Read more: POS and ERPLink to this question

With a conversation about what you need. We follow up with a written proposal: the model, the team or the scope, how cost is set and how the work will be governed. Once you agree, we introduce the people, set up access and start. How quickly that happens depends on the roles and on the access your systems need.

Read more: How we workLink to this question