A material study photographed in bright daylight. Six broad pleated blades of clear turquoise glass sweep in from different directions across the right of the frame and interlace into one tight bundle before continuing past each other, two pearl silver ribbons running the length of the weave. The left of the frame is empty pale mint.
  1. Home
  2. Services
  3. Integrations and data

One of the eight services

Integrationsand data.

Integration work is the connection between the systems you run, so an order, a lead or a payment appears everywhere it is needed without a person carrying it across.

A written map of which system is right about what, and an alert to a named person when two of them disagree.

Book a discovery call Request a performance audit

Know what you are building? Book a discovery call. Not sure where the problem is? Request the audit.

HUREAL / Material studies

Block 02

Soundslike this?

  1. Somebody exports a file out of one system every Monday and imports it into another.

  2. Our sales team retypes inquiries into the CRM out of an inbox.

  3. The stock number on the website is a number a person updates by hand, when they remember.

  4. Two systems disagree about a price, and there is an argument about which one is right.

  5. Month end takes a week, and most of that week is reconciling.

  6. We are buying a new system, and nobody has written down what it has to fit into.

  7. When a transfer fails, we hear about it from a customer.

If none of those is familiar and the real problem is that work sits in a queue until somebody gets to it, the connection is not the missing piece and Agentic Operating Systems is the page for that.

Block 03

What this is,in plain language.

What happens today

An order is placed on the website. Somebody opens the order, opens the accounting package, and types it in again. On Monday a file comes out of the warehouse system and goes into a spreadsheet, and the spreadsheet decides what the website says about stock until next Monday.

Nothing here is broken, exactly. Five systems each hold part of the truth and a person carries the rest between them. The business is running on somebody's memory of which screen to trust.

What happens after

The order placed on the site appears in the accounting package with the same identifier it has everywhere else. The lead from the form arrives in the CRM with its source and its owner. The payment reconciles. Stock on the website is stock in the warehouse, and it is that at four in the afternoon as well as at nine in the morning.

When two systems disagree, nothing is silently overwritten. It stops, a named person is told, and the decision they make is recorded. The exception is a queue rather than a discovery.

Most businesses do not have a software problem. They have a translation problem.

Five systems each hold part of the truth, and somebody exports from one and pastes into another every week. Integration work removes that person from the middle, and it starts with a question rather than with code: which system is right about which field. Most integration problems are really that question left unanswered, and a connection built before it is answered does not settle the argument, it encodes it.

The unglamorous part is where the value is: what happens when a system is down, when a record is a duplicate, when a field is empty, when two systems disagree. We design those cases deliberately, because an integration that only works on a good day creates more work than it removes.

Block 04

Who this is for,and who it is not for.

Where this pays for itself

  • Somebody exports and imports on a schedule, and everybody knows whose job it is and which day it happens.
  • Three or more systems hold overlapping records, and none of them is agreed to be the one that is right.
  • The website should show real stock and real pricing, which for a distributor or a manufacturer is the difference between a catalogue and a shop.
  • Inquiries are retyped into the CRM, which is also where the source and the owner quietly disappear.
  • A new system is being bought, and what it has to fit into has not been written down yet.
  • A number has to be explained to a board, an auditor or a customer, and today the explanation is a person's recollection.

You probably do not need this if

  • Two mainstream systems already have a supported connection between them. Turn it on. It is usually configuration rather than a build, and paying anybody to rebuild it is paying twice.
  • It is a handful of records a month. Ten minutes of somebody's time once a month costs less than anything we would build, and it does not need monitoring.
  • Nobody can say which system owns a field. That decision is the project. Until it is made, a layer built over the disagreement makes the disagreement automatic and much harder to see.
  • One of the systems is being replaced this year. Connecting the one that is leaving is work with a known expiry date, and waiting is usually the cheaper plan.
  • The requirement is a single dashboard rather than connected systems. That is reporting, it reads rather than writes, and it is a smaller job than this one.

Where an automation tool does the job, we will say so, and we use them ourselves where they fit.

Block 05

What itincludes.

Fifteen capabilities, what each one does in plain words, and what it changes for the business. The first group is the one people try to skip, and it is the one that decides whether the rest of it works. None of the three headings is a link, because the pages beneath this service have not been written yet and a heading that promises one is a heading that lies.

Integrations and data, the capability table
Capability What it does What it changes
Decide the truthBefore any connection is built
System inventory What you run, by name and version, who owns each one internally, and what each is the truth for. The argument about which screen is right happens once, in a room, instead of every month.
The direction of truth Which system owns which field, agreed and written down before anything is connected. An overwrite is a rule somebody chose rather than an accident somebody discovers.
Connection assessment What each system's interface actually allows, what it costs, and where its limits are, including the old and locked-down ones. The unpleasant surprise happens during scoping, which is the only phase where it is cheap.
Mapping and matching rules Fields, identifiers, and the rule that decides when two records are the same record. The same customer stops existing three times under slightly different names.
Build the connectionsOne at a time, proven before the next
Synchronization design Real time, scheduled or on demand, chosen per connection with the reasoning written beside it. You are not paying for live updates on a field that changes twice a year.
The connections themselves Built one at a time, proven in a test environment, then live, then the next one. A failure is traceable to one connection instead of to a launch.
Error handling Retries, queues, alerts, and what a person sees and does when something cannot be resolved automatically. The integration still behaves on the day one system is down.
Duplicate and conflict rules What happens when two systems disagree, and which disagreements stop for a person instead of resolving quietly. Nothing important is overwritten by whichever system wrote last.
Historical migration Where the connection also needs the past, moved once, checked, and reconciled against the source. Reporting works across the join instead of starting from the day you switched on.
The test environment A place changes are proven before they touch live data, kept after launch rather than dismantled. The next change is also safe, which is the part that pays for it.
Run themAfter launch, because a connection is not a delivery
Monitoring Every connection watched, with alerts pointing at a named person rather than at a shared inbox. You hear about a failure from us rather than from a customer.
The transfer record A record of what moved, when, and what happened to it, kept for the times a number has to be explained. An awkward question has an answer that is not somebody's recollection.
The exception queue The screen a person works in when a transfer stopped, showing what stopped and why. The unresolved cases are a short list rather than a silence.
Documentation per connection What it does, what it maps, what it retries, written for whoever maintains it next. A developer who has never met us can pick it up without calling us.
Volume and failure reporting Monthly: what moved, what failed, what was resolved by a person, and what changed since last month. The connections stop being invisible until the day they break.

Scroll the table sideways to read it.

Block 06

How itworks.

Almost everything on this board is already yours. One plate in the middle is the work, one line near the bottom is the part that stays with a person, and the route across the top is the one that stops.

Scroll the drawing sideways to read it.

Nine systems, one layer, and one broken line across the top. The break is the deliverable.

What the system does

The work, the path it takes, and everything HUREAL builds. It never means anything else.

What stays with a person

The line, its single opening, and the plate standing in it. On a light board it is the one dark plate.

What you already run

Present, named, and not for sale. The lowest contrast on the board, deliberately.

  1. Everything on the board except one plate is already yours.

    Your website, your app and your store on one side. Your CRM, ERP, accounting, booking, marketing and analytics on the other. They are drawn in the quietest tone on the board on purpose: this service does not replace any of them, and a proposal that starts by replacing three of them is a migration wearing an integration's name.

  2. The route across the top is the one that stops.

    It is drawn, and then it is cut. That route is a person exporting from one system and pasting into another on a schedule, and it is the thing you are actually buying the end of. It is also the only line on the board that nobody designed.

  3. One layer, and one direction per field.

    The plate in the middle is the whole build. It holds the map: which system owns price, which owns stock, which owns the customer's address, and what happens to the other copies when the owner changes. That map is agreed in phase one, in a room, before a line of it is built.

  4. What crosses, and how often, is a decision per connection.

    Every arrow carries what moves and on what cadence. Real time where a customer is waiting for it, scheduled where nobody is, on demand where it is expensive. Choosing live updates everywhere is how an integration becomes costly and fragile at the same time.

  5. When two systems disagree, it stops at the line.

    Retry, queue, alert to a named person, and a queue that person actually works in. Nothing important is resolved by whichever system happened to write last, and every resolution is in the transfer record, which is what makes a number explainable later.

Bring the list, by name and version. Which systems you run, who owns each one internally, and which screen your team trusts when two of them disagree. That list plus a discovery call is the whole of phase one, and the map that comes out of it is yours whether or not you build anything.

Book a discovery call

Block 07

What youend up with.

  • The system inventory

    Every system by name and version, what it is the truth for, who owns it internally, and what its interface actually allows.

  • The direction of truth

    Which system owns which field, written down and agreed, which is the document the whole build is measured against.

  • The field map

    Fields, identifiers and matching rules per connection, including what counts as the same record.

  • The connections

    Built one at a time, each proven in a test environment before it touched live data.

  • The failure design

    Retries, queues, alerts and the human path, written as a document rather than left as behaviour to be discovered.

  • The exception queue

    The screen a person works in when something stopped, showing what stopped, why, and what happens if they do nothing.

  • The transfer record

    What moved, when, and what happened to it, kept for the times a number has to be explained to somebody.

  • Monitoring and alerts

    Live before launch day, pointing at a named person rather than at a dashboard nobody opens.

  • Documentation per connection

    Written for a developer who has never met us, because being difficult to replace is not a business model we are interested in.

  • The test environment

    Kept after launch rather than dismantled, so the next change is as safe as the first one was.

V3. The direction of truth, drawn

your-company/integration/field-map 6 fields, 1 unowned

Which system is right about what

Agreed in phase one. Every connection is built to this and nothing is built before it.

  • List priceOwner: the ERP

    Read by the store and the CRM, written by neither. A price changed anywhere else is rejected and the attempt is in the record.

    One way
  • Stock on handOwner: the warehouse system

    Pushed to the store every few minutes, and the store shows the time it was last true rather than implying it is live.

    One way
  • The customer recordOwner: the CRM

    Created wherever the customer first appears, then owned by the CRM. The identifier it is given there travels with it everywhere else.

    One way
  • The orderOwner: shared, in sequence

    Created by the store, owned by the ERP from the moment it is accepted. The handover point is a line in this document rather than a convention.

    Two way
  • Payment statusOwner: the accounting package

    Nothing else may mark an invoice paid. The store is told, and the store does not decide.

    One way
  • The delivery addressOwner: not decided

    Three systems write it and none of them is agreed to be right. It stops here until somebody on your side decides, and nothing is built over it in the meantime.

    Unowned
Every one of these documents has a row like the last one, and finding it is most of the value of phase one. A connection built over an unowned field does not settle the argument about it. It makes the argument automatic, and much harder to see.

On every HUREAL engagement, whichever of the eight it is

  1. A written scope with a fixed price and a timeline, before any code.
  2. The working build, reviewed at every phase, in your own accounts.
  3. Full ownership of the code, the content and the data, with admin access from day one.
  4. A named contact who is accountable for the work.

Block 08

How anengagement runs.

Five phases. You can stop after any of them, and every one produces a document you own.

  1. 01

    Discovery call

    A discovery call with the people who own the systems. We inventory what you run by name and version, and answer the question underneath every integration problem: which system is right about which field.

    How long
    One call. The written proposal follows it.
    Your people
    Whoever owns each system, plus whoever can settle a disagreement between two of them.
    You end up with
    The inventory, the direction of truth, and a written proposal with a scope, a price and a timeline you can sign or walk away from. Yours either way.
  2. 02

    Design

    Mapping, matching rules, synchronization cadence per connection, and the failure design: retries, queues, alerts and what a person sees. All of it agreed while it is still a document rather than a behaviour.

    How long
    Set in the signed proposal.
    Your people
    Whoever knows what the data actually means, which is rarely the same person who administers the system.
    You end up with
    The field map, the matching rules, and the failure design, per connection.
  3. 03

    Build

    One connection at a time. Proven in a test environment against real shapes of data, then live, then the next one. Nothing goes live as part of a batch, because a batch failure is a failure with no address.

    How long
    Set in the signed proposal, with the review schedule agreed in it.
    Your people
    Access to a test environment, and somebody who can confirm a transfer looks right.
    You end up with
    Each connection live and proven on its own, in your accounts, with its documentation written as it lands.
  4. 04

    Launch

    Monitoring and alerts live before the first real transfer, the exception queue staffed by a named person, and the same fourteen published checks every HUREAL build passes.

    How long
    The checklist against the finished build, plus the first full cycle of every scheduled transfer watched end to end.
    Your people
    Whoever will work the exception queue, and an admin sign-in before launch day.
    You end up with
    A launch record against fourteen named checks, and alerts that point at a person rather than at an inbox.
  5. 05

    Run

    Monitoring, the exception queue, and a monthly report on volume and failures. When one of your systems changes its interface, which happens on their schedule and not yours, the change is handled rather than discovered.

    How long
    Monthly, for as long as you want it. Cancellable at any time.
    Your people
    One read of the monthly report and whoever works the exception queue.
    You end up with
    A written report: what moved, what failed, what a person resolved, and what changed since last month.

What makes it longer: how old the systems are, whether any of them has no real interface, how much history has to move with the connection, and how many fields turn out to have no agreed owner. What does not make it longer: how many connections you eventually want. The second one is faster than the first every time, because the map, the monitoring and the exception queue are already built.

Read the whole method, including the fourteen launch checks

Block 09

What itconnects to.

By category, because the category is the question. On this service the honest answer is a list plus a qualifier, and the qualifier matters more here than anywhere else on the site: an old system connects through whatever door it has, and sometimes that door is a scheduled file.

  • CRM

    Where the customer record, the source and the owner live, and usually where the identifier everything else refers to is created.

    Salesforce, HubSpot, Zoho, Dynamics

  • ERP and accounting

    Where price, cost, credit, invoices and stock are true, which is why it is usually the owner of more fields than anything else.

    NetSuite, SAP, Sage, QuickBooks

  • E-commerce

    Where the order starts, and where the catalogue has to agree with whatever the warehouse thinks.

    Shopify, WooCommerce, BigCommerce

  • Booking and scheduling

    Where a slot or a job is held, moved or released, and where a double booking is the failure everybody notices.

    Calendly, Acuity, an in-house dispatch board

  • Marketing and email

    Where a contact is sent something, which means consent has to travel with the record rather than be assumed at the other end.

    Mailchimp, Klaviyo, HubSpot

  • Analytics and reporting

    Where the numbers are read, which is the one direction where a copy of the data is usually the right answer.

    a warehouse, a reporting database, your existing analytics

  • Payments

    Where money moves, and where reconciliation either happens automatically or happens on somebody's Friday.

    card processors, Interac, your bank's file formats

  • Documents and storage

    Where the signed thing, the drawing or the certificate lives, which is often the attachment a record is useless without.

    SharePoint, Google Drive, Dropbox

  • Your industry system

    The one system that runs your trade. It is usually the oldest, the most important, and the one nobody else offers to connect to.

    dispatch, estimating, practice management, warehouse management

Every connection is validated by HUREAL's engineers during scoping and confirmed in writing before signature. Where a system genuinely cannot be connected, you hear it during discovery rather than during the build, and the scope is drawn around it instead of making a platform migration the price of entry.

Block 10

What we do,and what we will not do.

What we do

  • Answer the question firstWhich system owns which field, written down and agreed, before a connection is built.
  • Check every doorEach system by name and version, and what its interface actually allows, confirmed in writing during scoping.
  • Design the bad dayRetries, queues, alerts and the human path, specified before the good day is built.
  • Build one connection at a timeProven in a test environment, then live, then the next, so a failure has an address.
  • Alert a personEvery failure points at a named human being rather than at a shared inbox or a dashboard.
  • Keep the recordWhat moved, when, and what happened to it, so a number can be explained months later.
  • Document for the next developerWritten for somebody who has never met us, because being hard to replace is not a business model we want.

What we will not do

  • Build over an unowned fieldWhere nobody will say which system is right, we stop and say so. A layer over a disagreement automates the disagreement.
  • Rebuild a connection that already existsWhere two systems have a supported connection, turn it on. Charging to rebuild it is charging twice.
  • Let a failure be silentNo retry loop that gives up quietly. If it cannot be resolved, it queues and somebody is told.
  • Make a migration the price of entryWhere a system is hard to connect, the scope is drawn around it. Replacing your software is not our opening offer.
  • Move data nobody needsEvery field that crosses a connection has a reason to be there, and the ones that do not are left where they are.
  • Ship without a test environmentIf there is nowhere to prove a change before it touches live data, that is the first thing we build.
  • Sell a layer where ten minutes a month would doAt a handful of records, a person is cheaper than anything we would build and needs no monitoring.

Every one of those is in the scope document before you sign it, which is the only place a commitment is worth anything. The first line in the right column is the one that stops projects, and it stops them in phase one rather than in month three, which is the only difference that matters.

Block 11

A person, a wiring tool,or a layer.

Three ways to get a record out of one system and into another. They cost different amounts, they fail differently, and two of the three are often the right answer.

The three approaches, on ten deciding factors
Deciding factor A person and a spreadsheetManual An automation tool, wired point to pointSubscribed A built integration layerBuilt
Cost to start Nothing. It is already happening. Low. A subscription and an afternoon. Highest. It is a build, and the first phase is a decision rather than code.
Cost to keep The same hours every week, forever, and they are somebody's Monday. A subscription that usually rises with the number of operations. Hosting, plus the monthly arrangement if you want one. Both declinable.
What happens as volume grows The hours grow with it, in a straight line. Cost and fragility both grow with it, and the fragility arrives first. Volume is the part that does not cost more.
When one system is down The person notices, and does it later. It depends on the tool, and a quiet failure is common. It retries, then it queues, then it tells a named person.
A record that does not match Judgement, applied consistently and written down nowhere. A second record, usually discovered later by somebody else. Matching rules you agreed, and an exception queue for the rest.
Who knows how it works One person, and it leaves with them. Whoever built the scenario, if they still work there. A document written for a developer who has never met us.
Adding the fourth system Another routine on the same person's Monday. More wires between more pairs, which is where the count multiplies. One more connection to a map that already exists.
Explaining a number six months later Recollection. Partial logs, kept for as long as the plan keeps them. The transfer record: what moved, when, and what happened to it.
Where it lives A shared drive. The vendor's account, on the vendor's terms. Your own cloud accounts, under your admin access, from the first commit.
When it is the right answer A handful of records a month, and nobody is waiting on them. One or two connections, modest volume, two mainstream systems, simple matching. Three or more systems overlap, the volume is real, and somebody has to be able to explain a number.

The verdict, including where it goes against us

If it is a handful of records a month, keep the person. Ten minutes on a Monday costs less than anything we would build, it needs no monitoring, and automating it would be buying a system to save a number of minutes you could count on one hand.

If it is one or two connections between mainstream systems at modest volume, buy the automation tool. They are good at exactly that, we use them ourselves where they fit, and paying for a build to get it is paying twice. They get fragile with volume, with complicated matching, and when nobody owns them, which is the point at which this conversation is worth having again.

A built layer earns its cost in a narrow place: three or more systems hold overlapping records, the volume is real, a failure costs money or a customer, and somebody has to be able to explain a number to a board or an auditor. That is the whole case. The discovery call is where we find out whether you are in it, and the inventory that comes out of it is useful to you either way.

Block 12

What a Canadian buildhas to be designed around.

An integration moves personal information between systems that were each chosen for a different reason, sometimes into a different country, usually without anybody watching it happen. These are the requirements this service is designed around, and the line between what we build and what your counsel decides.

  • Where the data livesAnd which processor sees it, which on this service is the first question rather than the last

    What we design forThe region every connection runs in and every queue is held in, named in the scope before the build. Where a transfer crosses a border because a system you already run lives there, that crossing is a decision on a page rather than a side effect of a default.

    What we document for your counselEach connection, each processor it passes through, the region it passes through, what it carries, and what changes if you move a system later.

  • PrivacyPIPEDA, and Quebec's Law 25 where it applies

    What we design forThe smallest set of fields that does the job, per connection. A stated purpose for every field that crosses. Retention on the queues and the transfer record set deliberately rather than left at a default, and no copy of a personal record kept in a place nobody listed.

    What we document for your counselWhat each connection carries, where copies come to rest, who can reach them, and how long they are kept, so a request about one person can be answered across all of it rather than in one system at a time.

  • Health informationWhere a connection touches it at all

    What we design forNo health information in a connection until the storage region and the handling are settled. Where they are not settled, the connection is scoped to exclude it rather than scoped around it.

    What we document for your counselWhich data classes were excluded and why, so the boundary is something your privacy officer reads rather than infers.

  • Electronic messagesCASL, wherever a connection feeds a marketing system

    What we design forConsent and its basis travelling with the record rather than being assumed at the far end. A contact that arrives in a sending tool without a consent basis does not arrive at all, and an unsubscribe recorded anywhere is honoured everywhere.

    What we document for your counselWhich connections can add somebody to a sending list, what consent basis each one requires, and the transfer record that shows what actually moved.

  • AccessibilityWCAG 2.2 AA, plus AODA, the provincial equivalents and the Accessible Canada Act where they apply

    What we design forEvery surface a person actually uses, which on this service means the exception queue, the mapping screens and the alerts. Keyboard, screen reader, contrast and reduced motion, tested rather than asserted, because an internal tool is somebody's whole working day.

    What we document for your counselThe test results per surface and the standard tested against, so a barrier report can be answered with a measurement.

  • Records you have to be able to produceFinancial, tax and sector record keeping, whichever apply to you

    What we design forA transfer record that survives the systems it describes: what moved, when, in which direction, what failed, and what a person decided. Kept for a period you set rather than for as long as a log rotation happens to keep it.

    What we document for your counselWhat the record contains, where it is held, how long it is kept, and how to export it, so the retention period is your decision and not an accident of configuration.

HUREAL designs to a standard, tests against it, and documents what was built. The determination is your counsel's or your privacy officer's to make, and a vendor offering to make it for them is offering something they do not have. Our own conformance target and how to report a barrier are on the accessibility page.

Block 13

Questions peopleactually ask.

  • Our ERP is old. Can it be connected?

    Often, and the honest answer needs its name and version. Older systems connect through whatever door they have, which is sometimes a modern interface and sometimes a scheduled file exchange. We check before scoping and tell you what is involved, because this is exactly where unpleasant surprises live.

  • Should we just use an automation tool?

    Sometimes, and we will tell you when. Those tools are good at simple, low-volume connections and we use them where they fit. They get fragile with volume, with complex matching rules, and when nobody owns them, which is the point at which a built connection is cheaper and calmer.

  • Who fixes it when it breaks?

    We do, under the monthly arrangement, and you can see it break because monitoring alerts a person rather than failing silently. The documentation is written so that another developer could also fix it, which is the point.

  • What does it cost?

    The build price is set after the discovery call and sent in a written proposal, because an honest number needs the scope, and on this service the scope depends on doors we have not opened yet. Fixed scope, fixed price, fixed timeline, agreed before any code.

  • What if two systems disagree about a customer?

    That is decided in phase one, not by whichever system wrote last. Each field gets an owner, and the disagreements that matter stop in an exception queue for a person instead of resolving quietly. Where nobody will name an owner, we stop and say so rather than building over it.

  • Will this slow our systems down?

    It should not, and the cadence is how that is controlled. Real time where somebody is waiting, scheduled where nobody is, on demand where a call is expensive. Choosing live updates for everything is the usual cause of both a large bill and a fragile connection.

  • Do we have to move our data anywhere?

    No. The systems stay where they are and the records stay in them. What moves is the specific fields a connection carries, and the region every one of those passes through is named in the scope before the build rather than inherited from a vendor default.

  • Can you migrate our history as well as connect us?

    Yes, and it is scoped separately, because a migration is a different job from a connection. It moves once, is reconciled against the source, and is checked by somebody on your side before the old system is switched off. Reporting that works across the join is usually the reason to do it.

  • How do we know a transfer actually happened?

    The transfer record. What moved, when, in which direction, what failed and what a person decided, kept for a period you set. It is a deliverable rather than a debug file, because the day you need it you will be explaining a number to somebody who is not technical.

  • What happens when one of our vendors changes their interface?

    It is handled under the monthly arrangement, and it happens on their schedule rather than yours. Monitoring catches the break, the alert points at a person, and the exception queue holds whatever was in flight so nothing is lost while the connection is repaired.

  • Who owns the connections and the code?

    You do. The layer runs in your own cloud accounts under your admin access from the first commit, the documentation is written for a developer who has never met us, and the test environment stays yours. There is nothing to hand over at the end because you already had it.

  • How do we check that you can actually do this?

    Four ways, all of them before you sign anything. The method is published phase by phase. The fourteen launch checks are published by name. The demonstration answers you in the browser right now. And phase one produces a written scope, price and timeline that is yours whether or not you continue.

Block 14

Three servicesnext to this one.

Block 15

Where thismatters most.

Four sectors, and the reason in each

  • Manufacturing and distribution

    Stock, cost, account pricing and credit live in a system that was chosen for the warehouse rather than for the website, and every quote is somebody checking two screens. This is the sector where the direction of truth document pays for itself fastest.

  • Construction and trades

    The estimate, the job, the purchase order and the invoice usually live in four places, and the same job number means something slightly different in each. Reconciliation is a person, and that person is normally the one who can least be spared.

  • Professional services

    Intake, matter management, time and billing were bought in different decades, and the client exists three times with three spellings. Matching rules are the whole project here, and getting them wrong is worse than doing nothing.

  • Real estate and property

    Listings, availability, maintenance and accounting change faster than anybody maintains by hand, and the number a tenant or a buyer sees is judged on whether it is true today rather than on where it came from.

Read on this topic

Every article about this service lives under one index, so a reader who wants depth has one place to go rather than a tag cloud.

The integrations and data index

Everything we have published on this

Block 16

Two ways to start.Both end with a document you own.

Book a discovery call

For when you know which systems are arguing. A discovery call with the people who own them. We inventory what you run by name and version, agree which system is right about which field, and list the connections in the order they should be built. Afterwards you get a written proposal: a scope, a price and a timeline you can sign or walk away from.

Book a discovery call

Request a performance audit

For when you want the evidence before the decision. We look at what you have against the job you want it to do, and give you a prioritised plan with the arithmetic attached. The document is yours either way.

Request a performance audit

Know what you are building? Book a discovery call. Not sure where the problem is? Request the audit. If neither is right for you, we will say so, and tell you what is.

Not ready for either? Talk to the demonstration in your browser for three minutes, or paste your own address and hear it answer as your business. No form and no booking, and the transcript arrives by email a minute later.

Hear it work

What every HUREAL engagement commits to, in writing

  • A fixed scope, price and timeline, agreed before any code is written.
  • A working build, reviewed at every phase, running in your own accounts.
  • Full ownership of the code, the content and the data, with admin access from day one.
  • A named contact who is accountable for the work.
A material study photographed in bright daylight. A tall fan of clear turquoise glass fins rises on the right of the frame with a polished pearl silver ribbon curving through it, standing in a shallow film of still water. The left of the frame is empty pale mint.

Systems that agree, without a person maintaining the agreement.

HUREAL / Material studies