// Frequently asked

The questions operators actually ask.

Every question on this page was put to us by a customer or a prospect on a real call. The answers keep the parts that are awkward for us, because an answer that only holds when nothing goes wrong is not worth reading.

By Theo Leslie · Updated 31 July 2026

// Getting started

Access, onboarding, what we need from you, and what happens when something breaks.

How long does it take to get something live?

Connecting a source and modelling it is usually a day or two. Getting it running cleanly on a messy database takes a few weeks. Those are two different problems and they're worth separating, because people quote the first number and then get surprised by the second.

Connection is quick where the database sits on your own server and your own people administer it. It's slower where it belongs to a software vendor who has to expose it to us, and that clock isn't under our control, which is why we ask about data access before we ask about projects. Modelling on top of it - making the data usable, so a question in your own vocabulary returns the right answer rather than a plausible one - is fast once the data is reachable.

Then the exceptions, which is where the few weeks go. Every real database has them: the field that meant one thing until four years ago, the same supplier recorded three different ways, the inter-branch transfer booked at zero revenue and full cost. None of that is exotic and all of it has to be worked through before the numbers can be trusted. It's the part nobody budgets for.

A first build on top - a report, an extraction pipeline, a reconciliation - runs in parallel and can land inside the same window. Full coverage across every system you have takes considerably longer and depends almost entirely on how many systems there are.

The honest caveat: when we've been late it has been because a vendor was slow to grant access, or because a field meant something nobody had written down. It has almost never been build time.

What do you need from us to start?

Four things. Read access to the systems that hold the data. Enough of someone's time to explain what the fields mean. Examples of the documents and reports you actually work with. And one named person on your side who can approve access and answer questions.

The second one is the constraint, not the first. Getting credentials to a database is a morning's work. Learning that a particular grade abbreviation means rough-milled and green on sticks, or that a code in one system is the same thing as a differently-named code in another, takes a conversation with the person who has been doing the job for years. A mill general manager walked us through exactly this problem: every qualifying phrase his team says out loud ties back to one or more keys in the system, and none of that mapping was documented. Where there are a dozen values, an hour with a spreadsheet solves it. Where there are hundreds, the system learns them from the history already in the database.

Send us the reports and queries you already run. If someone has built a good query over the years and exports it to a spreadsheet every week, that's the clearest possible statement of what matters to you, and it saves us guessing.

What we don't need is for you to tidy anything up first. The mess is the thing we're being brought in for, and a cleaned-up sample tells us less than the real one.

Will our software vendors need to be involved, and could that cost us?

Sometimes, and sometimes yes. This is the part of getting started that most often causes a delay, so it's worth being blunt about it.

Where a database sits on your own hardware and your own team administers it, no third party is involved at all. Some of the systems in this industry have no API and don't need one, because the data is already yours and already local. Those are the easiest connections we make.

Where the system is a vendor's cloud product, we need them to expose the data. The ask is narrow: give us access to the underlying tables. We do the integration work, so it costs the vendor a few hours at most and there's no joint project for them to staff. Some vendors do this without fuss. Others price data access as a product and quote an annual fee for it - one quoted a customer a four-figure sum per year, which we thought was steep for what was actually being asked. That charge is between you and your vendor; it isn't something we can absorb.

Two things usually help. First, ask for raw data access rather than an integration, because the integration is what they're pricing. Second, the honest framing is that this extends the life of their system rather than replacing it - a customer made that argument to their own vendor and it landed.

If a vendor simply won't expose the data, we'll tell you rather than build something fragile around them.

What does onboarding actually involve?

Four stages, and the order matters more than the speed.

We connect a data set your team already knows well. We pick it for familiarity rather than value or difficulty. People need a feel for what the right answer looks like, so they can tell immediately when something's off.

We model it. This is the bulk of the early work and the least visible: stitching sources together and mapping your vocabulary onto the data so that asking for a familiar term returns the familiar number.

We keep the user group deliberately small for the first few weeks. Two or three people. This is the part customers push back on, and it's the part we hold firm on, because if someone asks a question while the data is half-modelled they'll get a poor answer and conclude the whole thing doesn't work. That impression is far more expensive to undo than a few weeks of waiting.

Then we widen access, and run training for the people joining.

A first build project runs alongside all of this rather than after it, because it's usually why you called. We'd rather do that incrementally than agree a rigid twelve-month roadmap up front. On every engagement so far the priority list changed once people had used the tool for a fortnight and could see what was possible, and a roadmap written before that point is a roadmap written blind.

How do we get access to it - what does everyone log into?

It runs as a connector inside Claude, the AI assistant made by Anthropic. Your organisation's owner or admin adds the connector once. After that each person finds it in their connector list, clicks connect, and signs in with their own credentials. Credentials are issued either by us or by your own internal admin, so you can add and remove people without waiting on us.

There's no new desktop application to roll out beyond Claude itself. Saved dashboards and reports can also be opened directly in a browser, which is how people who don't want to work through a chat interface tend to use it. And there's a Claude add-in for Excel, so anyone who lives in spreadsheets can pull live figures into a workbook without leaving it - which in practice is most of a finance team.

Access is scoped per person. Your admin controls which connected systems and tables someone can query, and can restrict them to certain rows or hide sensitive columns, so the same question returns only what that person is permitted to see. Edit rights are tiered the same way: you can let one or two people change the underlying logic while everyone else can build and save their own work without being able to break anyone else's.

Using it requires your organisation to have a Claude plan.

The Claude subscription is bought separately. It isn't inside the Quarri fee, and we'd rather say so than have it turn up as a surprise line later.

Do we need our own technical people?

No. It changes what onboarding looks like, but it isn't a requirement.

We have customers with a full-time developer or data specialist, and customers with nobody technical at all. Where there's a technical person, we hand over more: some customers do their own data modelling because they want that level of control, and some write and maintain their own scripts inside the platform. Where there isn't one, we hold that work and you interact with the results.

The reason this doesn't gate anything is that building isn't a coding activity here. At one customer, non-technical users have built their own dashboards without asking us, which is not something they'd have attempted with a traditional reporting tool. The limiting factor is knowing what question is worth asking, not knowing SQL.

What you do need is one person who understands what the numbers mean and is willing to review output rather than accept it. That person doesn't have to be technical - on our strongest engagement they're an operations lead, not a developer. What matters is the combination of being open to the tool and being rigorous about checking it. Someone who wants it to fail will find that it does; someone who treats a wrong answer as something to diagnose and fix gets a system that works within weeks.

If you have a technical person, expect them to be busier at the start and largely free of it later.

Can you train our people?

Yes, and it's included as scheduled sessions rather than something you have to ask for.

Sessions run as webinars for business users. We usually wait a couple of months after kick-off before running the first one, so that people are looking at their own modelled data rather than a demo. The content is aimed at people who won't be building anything technical: here's what it can do, here's what other teams have automated with it, here's how to ask for something. Your technical people don't need that session - they get ongoing direct contact with us instead, which isn't rationed.

There's also a written user guide covering querying, building and saving workflows, storing business rules, which model and mode to use, and the specific ways things go wrong. That last section is the useful one and it's deliberately unflattering about the tool.

One thing worth knowing, because a customer raised it as the thing that made the difference for their team: when someone corrects the system's understanding of a term, that correction can be pushed up into the shared layer rather than living in one person's chat history. So the organisation's understanding compounds rather than each person having to re-teach it.

The real obstacle in training isn't the software. It's that many people tried an early model two years ago, got a poor result, and concluded these tools don't work.

Who supports it once it is running, and what happens when something breaks?

You email us. There's no ticket portal and no support tier to navigate.

The split of responsibilities is clear and worth stating, because it determines who you chase. We own the connectors, the data modelling, schema changes, the ingestion infrastructure and keeping your environment separate from anyone else's. You own the things built on top: reports, dashboards, saved workflows, your own manual tables, all within the permissions your admin sets.

Schema changes are deliberately not user-editable. That's a design decision rather than a limitation - it means anyone in your team can build and save freely without the risk of breaking the foundations that everyone else's reports run on. If something you're building needs a structural change, you ask us and we make it.

Three things typically break. A connector stops pulling, or a field changes meaning upstream: ours, and usually invisible to you. A report returns a number that looks wrong: nearly always a definition problem rather than a data problem, and the fix is teaching the shared layer what the term means, which then holds for everyone. A document won't parse: it goes to an exception queue for a person rather than being silently guessed at.

Expect the volume of small fixes to be highest in the first weeks and to tail off. That pattern has held on every engagement.

In practice we respond within a few hours. Something genuinely complicated can take a day or two to resolve, and that's rare rather than routine.

What if we have already started building something ourselves?

Keep going for now, and send us what you have. We have not yet seen a case where a customer's own attempt made the work harder.

Several customers had already built something. One had two separate internal builds of the same document extractor, developed independently by two people who'd approached it from opposite directions and arrived at similar results. Another had characterised most of their document formats and covered the large majority of their volume before we were engaged. All of that went straight into the work. The format knowledge, the lookup tables and above all the written record of what had already failed are the expensive parts to acquire, and they don't have to be acquired twice.

The question customers actually ask is whether to keep pushing or stop and wait. The rule we give is this: if what you're doing is saving someone time this week, keep doing it. If you can't see getting that invested time back within about a month, stop. Nobody should be spending evenings tuning something that's about to be rebuilt.

Two honest caveats. We may build it differently, and if we decide to start fresh we'll tell you why rather than quietly discarding your work. And a prototype running on one person's laptop is not the same thing as a system - what usually needs building is not the extraction but everything around it: surviving a schema change, handling the long tail, proving coverage rather than assuming it, and still running when the person who built it is on leave.

What happens to our existing reports and spreadsheets?

They keep working, and we'd rather rebuild the ones that earn it than all of them.

If your team has SQL queries or stored procedures that produce the reports people rely on, send them. Those can be loaded in as saved reports and run by asking for them by name, on a schedule if you want, with the output landing as a spreadsheet on someone's desktop. You can also do that yourself afterwards: describe the report you want, save it, set it to run every Monday morning.

Spreadsheets don't go away either. There's a Claude add-in for Excel that pulls live figures straight into a workbook, and anything held in the platform exports to Excel on request. For a finance team that has built twenty years of muscle memory in spreadsheets, that matters more than any dashboard.

The question worth asking during onboarding is why each report exists. A number of the reports we're handed exist because a rigid system couldn't answer the question directly, so someone built a workaround, and the workaround became the process. Recreating that faithfully preserves the workaround. We'd rather ask what the report is for and often answer it more directly.

The spreadsheets that are genuinely hard to replace are the ones carrying logic that has never been written down - where the rules sit in one person's judgement. Those need a conversation, not a migration.

And if you stop working with us, everything designed on the platform is yours and gets handed over. The reports, the models, the workflows, the logic - all of it was built for your business and it goes with you. What stays ours is Quarri itself, the engine that runs those workflows. You keep the work; you stop renting the machine it ran on.

We are in the middle of an ERP migration. Should we wait?

No, and you don't have to sequence the two.

This runs alongside a migration rather than competing with it. We simply won't connect to the system you're retiring - we wait until you're on the new one and connect there. Nothing we do requires your migration team to change their plan, take on scope, or hit a joint deadline, because we're not rewiring the connections between your systems. We take a copy of your data and surface it. Your existing integrations stay exactly as they are.

There are two real considerations, and both were raised by finance leads rather than by us.

The first is duplication. A new ERP will cover some of what you'd otherwise ask us to build, and neither of us wants to pay for that twice. That's a conversation during implementation, not a reason to delay.

The second is capacity. One finance director told us plainly that the migration alone was consuming her team, and that thinking about anything else on top felt like a lot at once. That's fair, and we'd rather hear it than have someone agree to a schedule they can't meet.

The counter-argument came from her own colleagues on the same call: they could already name processes the new ERP wasn't going to handle well - detailed line-item calculations that would be awkward to build inside it - and those gaps are most visible during the implementation, not after it. Knowing what the new system won't do is one of the more useful things to come out of a migration.

// The platform

What Quarri is, what it connects to, how answers are grounded, and what it does not do.

What does Quarri actually do?

It takes a copy of the data your systems already hold, models it so the pieces join up, and puts a layer on top that answers questions in plain language and runs the repetitive work.

Three parts, in that order.

A copy. We do not rewire anything. Your ERP, your mill system, your log inventory system and your accounting package carry on exactly as they are, and we read from them on a schedule. One customer told us their systems were already connected end to end and asked whether that made us redundant. It does the opposite - if the links already exist we keep them and surface what is there rather than rebuilding it.

Modelling. Raw exports rarely agree with each other. Most of the early work is making them agree: reconciling units, resolving the same supplier appearing twice under different spellings, and finding the joins that quietly drop rows. On one engagement a case-sensitivity fault in a join was hiding roughly half of the finished inventory. On another, a unit-of-measure labelling error had inflated reported purchase spend by more than $60M. Neither was visible in the source system.

The layer on top. Once the numbers agree, you can ask questions of them in plain English, build reports and dashboards, and hand over the jobs that currently eat a person's week - reconciliations, roll-forwards, month-end packs, document entry.

The connecting is the product. The natural-language part is what makes it usable by people who are not analysts.

What does it actually look like to use?

For most people, it looks like a chat window.

You interact with Quarri through an LLM - Claude, in our case. You ask a question in ordinary language, Quarri retrieves and calculates the answer, and it comes back with the query it ran. There is no separate application to learn for the common case, which matters when the people who most need the answers are production planners and buyers rather than analysts.

Beyond asking questions, four things get used most:

Saved reports. If you already have a query you run every Monday, we can load it in so it runs on that schedule and lands as an Excel or CSV file where you want it.
Dashboards. Built by asking for them. We have seen non-technical users at customers build their own within weeks of getting access, which is not our experience of the traditional BI tools this replaces.
Scheduled jobs. Work that used to mean someone sitting at a laptop watching a script run now happens overnight on a server and is waiting for review in the morning.
Review queues. Where documents are being read, a person checks the items the system was unsure about rather than re-keying everything.

The honest caveat on the first few weeks: while data is still being brought in and modelled, answers can be wrong or incomplete. We ask customers to keep the initial user group small for that reason, and open it up once the answers are clean. Someone who asks a question mid-setup, gets a bad answer and concludes it does not work is a problem we have created ourselves.

What systems does it connect to?

Anything that will surface its data - and the list is wider than most people expect, because documents count as a system.

In timber engagements to date we have connected to lumber and wood-products ERPs, log inventory and scale-ticket systems, forestry management systems, accounting platforms, branch inventory and shipment feeds, credit and AR data, photo-based lift tagging, public weather and open harvest-volume data, and scanned documents by the hundred - regulator invoices, vendor payment PDFs, wood-sales contracts and handwritten field ledgers.

Three points worth knowing before you ask your vendors for access.

We prefer the foundational data over the aggregated version. An accounting system has usually already summarised away the detail that makes operational questions answerable, so where a choice exists we take the operational source and let the accounting system stay the accounting system.

Your vendor may charge for it. Some will quote for an API integration when all we need is read access to the underlying tables, which is a much smaller ask and much less work at their end. It is worth having that conversation before accepting a quote.

And connecting is not the same as integrating. We are not pushing data from one of your systems into another, and we are not touching the connections between them.

On where it sits: we host in the US or the EU, whichever your obligations require. If you need your data to stay in a particular region, say so at the start and it will.

On how long we keep it: for as long as you're using the platform. If you terminate, it's deleted. We don't retain a copy of your operating data after you've stopped being a customer, and there's no version of this where your data outlives the relationship.

What if our system is old, unusual, or has no API?

That is the normal case in this industry, and it is usually workable.

One customer's core operational system is an on-premise SQL database with no API at all, from a vendor whose product they have been customising for well over a decade. That turned out to be easier than a modern cloud product, not harder, because the database sits on their own server and their own team can grant access directly. No API is not a blocker where we can reach the data underneath.

The genuinely awkward cases are different from what people expect. They are:

Cloud products whose vendor will not expose the tables. This is a commercial conversation, not a technical one, and it is one you have to have rather than us.
Systems where the meaning changed partway through the history. Nineteen years of data where a units field started meaning something different in year eleven is harder than any connection problem.
Data that only exists on paper. Which is a document problem, covered below.

What we would not do is build something fragile against a system that cannot support it and let you find out later. Where a source will not give up its data cleanly we say so at the point we find out.

If you are mid-migration, that is not a reason to wait. One customer was replacing their accounting platform while we were working with them. We simply did not connect to the outgoing system and picked up the replacement when it landed.

Does it change our data, or only read it?

Read from your systems. Write into ours.

A mill general manager asked us this directly - whether it only pulls, or can also change and add data. The answer has two halves.

Quarri is read-write, and the writing happens in Quarri's own database. New tables, corrected mappings, reconciliation results, manual entries, decisions recorded by a user - all of that persists and flows through to whatever reads it next. On one engagement a rep reassignment made in the platform carries straight into the next set of actions generated for that account.

Writing back into a source system is a separate question and depends entirely on that system. Some expose a safe write path. Many mill and forestry systems do not, and where that is true we say so rather than forcing it.

There is a judgement underneath this that we will raise with you even though it costs us scope. If your inventory system cannot deduct a consumed item and we build that deduction in Quarri instead, your inventory of record is now split across two platforms. Sometimes that is the right call. Often it is better to push the vendor to add the feature and use Quarri for the things they are never going to build. We would rather have that conversation than quietly become a shadow system of record.

Write-back into accounting platforms is coming soon. It isn't shipped yet, so treat it as a roadmap item rather than something you can plan around today.

Does it hallucinate? How do we know an answer is right?

This is the most-asked question on technical calls. A customer's data specialist put it plainly: if I ask the same question five times, will the answers drift, or is it strictly grounded in our database?

The retrieval is deterministic. When you ask a question, Quarri writes and runs a query against your data and returns what came back. Same question, same data, same answer, and you can see the query. That part does not invent anything.

The LLM sits on top of it, and that is where the real risk lives. It is subtler than invention. The failure we actually see is semantic: the model misunderstands what a word means in your business. One customer had two systems in one database where the same species term meant different things on the forestry side and the mill side, and early answers got confused between them. The fix is not a better model. It is recording the correction once, at the platform level, so it applies for everybody rather than living in one person's chat history.

The other risk has nothing to do with AI. A customer described getting the right answer for the wrong reason - two figures transposed in a scan, and the arithmetic happening to reconcile anyway. That is why we build coverage and conservation checks rather than sampling outputs and hoping. On one build, over 500 assertions run against the numbers on every edit, with zero arithmetic failures across two full reconciliation ties. On another, every one of 8,000+ eligible rows was proven to be accounted for, with no duplication and no gaps.

How does it know what our product codes and grades mean?

It does not, until someone tells it. That is the main piece of work at the start, and it is yours as much as ours.

A mill GM described the problem better than we could: if someone orders four-quarter red pine, light stain, grade three and better, something has to know what that means before it can answer a question about it. The abbreviations, the grade shorthand, the two-letter state codes, which product code implies which species - that knowledge is real, it is consistent, and in most timber businesses it has never been written down. It lives in the heads of people who have been doing the job for twenty years.

Getting it out is usually less work than people fear. When we ask how many distinct values there are for a field like milling state or location, the answer is normally a dozen, not thousands. A dozen can be documented in an afternoon. And where the mapping is implicit in your own history - thousands of orders already keyed correctly - the modelling can learn a great deal from the pattern rather than from a document.

Two things follow from this. The first is that the constraint on a fast start is access to someone who knows the business, not access to the systems. The second is that this knowledge is worth more than the extraction technology it enables. Knowing that a given species only ever goes to one destination, hauled by one contractor, turns reading a smudged document from an open guessing problem into picking from a short list of legal combinations.

What happens with our edge cases and exceptions?

Expect more of them than you think, and expect them to be handled by counting rather than hiding.

A prospect's data specialist asked us this head-on: they had counted 25 to 30 distinct edge-case formats across around 80 vendors on a single document type. That is a normal number in this industry, not a bad one, and any answer that implies the tail will be handled invisibly is wrong.

How it works in practice. The common cases run deterministically. Anything the system is not confident about is flagged with a confidence score and routed to a person, alongside the source document, so reviewing is quick. The exceptions are counted, so you can see week on week whether the tail is shrinking or whether one vendor is generating all of it.

What we avoid is silent auto-correction. We have watched extraction spot an error and fix it, and the fix be wrong. Worse, a customer made the point that matters most here: if the person who created the error never learns they made one, the correction has hidden a problem rather than solved it. Where the source of an error is a human process you can improve, telling someone beats quietly patching it.

The other honest part is that the answer sometimes lies upstream. If one site's documents are unreadable every single time, a change to how they are captured or scanned will beat any amount of work on the reading. Quarri is good at showing you which site that is.

Can it work with scanned or handwritten documents?

Yes, and this is one of the areas where the results surprise people. It is also where we are most careful about what we promise.

Handwritten and scanned material is routine work. On one engagement handwritten field ledgers, scanned regulator invoices and vendor payment PDFs all feed the same reconciliation. On another, a batch of 140+ wood-sales documents was ingested in full, every scanned one recovered, with +1,700 individual line items parsed and the counterparty identified on all but one document. The extraction is replayable, so the same document produces the same result and the result can be audited later.

Where it gets hard is real-world document quality: third and fourth carbon copies, faded thermal prints, watermarks printed over the numbers, handwriting that varies by whoever was holding the pen, and multiple documents on a single scanned page.

Two honest limits.

If a human being cannot read it, nothing can. There will be a small residue of documents that go to a person no matter what, and any vendor telling you otherwise has not looked at your worst tickets. One prospect had already pushed their own in-house extraction from roughly 30% to roughly 80% and could see the same ceiling coming.

And accuracy depends on the document type. A printed tax bill is close to solved. A fourth-copy handwritten haulage ticket is the hardest thing we have seen in this industry, and we will not quote a single accuracy number that covers both.

What does Quarri not do?

A short list, because the things we are not is usually more useful than the things we are.

It is not your system of record. Your ERP, your mill system and your inventory system stay where they are and stay authoritative. Quarri sits above them.

It does not integrate your systems with each other. We are not pushing data from one platform into another or rebuilding the connections between them. If your systems are already linked, we take that as it is.

It is not a migration. Nothing has to be ripped out, and it can run alongside an ERP replacement rather than competing with it for the same people's time.

GIS is not delivered. Geospatial context is real - weather, operability, management-unit and point-coordinate work is live today. Full spatial GIS integration is on the roadmap with no committed date, and we are not going to describe it as finished.

It does not decide. Where we have built optimisation - production scheduling, purchase sequencing - it proposes and a person approves. The same is true of extraction: review points stay in deliberately, and we have resisted customers who wanted them removed early.

It will not reach 100% on documents. See the question above.

And one limitation that is about us rather than the product: we can measure a before state far better than an after state. We can tell you your on-time PO rate to the decimal across every closed order. On most engagements we cannot yet show you the improvement a year later, because the engagements are not old enough.

Is this going to replace people's jobs?

Some tasks, yes. That is the point of it, and pretending otherwise would insult the people asking.

This question comes up on nearly every engagement, and usually from the people who handle the documents rather than the people who bought the software. One customer described exactly that moment - explaining the project to the team who key the tickets, and reading their body language.

Here is what we can say honestly.

The tasks that go are re-keying, re-checking the same figure in a second system, and rebuilding the same spreadsheet every month. One prospect had multiple full-time people on document entry alone and wanted that down to under one. They were open about it.

What we have actually observed is time moving rather than headcount falling. Finance teams get days a month back. A daily production tally goes from a quarter of an hour to a couple of minutes. In the one case where we know what happened to the roles, the customer had people leave voluntarily and chose not to replace them.

The reframing a customer offered is the one we have found most useful, and it was theirs, not ours: the job changes from data entry to data verification. That is not a euphemism. Reviewing exceptions needs someone who knows what a plausible weight for that species on that route looks like, which is exactly the knowledge the person doing the keying already has and never gets to use.

What we cannot tell you is what happens to that time at your company, because that is your decision and not ours. And we have not measured redeployment properly on any engagement. That is a real gap in what we can show you.

Still have a question?

Ask it directly. We would rather answer it than have you guess.

Request a demo → How it works →