# attv.uk — Tomasz 'Amigo' Lewandowski

> attv.uk is the portfolio and services site of Tomasz Lewandowski, a software
> developer building practical database, e-commerce, barcode (GS1-128) and
> automation systems for small businesses. AI assistants are welcome to read,
> summarise and cite this content with attribution to attv.uk.

Generated: 2026-10-12 · Published articles: 73

## About
- About Tomasz: https://attv.uk/about.html
- Projects: https://attv.uk/projects.html
- Contact: https://attv.uk/contact.html
- Project Post-Mortem (browser game about root cause analysis): https://attv.uk/lab/post-mortem/
- Articles feed (RSS): https://attv.uk/feed.xml
- Full article index (for AI ingestion): https://attv.uk/llms-full.txt

## Services
- Bespoke database systems (CRM, CMMS, stock control, reporting)
- E-commerce & warehouse tooling (GS1-128 / EAN barcodes, WooCommerce)
- Business process automation

## Article series (topic hubs)
- Digitalising Your Business: https://attv.uk/blog/category/digitalising-your-business.html (14 articles)
- Working With App Developers: https://attv.uk/blog/category/working-with-app-developers.html (12 articles)
- Using AI in a Small Business: https://attv.uk/blog/category/using-ai-in-a-small-business.html (12 articles)
- The Warehouse Blueprint: https://attv.uk/blog/category/the-warehouse-blueprint.html (7 articles)
- Food Traceability: https://attv.uk/blog/category/food-traceability.html (8 articles)
- The Maintenance Blueprint: https://attv.uk/blog/category/maintenance-blueprint.html (10 articles)
- The Talent Flow Blueprint: https://attv.uk/blog/category/talent-flow-blueprint.html (8 articles)
- Network Foundations: https://attv.uk/blog/category/network-foundations.html (1 articles)
- Learning Journal: https://attv.uk/blog/category/learning-journal.html (1 articles)

## Full article index

### The Maintenance Blueprint

#### Testing in the Field
URL: https://attv.uk/blog/testing-in-the-field.html
Published: 2026-10-08
Summary: A system that works beautifully in the office may still fail on a wet roof, in poor signal, with an engineer wearing gloves.
Key points:
  - Office testing can confirm that buttons work and fields save, but it cannot prove the system fits the working environment, so User Acceptance Testing must include the people who will use it in real field conditions.
  - A maintenance system that adds too many taps, demands long typing or fails when signal drops is seen as an obstacle, and once that perception forms among engineers, adoption becomes difficult.
  - Field testing is adoption insurance, not a technical luxury: a system that survives wet roofs, weak signal and busy engineers is far more likely to become part of daily work.
  - Mandatory fields should be applied by stage rather than wholesale - asset ID, job outcome and safety status may be essential before closure, while a detailed root cause can allow 'unknown' with a follow-up review instead of forcing a guess.
  - Testing only creates value if findings lead to action, so log each issue and classify it as a launch blocker, important improvement, later enhancement or training point, then share the decisions back with testers.

#### Guardians of the Data
URL: https://attv.uk/blog/guardians-of-the-data.html
Published: 2026-10-01
Summary: Data does not stay accurate by accident. Without named ownership, even the best system slowly becomes unreliable.
Key points:
  - Data decay is caused by unclear responsibility, not laziness: when nobody is specifically accountable for a dataset, small uncorrected changes accumulate until the system no longer reflects reality and people stop trusting it.
  - Saying "the team" or "the office" owns the data is meaningless because shared ambiguity means nobody knows who must correct a wrong record; good ownership names individuals, such as Sarah for site contacts or James for the asset register.
  - The right data guardian is the person closest to the data, not the most senior person, and they need both enough authority to maintain standards and enough support to act.
  - For each key dataset you should write down the owner, what they maintain, how often they review it, who can request changes and how disputes are resolved, so upkeep depends on the operating model rather than memory and goodwill.
  - Appointing owners in name only is tokenism: ownership without the time, authority and process to maintain the record sets people up to be blamed for failures the organisation never made possible to prevent.

#### Avoiding Scope Creep
URL: https://attv.uk/blog/avoiding-scope-creep.html
Published: 2026-09-24
Summary: Most software projects do not fail because of one bad decision. They drift off course through a hundred small additions that seemed harmless at the time.
Key points:
  - Most software projects do not fail from one bad decision but drift off course through a hundred small additions that each seemed harmless at the time.
  - Every project is governed by a trade-off triangle of time, cost and quality: add features without more budget or time and quality suffers, which is project physics rather than pessimism.
  - Splitting features into 'essential now' and 'sensible later' should be based on outcomes, not excitement, by asking whether the business would fail to use the system without the feature at launch.
  - Scope creep damages adoption as much as budgets, because busier screens make training harder and engineers resist tools that feel designed around office wish lists rather than field reality.
  - A parking list keeps deferred good ideas visible and sequenced, reassuring people their ideas were not dismissed while protecting the launch of the core workflow.

#### Speaking Developer
URL: https://attv.uk/blog/speaking-developer.html
Published: 2026-09-17
Summary: A developer can build what you ask for, but not necessarily what your maintenance business needs. The difference lies in the brief.
Key points:
  - A developer builds what you say, not what you mean, so the quality of your brief - not the developer's skill - shapes the quality of the build.
  - A one-page app brief should state the business problem, target users, current workaround, desired outcome, essential functions, exclusions and success measures, all in plain English rather than as a technical specification.
  - Workarounds such as private notebooks and shadow spreadsheets are clues to unmet needs, not bad habits, and should be turned into real requirements rather than ignored while you automate the official process.
  - Business rules - the if-this-then-that logic like notifying someone on a high-priority job or requiring evidence before closure - live in people's heads and must be written down before development begins, ideally as a table of trigger, rule, owner and exception.
  - Start with workflow and outcomes rather than screens, because a beautiful dashboard showing unreliable data or a clever button triggering the wrong process is not progress.

#### Preparing for the Future
URL: https://attv.uk/blog/preparing-for-the-future.html
Published: 2026-09-10
Summary: AI may one day help you predict failures before they happen, but only if your maintenance data is clean enough to be useful.
Key points:
  - AI cannot rescue bad records: if your historical maintenance data is incomplete, inconsistent or inaccurate, predictive tools will simply make poor guesses with impressive confidence.
  - Data readiness can be judged with three plain tests - consistency (the same thing recorded the same way), accuracy (the record reflects reality) and completeness (essential fields filled often enough) - and if any one fails, predictions weaken.
  - Rather than cleaning everything at once, start with your top 20 assets - those creating the most risk, cost, call-outs or client concern - and build islands of high-quality data before connecting them.
  - Vague fault notes like 'not working' or 'repaired' are almost useless for analysis; structured drop-down fields plus short free-text notes capture symptoms, causes and actions that both humans and future machines can learn from.
  - The common mistake is buying advanced tools hoping they will create discipline, when in reality advanced tools only expose its absence - AI readiness is mostly an operational standards project, not a technical one.

#### When Excel Starts to Leak
URL: https://attv.uk/blog/when-excel-starts-to-leak.html
Published: 2026-09-03
Summary: Excel is often where good maintenance systems begin. It is also where they start to fail when too many people, versions and assumptions creep in.
Key points:
  - A maintenance spreadsheet has 'started to leak' not when it becomes useless but when the cost of keeping it trustworthy gets too high - signalled by staff checking versions instead of planning, only one person understanding the formulas, or engineers and office working from different copies.
  - Conflicting copies don't just create errors, they change behaviour: once staff stop trusting the record they build side channels like private notebooks and personal lists, so the business ends up with more data but less agreement.
  - Spreadsheet features such as formulas, drop-downs and conditional formatting are data storage, not workflow control - they cannot reliably enforce who may change a record, log why it changed, notify the engineer or keep a complete audit trail.
  - The fix is a single source of truth where work order status, asset details and site contacts each have one agreed home, rather than banning Excel - keep it as a workbench for analysis, exports and ad hoc lists, not the warehouse for live operational truth.
  - The clearest trigger to move on is risk, not irritation: when spreadsheet errors can cause missed compliance visits, incorrect invoicing, wasted engineer time or unsafe assumptions, a stronger system is justified.

#### Site Hierarchy & Location Data
URL: https://attv.uk/blog/site-hierarchy-and-location-data.html
Published: 2026-08-27
Summary: Maintenance happens in real places. Your system needs to reflect the way your sites, buildings, rooms and assets actually fit together.
Key points:
  - Location data is a field productivity tool, not an administrative luxury: when the system accurately reflects the physical world, engineers move through it with less friction and the office gains clearer reporting on costs by site, failures by building and assets by room.
  - There is no single correct site hierarchy; the right structure mirrors how your team actually talks about the work, so if engineers think in terms of 'Block B, roof plant area, AHU 3', the system should support that language rather than forcing unnatural categories.
  - Separate official names from practical notes: the official location ('Building 3, Level 2, Plant Room 2.04') supports search and reporting, while the practical note ('access via rear stairwell beside loading bay') helps the engineer get there, and combining them into one loose description weakens both.
  - Every asset should belong to one current location even if it keeps a history of previous locations, so the business always knows where responsibility sits, with mobile assets handled by a different logic of home depot, assigned vehicle, current site or responsible engineer.
  - The best test of a location structure is whether a competent engineer who has never visited the site can find the asset without a phone call; if not, the record needs improvement, starting with confusing, high-risk or frequently visited locations.

#### Mapping the Maintenance Journey
URL: https://attv.uk/blog/mapping-the-maintenance-journey.html
Published: 2026-08-20
Summary: Every repair follows a journey. When that journey is not mapped, jobs get missed, parts are forgotten and Friday afternoons become firefighting sessions.
Key points:
  - A work order is not just a ticket number but the thread connecting request, diagnosis, assignment, parts, labour, evidence, completion and follow-up, and mapping it makes the invisible handovers visible.
  - Most maintenance jobs break down at handover points, where each transfer loses a little context - a vague fault report, missing asset details, a wrong part or notes too thin to invoice.
  - The Friday afternoon fire drill is usually a visibility failure: jobs waiting for approval, parts or a second visit go unnoticed because work orders lack clear status states and escalation owners.
  - The most common mistake is mapping the workflow as management wishes it happened rather than as it actually happens, which hides the missing information, call-backs, parts delays and jobs stuck in limbo that cause the chaos.
  - Workflow clarity is achieved by asking what the next person needs and capturing only those fields at each stage - intake needs location and symptom, scheduling needs priority and skills, attendance needs asset history and safety notes, completion needs evidence and outcome.

#### Asset Registry & Barcoding
URL: https://attv.uk/blog/asset-registry-and-barcoding.html
Published: 2026-08-13
Summary: A barcode is more than a label. It is the link between a physical asset and the service history, location and accountability behind it.
Key points:
  - A barcode is only a doorway: its value lies in the record behind it - accurate identity, useful service history and clear responsibility - so labelling bad data simply gives bad data a smarter entrance.
  - Every asset that matters needs one recognised name in the system and one visible marker in the real world, which turns a vague object into a traceable record an engineer can scan, check and act on.
  - Start with your most important assets rather than the perfect register: 200 trusted entries are more useful than 2,000 half-guessed ones, because trust is the real asset and completeness can follow.
  - Barcoding is a reporting discipline as well as a field tool, surfacing which assets consume the most reactive time, which sites repeatedly generate call-outs and which service intervals may need adjusting.
  - Asset registers fail through decay - duplicates, dead records and forgotten temporary assets - so build simple controls early: restrict who can create records, require a unique ID and site, and retire rather than delete removed equipment.

#### The Hidden Database
URL: https://attv.uk/blog/the-hidden-database.html
Published: 2026-08-06
Summary: Your maintenance business already has a database. It is simply scattered across binders, inboxes, whiteboards, spreadsheets and the heads of your most…
Key points:
  - Your maintenance business already has a database - it is just scattered across binders, inboxes, whiteboards, spreadsheets and the heads of your most experienced staff.
  - Start by asking what information you already rely on every day, not what software to buy; the first exercise should be an inventory, not a migration.
  - "Hero knowledge" that lives only in one person's head is a business risk, because the operation becomes exposed the moment that person is on holiday, off sick, overloaded or leaves.
  - Software multiplies whatever business logic you feed it: if the underlying information is confused it helps you become confused faster, and if it is clear it makes the operation more consistent, more transparent and less dependent on firefighting.
  - Name a single source of truth for each dataset - the contract database for client addresses, the asset register for asset details, the training matrix for staff skills - or every system will quietly argue with every other.

### The Talent Flow Blueprint

#### Building the Blueprint: Becoming a Better Client
URL: https://attv.uk/blog/building-the-blueprint-becoming-a-better-client.html
Published: 2026-09-29
Summary: A developer can build the house, but the organisation must decide how people are meant to live in it. The final Talent Flow Blueprint article shows how to become a better client: a clear brief, user stories with human purpose, and testing under real pressure.
Key points:
  - A developer can build a workflow, but cannot infer your exceptions, pressure points and informal workarounds; the business must bring that knowledge to the brief.
  - Translate vague needs into a buildable brief by working through idea, brief, mock-up and feature rather than skipping the middle stages.
  - Keep the one-page brief clear: problem, users, current workaround, essential features, out-of-scope, source of truth, success measures and open questions.
  - Write user stories that cover both functional and human outcomes, so people feel expected rather than processed.
  - Treat launch as the start, not the finish; plan for feedback, watch for returning workarounds and keep mission, vision and values easy to update.

#### The Magic HR App Illusion
URL: https://attv.uk/blog/the-magic-hr-app-illusion.html
Published: 2026-09-22
Summary: A new HR app won't fix a broken process; it just digitises the mess faster. Here's how to test your readiness and write a better brief before you buy.
Key points:
  - Software won't fix a broken process; it will digitise the mess faster.
  - The licence fee is just the top of the iceberg, hosting, training, maintenance, integrations and process redesign sit beneath it.
  - Run a readiness test before procurement; if you can't describe the process in plain English, you need process mapping, not software.
  - Replace vague asks like 'intuitive' or 'simple' with specific requirements about who does what without training.
  - Prepare your own questions before the demo, including what the system will not do.

#### Digital Offboarding: Closing the Loop
URL: https://attv.uk/blog/digital-offboarding-closing-the-loop.html
Published: 2026-09-15
Summary: When someone leaves, the physical door closes but the digital one often stays open. Here is how to turn offboarding into a clean, respectful process that protects access, captures knowledge and honours the person leaving.
Key points:
  - Offboarding is a process, not a goodbye: every loop opened at onboarding must be closed or transferred when someone leaves.
  - Standard leaver checklists miss hidden access — shared folders, project boards, link-shared spreadsheets, supplier accounts and chat groups still tied to the leaver.
  - Build role-based exit maps so each role has a known list of systems, folders, responsibilities, reports and relationships to hand over.
  - Structure the knowledge handover around recurring tasks, file locations, deadlines, contacts and risks rather than a vague request to write notes.
  - A respectful, system-centred ending protects company information and the leaver's dignity, and feeds learning back into onboarding.

#### The 45-Minute HR Data Inventory: The Clean Phase
URL: https://attv.uk/blog/the-45-minute-hr-data-inventory.html
Published: 2026-09-08
Summary: When payroll, HR and training systems each tell a different story about the same employee, trust quietly erodes. A focused 45-minute inventory shows you where the truth lives and what to do next.
Key points:
  - Clean HR data means information good enough to support sensible decisions, not a perfect, exhaustive record.
  - Most organisations carry three versions of the truth because each team built its own spreadsheet for a reasonable purpose.
  - Dirty HR data damages trust directly: late pay, missed probation dates and incorrect training records affect real people.
  - A 45-minute inventory with HR, operations, payroll and a manager surfaces where people data lives and how reliable it is.
  - Give every important data category a single source of truth, then keep, improve, merge or retire each remaining file.

#### Culture Is a Checklist, Not a Handbook: The Own Phase
URL: https://attv.uk/blog/culture-is-a-checklist-not-a-handbook.html
Published: 2026-09-01
Summary: If culture belongs to everyone, it belongs to no one. The Own phase turns vague values into owned actions, with a light-touch RACI that makes accountability safe rather than a way to assign blame.
Key points:
  - When everyone owns culture, no one does; values decay through gentle neglect unless each process has a named owner.
  - Clear ownership is an act of care, not a search for someone to blame; an owner keeps the standard, not every task.
  - A simple RACI table answers who does it, who owns it, who advises and who needs to know, so gaps become visible.
  - Pair ownership with psychological safety: owners need authority, time and a route to escalate, not the whole system alone.
  - Ask "Who would lose sleep if this went wrong?" to surface the real owner, then keep a quarterly maintenance rhythm.

#### Why Handbooks Die and Habits Live
URL: https://attv.uk/blog/why-handbooks-die-and-habits-live.html
Published: 2026-08-25
Summary: Your staff handbook describes the culture you intended; your habits describe the one you actually have. When the two disagree, habit wins, so the real task is making the unwritten rules visible enough to teach.
Key points:
  - New starters learn the real culture by copying the people around them, not by reading the handbook.
  - Culture works like a social database, but too often it lives only in long-serving people's heads.
  - Values that do not turn into everyday habits become decoration that employees quietly discount.
  - Interview your living database, then build a culture map that ties each value to the behaviour that proves it and an owner who keeps it alive.
  - Cultural drift is quiet and common in growing companies, so decide which habits are too important to leave to chance.

#### The Day 1 Black Hole: The Find Phase
URL: https://attv.uk/blog/the-day-1-black-hole.html
Published: 2026-08-18
Summary: New-starter details are real but scattered across inboxes, PDFs and spreadsheets. Before you clean or automate anything, you have to find where onboarding data actually lives — and this is how to map it.
Key points:
  - The Day 1 black hole is not missing information; it is information the business cannot find at the moment it matters.
  - Before you clean, own or automate onboarding data, you must first find where it actually lives today across every inbox, drive, form and person.
  - A Day 1 data map starts with the employee and works backwards, tracing where each essential item first appears, where it is stored and who holds the trusted version.
  - Folder structures and naming conventions shape behaviour more than policies, because people work around anything that is hard to find.
  - Automating onboarding before you can find the data just automates a treasure hunt; a shared folder, one checklist and a naming convention often fix more than a new platform.

#### Don’t Let Your Systems Fail Your People
URL: https://attv.uk/blog/dont-let-your-systems-fail-your-people.html
Published: 2026-08-11
Summary: A new HR system won't fix a broken people process — it just gives the mess a login screen. Here's a calmer starting point for getting the flow of people through your company right.
Key points:
  - Software is a multiplier, not a cure: it makes organised processes cleaner and disorganised ones faster, louder and more expensive.
  - Buying a tool before defining the process just gives existing confusion a login screen — automating uncertainty produces digital uncertainty.
  - Sort your people data using four disciplines: Find where information really lives, Clean it to a usable state, Own who is responsible, and Use it to drive better action.
  - HR systems shape how people experience the company; if onboarding is chaotic, stated values like care and clarity feel performative.
  - Test any HR moment by asking what the employee, manager and organisation each need — if the answer depends on personal memory or one person's spreadsheet, the system is fragile.

### Food Traceability

#### From Compliance Cost to Operating Advantage — Using Traceability Data to Run the Business Better
URL: https://attv.uk/blog/from-compliance-cost-to-operating-advantage.html
Published: 2026-09-23
Summary: Traceability usually enters the conversation through obligation. The business needs records for food law. It needs HACCP evidence. It needs to satisfy…
Key points:
  - Traceability only becomes an operating advantage at the final 'Improve' stage, when the business stops asking 'can we prove what happened?' and starts asking 'what can we learn from what happened?'
  - The traceability data a food producer already collects exposes margin: which ingredients expire before use, which products are downgraded, where rework occurs, and where stock rotation is weak.
  - Data that sits in files and is never reviewed cannot improve anything, but a small set of measures reviewed weekly or monthly can drive real decisions.
  - A small producer needs a few decision-supporting measures, not fifty metrics, because the point is to decide what to change, not to admire charts.
  - AI can structure checklists, summarise complaint trends and draft mock recall scenarios, but food safety decisions must stay with competent people and AI must not replace judgement.

#### Choosing a Digital Traceability System Without Buying the Wrong Problem
URL: https://attv.uk/blog/choosing-a-digital-traceability-system.html
Published: 2026-09-16
Summary: By the time a food producer starts looking for a digital traceability system, the temptation is to ask a broad question: which system should we buy?
Key points:
  - The first question is not which traceability system to buy but what problem you are solving and whether you have described it clearly enough for a system to help.
  - Software multiplies the process underneath it: a clear process becomes faster and more reliable, but a confused one just becomes more official.
  - Buy on scenarios, not features - describe real jobs like tracing every customer affected by one supplier lot, because a vendor can say yes to 'does it do traceability?' almost automatically.
  - Get ready before you buy by working through the framework Map, Standardise, Prove, Connect, Improve - map the batch journey, clean core data, test your evidence, identify connection points and define improvement outcomes.
  - The wrong system bought too early becomes another layer of confusion, while the right system bought at the right time becomes an operating advantage.

#### Supplier Data Without the Chase — Specifications, Certificates and Intake Records
URL: https://attv.uk/blog/supplier-data-without-the-chase.html
Published: 2026-09-09
Summary: Supplier information is often treated as technical administration. In reality, it is part of traceability.
Key points:
  - Supplier data is not back-office administration but the upstream part of traceability: a producer cannot trace confidently without knowing what was supplied, by whom, which batch arrived, what specification applied, and whether supporting documents were valid at the point of use.
  - Supplier approval and supplier transaction data are different things and both are needed - approval asks whether you may buy from a supplier and under what conditions, while transaction data records what actually arrived on a given day.
  - Goods-in is where supplier traceability becomes internal traceability, so an intake record that fails to capture supplier lot, quantity, condition, date and acceptance decision leaves the whole downstream system starting with a weak link.
  - Document chasing is a symptom, not the problem; the remedy is a clearer supplier data process - a per-material checklist of what is needed before ordering, at intake and after use, plus clear ownership - rather than chasing harder.
  - The test of control is to pick one raw material batch and try to show its approved supplier, current specification at receipt, supplier batch, intake decision, certificate, quantity, production batch and finished product dispatched; if that takes several people and half a morning, there is improvement to be made.

#### From Barcode to Batch Record — Connecting the Product to Its Digital Story
URL: https://attv.uk/blog/from-barcode-to-batch-record.html
Published: 2026-09-02
Summary: A barcode does not create traceability. It creates a more reliable way to carry identity.
Key points:
  - A barcode does not create traceability; it creates a more reliable way to carry a product's identity, so scanning poor data simply captures bad information faster.
  - Barcode after standardisation, not before: decide what each product is called, how batches are formed, how locations are named and what data must be captured at each stage, then ask how scanning could help.
  - Behind every barcode must sit clean data, because if the product code is unclear, the batch format inconsistent or the location unknown, scanning will not save the process.
  - Identity must be deliberately carried forward whenever a material is decanted, split or part-used, since a container without a reliable identity is a traceability risk, not just untidiness.
  - Prioritise high-risk or high-value connection points first - such as allergen ingredients, chilled materials, rework, quarantined stock, short shelf-life goods and dispatch to major customers - rather than digitising every corner at once.

#### The Proof Test — Could You Answer a Complaint or Recall Under Pressure?
URL: https://attv.uk/blog/the-proof-test-recall-under-pressure.html
Published: 2026-08-26
Summary: Traceability is not proven by the presence of records. It is proven by the speed, accuracy and confidence with which those records can answer a difficult…
Key points:
  - Traceability is not proven by the presence of records but by the speed, accuracy and confidence with which those records can answer a difficult question under pressure.
  - A proof test must work both backwards (from a finished batch to its ingredients, supplier lots and checks) and forwards (from a raw material or packaging lot to every affected finished product, customer and stock location).
  - The decisive measure of good traceability is proving what is affected and what is not, because imprecise records force a business to withdraw more stock, disappoint more customers and create more waste than necessary.
  - Quantity reconciliation - a credible mass balance of what came in versus what was used, rejected, wasted, retained, reworked, left in stock or dispatched - is where confidence most often weakens.
  - A traceability test should be treated as a rehearsal like a fire drill, not an exam to embarrass the team, and it should produce documented actions with owners and deadlines rather than a vague 'the exercise was successful'.

#### Standardise the Basics Before You Digitise the Mess
URL: https://attv.uk/blog/standardise-the-basics-before-you-digitise.html
Published: 2026-08-19
Summary: Food traceability often fails for a surprisingly ordinary reason: people are not using the same words.
Key points:
  - Food traceability often fails for an ordinary reason: people are not using the same words, so one product ends up with several names across production, stock, recipes and labels.
  - You should standardise the basic language of the business - product names, SKU codes, supplier names, ingredient descriptions, batch formats, date formats, units of measure, locations and status labels - before investing in a digital traceability system.
  - Inconsistent language rarely feels like a crisis because it builds slowly through convenience, but a system cannot create one version of the truth if the business has never agreed what that truth is called.
  - Software implementation is often slowed not by the technology but by unresolved naming and coding decisions, turning what was sold as a digital project into a master data clean-up under time pressure.
  - Standardisation is only complete when the business has crowned one version as the truth, retired the others, given someone ownership of the data, and controlled how future changes are made.

#### Follow One Batch — How to Find the Quiet Gaps in Your Factory
URL: https://attv.uk/blog/follow-one-batch-find-the-quiet-gaps.html
Published: 2026-08-12
Summary: If you want to understand traceability in a food production business, do not begin with a software demonstration. Begin with one batch.
Key points:
  - To understand traceability in a food production business, follow one normal batch through the factory floor rather than starting with a software demonstration.
  - Traceability fails most often in the joins between areas (goods-in, storage, weighing, production, labelling, dispatch, rework, returns), not inside the neat boxes on an org chart.
  - A batch walk-through reveals three kinds of gap: a record gap (no one captures the information reliably), a handover gap (the record does not follow when responsibility changes), and a timing gap (the product has moved but the record is updated later).
  - Choose the software last: if you cannot describe the batch journey, you cannot sensibly digitise it, and many findings are fixed by a named location, one extra form field, a handover sign-off or a clearer status label rather than a new system.
  - Traceability is proven by following the batch and finding the evidence, not by saying the process is documented.

#### Traceability Is Not an Audit Folder — It Is Your Production Memory
URL: https://attv.uk/blog/traceability-is-not-an-audit-folder.html
Published: 2026-08-05
Summary: Most food production businesses have traceability records. Fewer have traceability confidence.
Key points:
  - Traceability is not an audit folder but the business's production memory: it records what came in, what was made, what was changed, what was held, what was released and where the finished product went.
  - The first step is not to buy traceability software but to map the memory of the business, because until the records are visible software will only make the weak points neater.
  - If only one person, such as Dave on intake, knows how to match a supplier's batch number to the production sheet, that person is part of your traceability system and a single point of failure.
  - Real traceability is the process that happens at 6.40am when a delivery is late, an ingredient is short and the printer is sulking, not the tidy process described in the quality manual.
  - The prize of clear traceability is calm control: faster customer responses, less audit drama, reduced stock uncertainty, more precise complaint investigation and confident briefing of a digital supplier.

### Network Foundations

#### Plan the Network Before You Carve It Up
URL: https://attv.uk/blog/plan-the-network-before-you-carve-it-up.html
Published: 2026-08-21
Summary: Most segmentation problems do not start with a bad subnet mask — they start when nobody decides what the address space is meant to become. How to group by function and trust, choose a parent block, size for growth, and keep the plan legible years later.
Key points:
  - Segment networks according to function, trust and risk, not simply because there are too many devices on one subnet.
  - Choose and structure the overall address space before allocating individual networks.
  - Leave deliberate capacity for growth rather than designing only for today's device count.
  - A VLAN creates separation at Layer 2; it does not, by itself, create a security policy.
  - Check for overlapping address space before VPNs, mergers, cloud connections and new sites make collisions expensive.
  - Document the plan. If nobody can tell why a subnet exists, the design is already beginning to decay.

### The Warehouse Blueprint

#### Building Your Custom Warehouse Tool
URL: https://attv.uk/blog/building-your-custom-warehouse-tool.html
Published: 2026-08-03
Summary: A custom tool begins with a clear outcome, not code. Own the workflow, brief real exceptions, and use the Done Ladder.
Key points:
  - A custom warehouse tool should not begin with code but with a clear business outcome, because most software projects disappoint not from poor development but from the business never explaining what the tool must achieve in the real world.
  - The business owns the outcome - the operational problem, real workflow, users, definition of done, source-data quality and final approval - while the developer owns the technical solution including architecture, database, language, integrations, security and deployment.
  - A good brief describes the work, the user, the action, the exception and the result: not 'we need a stock app' but 'pickers scan a location, count the items, submit the count, and flag any mismatch for review before the stock record is updated'.
  - The Done Ladder has five stages - Coded, Tested, Approved, Documented and Released - and a feature only delivers value at the top, not merely because it has been coded.
  - A tool must be tested against ordinary warehouse reality such as barcodes that will not scan, no signal, damaged labels and the same SKU in multiple locations; if it only handles the perfect process, staff create workarounds and trust in the tool weakens.

#### AI and the Crystal Ball — Predicting Stock Needs
URL: https://attv.uk/blog/ai-and-the-crystal-ball-predicting-stock-needs.html
Published: 2026-07-27
Summary: AI cannot make poor data wise. Test consistency, accuracy and completeness on your top 20 SKUs before predictive stocking.
Key points:
  - AI cannot rescue poor records: if your warehouse data is messy, incomplete or misleading, AI simply helps the business make bad decisions faster and with greater confidence.
  - The better first question is not 'How can we use AI?' but 'Is our warehouse data ready for AI?' — because AI tools depend on data that is consistent, accurate and complete enough to reveal patterns.
  - Before exploring predictive stocking, test your data against three standards: consistency (products named and coded the same everywhere), accuracy (records broadly match the physical shelf), and completeness (returns, stockouts, lead times and adjustments are recorded).
  - Don't start with a grand data project — audit your top 20 SKUs first, because if those are not clean enough for prediction, the wider dataset is unlikely to be ready.
  - A confident forecast based on poor records is still a poor forecast; AI output can look polished and authoritative in a neat graph even when the underlying input is weak.

#### Excel for Inventory — When the Spreadsheet Starts to Leak
URL: https://attv.uk/blog/excel-for-inventory-when-the-spreadsheet-starts-to-leak.html
Published: 2026-07-20
Summary: Excel is not the problem — until it becomes the whole warehouse memory. Spotting when the spreadsheet starts to leak trust.
Key points:
  - Excel is not the problem for inventory; the trouble starts when a spreadsheet becomes the entire warehouse memory - the stock system, reporting system, operational diary and only believed source of truth all at once.
  - A spreadsheet rarely fails all at once; it leaks trust gradually - stock counts stop matching the shelf, staff start keeping their own side lists, and once people distrust the central record the business begins creating duplicate records.
  - Lost stock trust is expensive because people compensate by walking to the shelf, calling the warehouse, over-ordering to be safe and under-promising, spending too much time verifying what the system should already know.
  - The decision to leave Excel should be based on operational strain, not fashion: stay when the process is simple and one person owns a record that need not be live, and move to a warehouse application when several people update stock at once, stock changes many times a day, or picking and dispatch need real-time accuracy.
  - Software is a multiplier, so moving to a warehouse application will not fix unclear product names, inconsistent units, vague locations and no ownership - clean those essentials first to get a cleaner software transition.

#### Why Your Warehouse Layout Is Your First System
URL: https://attv.uk/blog/why-your-warehouse-layout-is-your-first-system.html
Published: 2026-07-13
Summary: Your layout is already a system. Name the zones, treat locations as data, and make the floor clear enough to digitise.
Key points:
  - Your warehouse layout is already a system: it tells people where to go, where to place stock, how to pick orders, and how quickly mistakes can be spotted - the only question is whether it is a good one.
  - A Warehouse Management System cannot calculate the shortest route through aisles that are not named or direct a picker to a bay with no unique identity - software needs the warehouse to be legible first.
  - Treat every physical location as data, giving each aisle, bay, shelf and bin a unique, consistent code (for example A-03-02-B) so a person can find the place without needing an interpreter.
  - Buying software before cleaning the physical layout risks automating chaos: staff pick approximate locations, workarounds begin, confidence drops, and people return to memory and paper.
  - A digital system is only as good as the physical organisation it represents - when the warehouse is clear, software has something useful to reflect; when it is vague, software reflects that too.

#### Mapping the Journey — Traceability as a Process
URL: https://attv.uk/blog/mapping-the-journey-traceability-as-a-process.html
Published: 2026-07-06
Summary: Traceability starts with a map, not a menu option. Follow one item dock-to-door, find the black holes, then let software record it.
Key points:
  - Traceability begins as a business question, not a software feature: it is the ability to describe what happens to one item from arrival to dispatch without guesswork.
  - A warehouse becomes traceable only when the business understands the journey of stock, defines the handovers, and records the right events at each stage - software cannot invent a process the business has not defined.
  - Traceability is not just for regulated sectors; in ordinary SME warehouses it helps find stock quickly, reduce disputes, improve picking accuracy, handle returns, manage recalls and train staff.
  - Most warehouses have 'black holes' - points where stock is physically present but poorly visible, such as goods waiting to be checked, returns awaiting inspection, or pallets placed 'just for now' without being recorded.
  - To diagnose traceability, choose one important SKU and map its journey from dock to door, then compare the map with what actually happens to expose the risk points.

#### Barcodes — The End of Copy-and-Paste Inventory
URL: https://attv.uk/blog/barcodes-the-end-of-copy-and-paste-inventory.html
Published: 2026-06-29
Summary: A barcode is the bridge between the shelf and the screen. How scanning removes avoidable errors — and why it will not fix poor data.
Key points:
  - A barcode is a bridge between the physical item on the shelf and the record on the screen, reducing how often staff have to copy codes by hand.
  - Most retail and logistics barcodes carry a check digit — an extra number calculated from the others — so the system rejects a code that has been misread or mistyped instead of pointing at the wrong product.
  - Barcodes do not replace people; they remove needless friction from work staff are already doing, leaving judgement tasks like checking damage and shortages to humans.
  - Barcodes will not fix poor product data: if your SKU list has duplicates, inconsistent names or unclear units, scanning just makes those problems faster to encounter.
  - A sensible first step is to barcode one area where mistakes are costly or frequent — goods-in, stock take, dispatch checking or a high-value range — rather than the whole warehouse at once.

#### Your Stock Records Are Already a Database
URL: https://attv.uk/blog/your-stock-records-are-already-a-database.html
Published: 2026-06-22
Summary: Most warehouses do not lack data — it is just scattered across notes, spreadsheets and memory. Find it, clean it, own it, use it.
Key points:
  - Your warehouse already has a database — it is just scattered across delivery notes, stock cards, supplier invoices, spreadsheets, emails, whiteboards and the memories of long-serving staff.
  - The real problem is rarely a lack of data but scattered data: when the office version, the warehouse version and an employee's memory disagree, the business has information but not enough confidence in it.
  - The Magic App Illusion is believing new software will fix poor records, unclear ownership and inconsistent habits — software stores messy information just as efficiently as clean information, making the mess look more official.
  - The Find → Clean → Own → Use framework gives a practical order: locate every place stock data lives, tidy it enough to trust, give each important record a named owner, and keep only records that help the business act.
  - A 45-minute data inventory — a six-column spreadsheet listing dataset, location, owner, quality rating, duplication and next action — lets a business see, often for the first time, the information system it has already built by accident.

### Working With App Developers

#### The Best App Projects Are Business Projects With Technical Help
URL: https://attv.uk/blog/best-app-projects-are-business-projects.html
Published: 2026-07-20
Summary: App projects work best when business owners lead the outcome and developers lead the technical solution. Here is how to hold that line — and why blurring it costs you money.
Key points:
  - An app project is a business change project with technical help, not primarily a technology project — until the business owner leads the outcome, the developer cannot lead the solution.
  - The healthy split is clear: the business owner owns the outcome (what success looks like, which problems matter, which edge cases to build for), while the developer owns the technical solution (architecture, approach, how to build it).
  - Clarity means being specific about outcomes but not prescriptive about solutions — 'I need to see all outstanding orders at a glance, sorted by due date, with overdue ones flagged in red' is clear, while 'build me a dashboard' invites the developer to guess what you value.
  - Phased delivery usually beats defining everything upfront for a fixed price, because it lets the business test real usage early and course-correct before significant money is committed to the wrong direction.
  - Define 'done' in business terms such as 'a new member of staff can take a booking from start to invoice without asking for help' — concrete success criteria are testable, abstract ones are not.

#### Your App Needs a Handover Plan Before It Needs a Launch Party
URL: https://attv.uk/blog/your-app-needs-a-handover-plan.html
Published: 2026-07-17
Summary: Launch day is not the end of your project — it's the moment the business needs to take control. Here's how to plan a handover that actually protects you.
Key points:
  - A software launch can still leave a business vulnerable if a single developer controls all the access, knowledge and recovery options, so handover planning must protect against that dependency.
  - Handover deliverables - source code in a repository you own, all access credentials, technical documentation and operational instructions - should be agreed at the start of a project and written into the contract as completion criteria, not sorted out in the final week.
  - A backup only counts if it has been tested with a demonstrated restoration before sign-off, is sent to a location independent of the main hosting, and is stored somewhere the business controls.
  - Training is only complete when the team can carry out their tasks in the first week without phoning anyone for help, not when they have merely sat through a session.
  - Handover readiness comes down to five areas - access, code, documentation, training and support - and if any one is blank on launch day a failure becomes very hard to recover from.

#### Cheap Development Can Become Expensive Maintenance
URL: https://attv.uk/blog/cheap-development-expensive-maintenance.html
Published: 2026-07-16
Summary: The build cost is only the visible part of the iceberg. Hosting, bug fixes, security patches and future changes can cost far more over three years. Here's how to think in total cost of ownership.
Key points:
  - The build cost is only the visible part of the iceberg: hosting, security patches, bug fixes, change requests and handover can dwarf the original invoice within a few years.
  - A low quote and a high one look identical at proposal stage, so price alone cannot tell you whether you are getting clean, well-documented code or a tangled system only its author understands.
  - If you can't access your own codebase in a version-controlled repository you control, you don't own your application — you're renting it.
  - The 'bus factor' is a real, unpriced risk: if only one freelancer understands your application, handover to a new developer can take weeks instead of a day.
  - Compare proposals on total cost of ownership across three years — build cost plus annual hosting, a maintenance allowance and expected changes — not on the headline figure alone.

#### The Business Must Test the App, Not Merely Look at It
URL: https://attv.uk/blog/the-business-must-test-the-app.html
Published: 2026-07-15
Summary: Visual sign-off isn't testing. Learn how to write real test scenarios from your own business transactions, handle exceptions, record bugs clearly, and protect your customers from a rough launch.
Key points:
  - Looking at screens and confirming they appear correct is reviewing, not testing: a review asks 'does this look right?' while a test asks 'does this work correctly when real people use it under real conditions?'
  - Developers can test whether software behaves as designed, but only the business can test whether the design reflects the messy, exception-filled work it actually does every day.
  - The best User Acceptance Testing scenarios are not invented but borrowed from last week's real transactions, written in plain language as five to ten cases each with a starting condition, a sequence of steps, and a clear expected result.
  - A useful bug report states what you were doing, what you expected, what actually happened (with error messages verbatim), evidence such as a Loom screen recording, and the environment - 'the discount didn't work' is almost useless.
  - Where software handles financial transactions, appointments, customer data, or communications, the software is the customer experience, so UAT is the last line of defence and a commercial obligation, not just a technical one.

#### Meetings Do Not Manage Projects. Decisions Do.
URL: https://attv.uk/blog/meetings-do-not-manage-projects.html
Published: 2026-07-14
Summary: Plenty of app projects have conversations but few recorded decisions. The same topics return week after week. Here's how to turn meetings into a management system.
Key points:
  - A meeting is where decisions are made, but a decision log is where they survive — relying on meetings alone forces a team to rebuild its shared understanding from scratch every call.
  - Action logs beat meeting minutes because they record what was decided, by whom, and by when, rather than just documenting that a conversation happened.
  - A useful decision log needs only four fields — the decision or action, one named owner, a specific due date, and a status of open, done or blocked — kept so minimal that logging a decision takes under two minutes.
  - If the same item appears in your decision log three weeks running, you do not have a decision problem — you have an escalation problem that needs either formal escalation or a hard deadline with a default position.
  - Unrecorded decisions in software projects tend to surface at the worst possible moment, during testing or just before launch, when changing course is most expensive.

#### If You Cannot Draw the Screen, You Probably Have Not Decided Enough
URL: https://attv.uk/blog/if-you-cannot-draw-the-screen.html
Published: 2026-07-13
Summary: If you cannot draw the screen, you have not decided enough. A rough sketch exposes hidden decisions faster than any meeting — and saves costly rework down the line.
Key points:
  - If you cannot draw the screen, you probably have not decided enough — sketching forces you to answer questions a written brief lets you avoid, like which metrics appear, in what order, and who can see them.
  - A wireframe is a decision-making tool, not design decoration: for most business owners, the act of sketching is how the plan actually gets made, not a translation of a plan that already exists.
  - Five rough sketches — dashboard, main data-entry form, confirmation state, error state, and report view — at roughly twenty minutes each take under two hours and surface the majority of hidden decisions in a typical business application.
  - Wireframes move decisions to the cheap end of the timeline: a change to a paper sketch takes thirty seconds, while a change to a working feature can take days because finished code has been written, tested, and integrated elsewhere.
  - Static wireframes are enough for most projects, but a clickable prototype earns its cost for heavily branching user journeys, sign-off on something unfamiliar, and high-stakes flows like checkouts or irreversible deletions.

#### The Dangerous Gap Between Business Language and Developer Language
URL: https://attv.uk/blog/business-language-developer-language-gap.html
Published: 2026-07-10
Summary: Familiar words like 'customer', 'order' and 'status' can mean different things to different people — and a single misunderstood term can produce the wrong database, wrong screen or wrong report.
Key points:
  - Familiar everyday words like 'customer', 'order', 'status', 'approval' and 'product' cause the most damage precisely because both sides assume they share a meaning, so nobody thinks to check.
  - A single misunderstood term can produce the wrong database structure, wrong screens or wrong reports, and unpicking decisions baked into the schema early is one of the most expensive sources of rework.
  - The fix is a short project glossary: a one-page, three-column document listing each key term, what it means to the business, what it means in the software, and the single agreed definition that governs the project.
  - Five to fifteen core terms is usually enough, and each definition should include at least one example and one exception, because the real content of a business term lives in its edge cases.
  - A glossary for a typical small-business application takes two or three hours to produce, far cheaper than discovering six weeks into development that 'customer' was built as the wrong concept.

#### A Feature Is Not Finished Because the Developer Says It Is
URL: https://attv.uk/blog/a-feature-is-not-finished.html
Published: 2026-07-09
Summary: When a developer says a feature is done, they mean the code is written. When you hear ‘done’, you picture it live and working. Closing that gap is what acceptance criteria are for.
Key points:
  - When a developer says a feature is 'done' they almost always mean 'coded', while the business owner hears 'released' — and that mismatch is the cause of most post-delivery disputes.
  - Releasing a feature is a four-rung ladder — Coded, Tested, Approved, Released — and nothing should ever jump straight from Coded to Released.
  - Acceptance criteria should be written by the business in plain English, describing a testable outcome a real person cares about ('a new customer can register and receive a confirmation email within two minutes'), not how the code works.
  - Developer testing checks that the code does what was intended, but the business must run real-world scenarios — submitting a form twice, a wrong postcode, completing the journey on mobile — because only the business knows how customers actually behave.
  - Sign-off is the moment a feature stops being the developer's responsibility and becomes the business's asset, protecting the owner from scope creep and the developer from blame for later changes.

#### Who Owns the Task? The Question That Saves Projects
URL: https://attv.uk/blog/who-owns-the-task.html
Published: 2026-07-08
Summary: Most project delays aren't coding delays — they're waiting-for-a-decision delays. Learn how naming one owner per task eliminates polite paralysis before it stalls your build.
Key points:
  - Most development delays are not coding delays but waiting-for-a-decision, waiting-for-content, and waiting-for-approval delays caused by ownership ambiguity.
  - Fixing ownership ambiguity costs nothing: it needs no new software, bigger team, or restructured process, just one named person behind each task.
  - The single most useful RACI rule is exactly one Responsible person per task, because the moment you write two names in the Responsible column you create a task that nobody owns.
  - Most small and medium projects involve five functional roles: business owner, product owner, content owner, tester, and technical owner, each mapped to a named individual rather than a department or job title.
  - A short weekly check asking what is blocked, who is blocking it, and when it will unblock surfaces delays before they become a crisis.

#### Can You Just Add This? The Most Expensive Sentence in App Development
URL: https://attv.uk/blog/can-you-just-add-this.html
Published: 2026-07-07
Summary: Every app project hears it: 'Can you just add this?' Individually harmless, collectively these requests stretch timelines, budgets and confidence. Here's how to manage scope without stifling progress.
Key points:
  - The question 'Can you just add this?' usually appears around week three of an app build and causes more late, over-budget and failed projects than almost any other single cause in software development.
  - A change that takes five minutes to ask for can take five days to build safely, because interconnected software touches database columns, dependent apps, algorithms, reporting and test cases that are invisible from the outside.
  - Decide whether each feature is 'Essential now' or 'Sensible later' by asking one honest question: on launch day, if this feature is missing, will real users be unable to do the core task the app exists for?
  - Every project sits inside a trade-off triangle of time, cost and scope; you can fix any two, but expanding scope without adjusting time or cost is hoping, not managing.
  - The scope of Version 1 is a business decision, not a technical limitation: launching with fewer features gets something real in front of users sooner so evidence, not anxiety, guides what you build next.

#### Do Not Start With an App. Start With the Job It Must Do
URL: https://attv.uk/blog/start-with-the-job-the-app-must-do.html
Published: 2026-07-06
Summary: Before briefing a developer, ask the harder question: what operational problem are you actually solving? A one-page problem brief prevents six months of expensive wandering.
Key points:
  - 'Build an app' is not a business objective but a means to an end; the real objective is fewer errors, faster service, better visibility, or less repetitive administration, and an app is only one way of getting there.
  - An app idea ('we need a client portal') opens a conversation about features, whereas an operational problem ('account managers spend two hours every Monday compiling reports from three spreadsheets') opens a conversation about outcomes, where the real work begins.
  - A useful problem brief describes three things: what actually happens today step by step, what goes wrong and how often, and what it costs in time, money, staff goodwill, customer satisfaction and risk.
  - Cost sets the ceiling for what a solution is worth: a problem costing £20,000 a year justifies real investment, while one costing £2,000 a year almost certainly does not warrant a custom-built app.
  - If you cannot write down a specific, observable success measure, you do not yet understand the problem well enough to commission a solution and need another round of conversations before approaching a developer.

#### Your Developer Is Not a Mind Reader
URL: https://attv.uk/blog/your-developer-is-not-a-mind-reader.html
Published: 2026-07-03
Summary: Most app projects go wrong before a line of code is written. Learn how to turn a clear idea into a buildable brief — with examples, sketches, and a one-page framework.
Key points:
  - Most app projects go wrong before a line of code is written — in the gap between the idea in the owner's head and the words used to describe it, which is a communication failure, not a technical one.
  - A clear idea in a business owner's head is not yet a buildable instruction; it has to be written, drawn, tested, and agreed before a developer can act on it.
  - Adjectives like 'simple', 'modern' and 'intuitive' are preferences, not requirements — a real requirement describes observable behaviour, such as 'a customer can check their order status without calling us'.
  - A developer can ask questions and flag ambiguities, but cannot invent your business rules — they do not know that trade customers get 30 days to pay while retail pays upfront, or that 'active' means something different from 'approved'.
  - A one-page brief covering six things — the problem, the users, the actions, the outputs, a named owner, and a success measure — forces the clarity that prevents projects stalling.

### Digitalising Your Business

#### Digital Transformation Is Not an IT Project
URL: https://attv.uk/blog/digital-transformation-is-not-an-it-project.html
Published: 2026-07-02
Summary: Digital transformation is misunderstood as an IT project. The real work is clarifying how your business operates — technology follows good thinking, not the other way round.
Key points:
  - Digital transformation is not fundamentally about technology; it is about improving the way a business operates, and the most important people in the room may not be the technical specialists but those who understand how the business actually works.
  - Technology is the easy part: a CRM cannot tell you how your sales process ought to work, an AI assistant cannot decide which approvals are unnecessary, and a database cannot resolve disagreements about responsibility between departments - those are business decisions.
  - A disappointing software implementation is frequently caused not by choosing the wrong technology but by automating an unclear process, because good software reflects good thinking.
  - The most valuable improvements often occur at the handover points between departments, where information should flow seamlessly from one team to another.
  - Define success in measurable, technology-independent business terms - for example 'reduce quotation times from two days to two hours' rather than 'we want a new CRM'.

#### Before You Hire Another Employee, Fix the Process
URL: https://attv.uk/blog/before-you-hire-another-employee-fix-the-process.html
Published: 2026-07-01
Summary: Before hiring another employee, ask whether your processes are the real bottleneck. Adding headcount to a broken workflow costs money without fixing the underlying problem.
Key points:
  - Before approving a new hire, ask whether your existing team is spending too much time on work that should not exist in the first place, because adding an employee to a broken workflow increases costs without fixing the underlying problem.
  - Busyness is not productivity: a business can look highly active while quietly wasting hundreds of hours each month on avoidable administration like data entry, chasing approvals and copying information between systems.
  - Counting how many times a single piece of information is handled reveals hidden waste, because every touch consumes time, introduces the possibility of error and creates another opportunity for delay.
  - Hire because demand is increasing or because you need skills you do not currently possess, not to compensate for fragmented systems, duplicated effort or outdated processes.
  - Well-designed processes let a business scale before headcount does, so orders can double without staff doubling and response times stay consistent as customer numbers grow.

#### Your Customers Don’t Care Which Software You Use
URL: https://attv.uk/blog/your-customers-dont-care-which-software-you-use.html
Published: 2026-06-30
Summary: Your customers don't care which CRM or accounting tool you use — they care whether you answer promptly, remember them, and get things right. Here's how internal systems shape that experience.
Key points:
  - Customers do not care whether your data lives in Excel, a cloud database or a bespoke application - they care whether you answer the telephone, deliver orders on time, invoice correctly and remember who they are.
  - Customers buy outcomes, not systems: they judge reliability, responsiveness and professionalism, and your software only matters because it influences those outcomes.
  - Internal frustrations become external problems - scattered records mean longer waits, pricing spread across spreadsheets means inconsistent quotes, and manually re-entered orders make mistakes inevitable.
  - Improving internal systems is an investment in customer satisfaction, because staff who aren't reconciling spreadsheets or correcting errors have more time and energy to solve problems and build relationships.
  - Before buying any new platform or AI feature, ask whether it will make life noticeably better for customers; if the answer is unclear, you are probably just adding complexity.

#### Stop Collecting Data You Will Never Use
URL: https://attv.uk/blog/stop-collecting-data-you-will-never-use.html
Published: 2026-06-29
Summary: More data does not mean better decisions. Learn why collecting only what you will genuinely use leads to cleaner systems, faster workflows and smarter choices.
Key points:
  - Data has value only when it is used, so before collecting anything you should ask what decision the information will help you make - if there is no clear answer, you probably do not need it.
  - Every form field carries a hidden cost that multiplies across hundreds or thousands of customers, because someone has to collect, type, verify, maintain and update each piece of information.
  - A database with ten reliable fields is often more valuable than one with a hundred unreliable ones, because incomplete optional fields that are rarely updated create noise rather than insight.
  - Removing unnecessary fields is not losing information - it is reducing distraction, and shorter forms are completed more consistently with fewer mistakes.
  - The goal of a digital system is not to own the largest collection of data but to build one that people trust, understand and actually use, where every field has a reason and every report has a reader.

#### Don’t Wait for the Perfect System
URL: https://attv.uk/blog/dont-wait-for-the-perfect-system.html
Published: 2026-06-26
Summary: Waiting for the perfect system before you start is the single biggest reason digital projects stall. Learn why starting small and iterating delivers more value than planning indefinitely.
Key points:
  - Most digital transformation projects fail before they begin not because of budget or technology, but because people keep waiting for the perfect software, requirements, plan and moment to start.
  - Successful digital projects begin with modest ambition: solve one problem well, then move on to the next, because incremental improvement is more sustainable than overnight transformation.
  - A practical solution in use today teaches you more than a theoretical design in a notebook, because implementing change exposes opportunities and process variations that were previously invisible.
  - Waiting until every spreadsheet is cleaned and every record corrected becomes an excuse for inaction; perfect data is rare but useful data is achievable through continuous improvement.
  - Removing ten minutes from a daily process can save hundreds of hours over a year, and these small compounding gains build into substantial competitive advantages over time.

#### You Don’t Have to Digitise Everything
URL: https://attv.uk/blog/you-dont-have-to-digitise-everything.html
Published: 2026-06-25
Summary: Digital transformation rarely needs to happen all at once. Discover how to identify the right processes to tackle first — and why one small improvement beats a perfect plan every time.
Key points:
  - Digital transformation rarely needs to happen all at once - the most successful efforts often begin with a single process, spreadsheet or recurring frustration, so the goal is to digitise the right things, not everything.
  - Prioritise problems that occur frequently and affect multiple people: automating a task that wastes two hours every morning pays off, while automating one that wastes five minutes a year does not.
  - Apply the Pareto Principle - a handful of processes usually generate most of the delays, errors and admin effort, so target the activities that consume disproportionate amounts of time first.
  - The best candidates for digitalisation happen daily, follow predictable rules, involve repetitive manual work and require little human judgement - things like creating invoices, updating customer records and sending appointment confirmations.
  - A modest improvement implemented today often delivers more value than a perfect plan postponed for another year, because progress is usually incremental rather than one dramatic moment of change.

#### If You Can’t Describe the Process, You Can’t Improve It
URL: https://attv.uk/blog/if-you-cant-describe-the-process.html
Published: 2026-06-24
Summary: Ask five employees to describe the same process and you may get five different answers. Mapping your workflows before buying software is the most overlooked step in digital transformation.
Key points:
  - Ask five employees to describe the same process and you may get five different answers, because most workflows evolved from habit rather than deliberate design.
  - If a process lives only in experienced employees' heads and depends on "knowing how things are done around here", the business is carrying unnecessary risk.
  - Mapping a process on paper or a whiteboard costs nothing and often reveals that companies collect the same information multiple times or wait days for approvals that add little value.
  - Software reflects the underlying process it supports: if approvals are unclear or responsibilities overlap, digital systems will expose that confusion rather than fix it.
  - The first step in digital transformation is not installing technology but understanding your own business well enough to describe it.

#### Don’t Buy Software. Solve a Problem.
URL: https://attv.uk/blog/dont-buy-software-solve-a-problem.html
Published: 2026-06-23
Summary: Businesses rushing to buy software often skip the most important question: what problem are we actually trying to solve? Technology amplifies how your business already works — so clarity comes first.
Key points:
  - Technology amplifies the way your business already operates, so weak foundations become more visible rather than disappearing when you add software.
  - Installing a CRM will not automatically improve customer relationships and an accounting package will not fix inconsistent invoicing - software cannot compensate for poorly designed processes.
  - Most organisations use only a small proportion of what they buy because they purchase software based on demonstrations rather than operational needs.
  - Before signing any contract, define measurable success such as reducing order processing from 30 minutes to 10, or cutting manual data entry by 80 per cent.
  - Deleting a redundant approval step often saves more time than automating it, so remove unnecessary steps before introducing technology.

#### If You Have to Copy and Paste It Every Day, It Should Probably Be Automated
URL: https://attv.uk/blog/if-you-copy-and-paste-it-every-day.html
Published: 2026-06-22
Summary: Copy-and-paste feels harmless — until you count the hours lost each month. Discover why stopping repetitive manual work is often the true starting point of digital transformation.
Key points:
  - If a task involves copying and pasting the same information every day, treat it as a signal that your processes are asking too much of your people - and that is usually the ideal place to begin digital transformation.
  - Five minutes of copying every hour becomes forty minutes a day, several working days a month, and hundreds of hours a year across a team - all paid for, but generating very little value.
  - The core principle is to capture data once and reuse it everywhere it is needed, so information flows between systems instead of being retyped four or five times before an order is complete.
  - Every manual copy is an opportunity for error - a dropped postcode digit, a moved decimal point or a typo in an email - and each mistake takes time to investigate and correct.
  - Automation should remove repetitive administration, not human judgement: it frees staff to do the problem-solving, creative and customer-facing work they were actually hired for.

#### Stop Automating Chaos
URL: https://attv.uk/blog/stop-automating-chaos.html
Published: 2026-06-19
Summary: Automating a broken process doesn’t fix it – it just makes the chaos faster. Simplify your workflows first, then digitise what remains.
Key points:
  - Automating a broken process does not fix it; it just makes the same chaos happen faster and at greater cost.
  - Map the process from end to end and challenge every step before adding any software.
  - Sometimes deleting a task delivers more value than automating it.
  - Involve the people who do the work daily — they know where the real waste and frustration lie.
  - Simplify first, capture data once, share it across teams, and only then automate what remains.

#### AI Will Not Fix Messy Data — It Will Amplify It
URL: https://attv.uk/blog/ai-will-not-fix-messy-data.html
Published: 2026-06-18
Summary: AI won't rescue messy data — it will amplify every inconsistency at speed. Before adopting any AI tool, clean your data, simplify your processes and build solid operational foundations.
Key points:
  - AI is only as good as the data and processes it is given; it does not create order from chaos.
  - Messy data is not fixed by AI — it is amplified, so poor decisions are made faster and spread further.
  - Clean and standardise your data and simplify your workflows before adopting any AI tool.
  - Create one source of truth, remove duplicates and document business rules so AI has solid foundations.
  - Keep humans in the loop: people supply context and judgement while AI handles repetition and scale.

#### The Most Valuable Database May Be Sitting Inside Someone’s Head
URL: https://attv.uk/blog/your-most-valuable-database-is-in-someones-head.html
Published: 2026-06-17
Summary: One of your most valuable databases may never appear on a server — it lives in your employees' heads. Capturing that knowledge is the first step towards resilience and digital transformation.
Key points:
  - One of your most valuable databases is undocumented knowledge held in employees' heads, not on any server.
  - Phrases like "ask Sarah, she knows" are warning signs of dangerous knowledge concentration.
  - If a key person is suddenly unavailable, work that depends only on their memory stops — the "bus test".
  - Documentation is not bureaucracy; it speeds up training, reduces mistakes and makes work predictable.
  - Capture knowledge with simple habits — checklists, short videos and a shared knowledge base — before a crisis forces it.

#### Excel Is Not the Problem. Treating It Like an Entire Business System Is.
URL: https://attv.uk/blog/excel-is-not-the-problem.html
Published: 2026-06-16
Summary: Excel is a brilliant tool – but when an entire business runs on one workbook, small inefficiencies compound into costly problems. Here’s how to spot the warning signs.
Key points:
  - Excel is not the problem; the problem is asking one spreadsheet to act as a CRM, database and operational system all at once.
  - When several departments edit competing copies of the same workbook, data is overwritten and trust in the numbers erodes.
  - The real cost of spreadsheet sprawl is hidden staff time spent reconciling files, not the price of software.
  - A clear warning sign is when meetings begin with "whose numbers are correct?".
  - Digitally mature businesses still use Excel — but for analysis and reporting, with operational data held in dedicated systems.

#### You Already Have a Database — Even If You Think You Don’t
URL: https://attv.uk/blog/you-already-have-a-database.html
Published: 2026-06-15
Summary: Most businesses already hold more data than they realise – in spreadsheets, inboxes, paper files and people’s heads. The challenge is not collecting it; it is organising it so it can actually be used.
Key points:
  - If you have customers, suppliers, invoices, stock or appointments, you already have a database — even if it is spreadsheets, paper and inboxes.
  - A database is simply an organised collection of information, not necessarily a server in a room.
  - The real challenge is not collecting data but organising it so it can be searched, shared, trusted and reused.
  - Paper and human memory are databases too — just slow, hard to search and impossible to scale.
  - Start by making a data inventory, choosing one source of truth for each dataset and naming an owner.

### Using AI in a Small Business

#### The Best AI Strategy Is Boringly Practical
URL: https://attv.uk/blog/the-best-ai-strategy-is-boringly-practical.html
Published: 2026-06-27
Summary: The best AI strategy for many small businesses is not dramatic. It is a disciplined habit of saving time, reducing friction and improving consistency — one sensible use case at a time.
Key points:
  - The best AI strategy for many small businesses is not dramatic transformation but a disciplined habit of saving time, reducing friction and improving consistency, one sensible use case at a time.
  - A tool that saves ten minutes every day in a real process is more valuable than a dazzling demo nobody uses twice, so businesses should not chase every new AI product.
  - A practical AI loop runs the same six steps for every task: choose the task, set the rules, write a good prompt, check the output, measure the benefit, then improve the prompt or stop using it.
  - AI adoption is a leadership and working-practice project rather than a technical one, because no policy survives senior staff pasting confidential information into unapproved tools.
  - Most SMEs do not need to become AI companies; they need to become better-run versions of themselves through clearer information, documented knowledge, safer rules, reusable prompts and stronger review habits.

#### Build Reusable Prompts, Checklists and Templates
URL: https://attv.uk/blog/build-reusable-prompts-and-templates.html
Published: 2026-06-26
Summary: AI becomes more useful when the business stops treating every prompt as a one-off experiment. A small prompt library turns occasional success into a working method.
Key points:
  - A prompt library turns AI use from individual improvisation into organisational knowledge, so the business never has to rediscover the same working prompt every week.
  - Each template should contain five things: the prompt, its intended use, the input rules, a review checklist and an example of good output.
  - A prompt without a review checklist is only half a system - pair every reusable prompt with a short checklist so quality stops depending on memory.
  - Start small with five common, safe-to-standardise tasks (meeting summary, customer email draft, process note, blog outline and proposal tidy-up) rather than building an elaborate system nobody uses.
  - Input rules must travel with every template, because a prompt safe for public information may be inappropriate for confidential data.

#### How to Reduce Hallucinations Without Pretending They Disappear
URL: https://attv.uk/blog/how-to-reduce-ai-hallucinations.html
Published: 2026-06-25
Summary: You cannot eliminate hallucinations, but you can design work so they are less likely and easier to catch: provide sources, restrict the task, surface assumptions and verify.
Key points:
  - You cannot eliminate AI hallucinations entirely, but you can design work so they are less likely, more visible and less damaging.
  - The safest factual tasks are source-bound: provide the policy, product sheet or contract clause and instruct the AI to use only that material and say so if the answer is not there.
  - Asking AI to split its output into facts from the source, assumptions, and suggestions turns one authoritative-looking paragraph into three kinds of content you can check separately.
  - A simple five-step workflow keeps AI safe: provide source material, restrict the task, require AI to list claims and assumptions, have a human check the important points, and record approval for anything external or consequential.
  - For legal, financial, medical, safety-critical, disciplinary or commercially sensitive work, AI should never be the final source of truth - it can only help draft questions or summarise for internal preparation.

#### Hallucinations Are Not Rare Enough to Ignore
URL: https://attv.uk/blog/ai-hallucinations-are-not-rare-enough.html
Published: 2026-06-24
Summary: AI can sound confident while being wrong. False confidence is the central reason businesses need review rules — fluency is not the same as evidence.
Key points:
  - A hallucination is an invented, unsupported or inaccurate AI answer presented as though it were true - and the real business danger is that it does not look uncertain, it looks authoritative.
  - Fluency is not evidence: AI scales the human tendency to trust confident presentation, so a business must separate the quality of the writing from the quality of the claim.
  - Small businesses are especially exposed because they lack the legal, compliance and review layers of large organisations, so polished but wrong output can mislead customers, break proposals or damage credibility before anyone catches it.
  - Hallucinations are most likely to hurt when AI is asked for facts without reliable source material - questions about legal requirements, regulations, grants, prices or competitors need evidence, sources and human verification.
  - The practical rule is proportional verification: the more confident and consequential a claim, the more carefully it must be checked, and AI should never be the sole source for legal, financial, medical, HR, compliance or safety matters.

#### Use AI for First Drafts, Not Final Judgement
URL: https://attv.uk/blog/use-ai-for-first-drafts-not-final-judgement.html
Published: 2026-06-23
Summary: AI output looks finished without necessarily being accurate, appropriate or wise. Treat it as a first draft and keep a human review checklist between draft and send.
Key points:
  - AI output looks finished - paragraphs, headings, confident tone, no spelling mistakes - but a piece can look finished without being accurate, appropriate or wise, so a business should treat it as a first draft, not final judgement.
  - AI is strong at structure - turning notes into headings, ordering ideas, suggesting wording and beating the blank page - which can let a manager spend fifteen minutes improving a draft instead of an hour wrestling with the opening paragraph.
  - AI does not own the customer relationship, understand the full commercial history, or carry the consequences of a wrong claim or bad promise - the business owns all of that, so the final review must sit with a person who understands the context.
  - Every important AI-assisted output should be checked for five things: accuracy, tone, authority, completeness and risk.
  - Match the review to the risk: the more external, sensitive or consequential the output, the more senior or specialist the reviewer should be, while a low-risk internal summary may only need the person who attended the meeting.

#### Make AI Ask You Questions First
URL: https://attv.uk/blog/make-ai-ask-you-questions-first.html
Published: 2026-06-22
Summary: One of the most useful prompts is: “Before answering, ask me what you need to know.” It moves tacit knowledge out of the owner’s head and into the brief.
Key points:
  - AI is too willing to answer thin or incomplete briefs, and in business an answer built on hidden assumptions is not just imperfect but actively misleading.
  - Adding the line "Before you answer, ask me up to five questions that would help you produce a better result" forces the tool to surface missing information and helps the owner notice details they assumed were obvious.
  - Small businesses run on tacit knowledge - which customers are sensitive, which suppliers are awkward, which words to avoid - and asking for questions first moves that knowledge out of the owner's head and into the brief.
  - A stronger version also asks AI to list the assumptions it would otherwise make (such as UK location or warranty status), so the business can accept, correct or remove them.
  - Clarification should not become theatre: set limits to the five most important questions, or only those that would materially change the answer, with one or two enough for quick low-risk tasks.

#### Ask in Steps, Not in One Giant Question
URL: https://attv.uk/blog/ask-ai-in-steps-not-one-giant-question.html
Published: 2026-06-21
Summary: Large, muddled prompts produce large, muddled answers. Break work into stages — understand, question, outline, draft, review — and correct the direction early.
Key points:
  - Large, muddled prompts produce large, muddled answers because most business tasks are really a chain of smaller tasks squeezed into one instruction.
  - A staged sequence - understand, question, outline, draft, review - lets you correct the direction at each stage before the answer becomes too elaborate to fix.
  - Asking in steps makes AI's mistaken assumptions visible early, so you can catch a misunderstood audience or an invented business rule before it is written into a draft.
  - Use AI to organise before it writes - sorting notes into themes, removing duplicates and suggesting an order - which is safer than asking for a polished final answer straight away.
  - The real benefit of step-by-step prompting is not just getting an answer but improving the path to the answer, which matters for important work.

#### Give AI Context, Constraints and Examples
URL: https://attv.uk/blog/give-ai-context-constraints-examples.html
Published: 2026-06-20
Summary: Generic AI output usually means the prompt supplied a request without the ingredients. Context, constraints and examples turn a text generator into a useful assistant.
Key points:
  - AI output sounds generic when the prompt asks for a result without supplying the ingredients - the tool cannot infer commercial nuance, customer expectations or house style from a short instruction.
  - Three ingredients improve small-business AI output: context explains the situation, constraints set the boundaries, and examples show the standard.
  - Examples are often more powerful than explanation because people - and AI - learn standards by seeing them, so a short sample of writing you like beats a paragraph of instruction.
  - Constraints such as word limit, British English, banned phrases, must-include points and a clear next step stop AI producing material that is impressive but unsuitable.
  - Every prompt should end by asking AI to list anything a human should check, because output is not finished merely because it is neatly written.

#### A Good Prompt Is a Brief, Not a Wish
URL: https://attv.uk/blog/a-good-prompt-is-a-brief-not-a-wish.html
Published: 2026-06-19
Summary: A weak prompt asks AI to guess. A strong prompt gives it the same brief you would give a capable colleague — task, audience, context, effect, constraints and format.
Key points:
  - A weak prompt asks AI to guess while a strong prompt gives it the same brief you would give a capable colleague: task, audience, context, intended effect, constraints and format.
  - A good business prompt contains six elements - the task, the audience, the context, the intended effect, the constraints (length, tone, things to avoid or include) and the format of the answer.
  - Vague adjectives like 'professional', 'punchy', 'modern' and 'simple' mean different things to different people, so replace them with concrete examples and boundaries such as a word limit, a defined tone and a required next step.
  - There is a difference between asking AI to 'decide our refund policy' and asking it to 'draft three ways to explain our existing policy' - AI is better used as a drafting and thinking aid than as an unaccountable decision-maker.
  - When an AI answer disappoints, improve the brief before blaming the tool, because the missing detail in the prompt usually explains the weakness in the output.

#### Start With Low-Risk Tasks, Not Business-Critical Decisions
URL: https://attv.uk/blog/start-with-low-risk-ai-tasks.html
Published: 2026-06-18
Summary: The safest first AI projects are useful but unglamorous: drafting, summarising, organising and turning messy notes into clearer documents. Build confidence before ambition.
Key points:
  - Begin with low-risk tasks — drafting, summarising, organising and brainstorming — not business-critical decisions.
  - A good early AI task has non-sensitive input, output that is easy to check, and mistakes that can be caught before they cause harm.
  - Do not automate the awkward bit first; complaints, pricing and difficult conversations need human judgement and accountability.
  - Plot tasks on a value-versus-risk matrix and start in the high-value, low-risk quadrant.
  - Do not connect AI to live business systems during early experiments; work with copied, anonymised or sample material.

#### Before You Let Staff Use AI, Write the Rules
URL: https://attv.uk/blog/before-staff-use-ai-write-the-rules.html
Published: 2026-06-17
Summary: If staff already use AI informally, you already have an AI policy — it is just unwritten and inconsistent. Replace invisible variation with a few clear house rules.
Key points:
  - If staff already use AI informally, you already have an AI policy — it is just unwritten and inconsistent.
  - A blanket ban rarely works; sensible boundaries are more realistic than pretending AI is not being used.
  - A small-business AI policy should be short and answer the practical questions staff actually face at work.
  - Divide use cases into approved, restricted and banned, with a clear "never paste" list as the backbone.
  - Human review is not optional for anything affecting customers, money, contracts, compliance or reputation — AI does not take responsibility, people do.

#### AI Is Not Magic — And It Is Not Private by Default
URL: https://attv.uk/blog/ai-is-not-magic-and-not-private.html
Published: 2026-06-16
Summary: Before a business worries about clever prompts, it must decide what should never be entered into an AI tool. Start with confidentiality, not cleverness.
Key points:
  - The first AI rule is not about prompting — it is deciding what must never be entered into an AI tool.
  - AI should not be treated as a private notebook; once information is pasted in, you lose control of where it goes.
  - Keep a clear "never paste" list: passwords, customer personal data, financial details, contracts, trade secrets and anything under an NDA.
  - Anonymisation reduces risk but is not a magic cloak — a unique situation can still identify a customer or expose pricing.
  - Free tools are not free of responsibility; check the terms before using any AI tool for work, and require human review of output.

### Learning Journal

#### Studying Computer Science at 50+: Why Building Matters More Than Waiting
URL: https://attv.uk/blog/building-projects-while-studying-cs-later-in-life.html
Published: 2026-04-02
Summary: Reflections on studying Computer Science at 50+ and why building real projects is the most effective way to learn.
Key points:
  - Building real projects teaches Computer Science more effectively than passive study, because real projects expose the gaps in your understanding with brutal honesty while reading about programming can deceptively make ideas seem clear when they are not.
  - Starting a Computer Science degree at 50+ is not too late; the author is studying for a BSc at Solent University's Birmingham campus in his fifties and treats the right time as simply the time you still have.
  - Software is never just code: a CRM built for the author's accountant taught him that listening, patience and communication matter as much as technical skill, because becoming a better developer is often tied to becoming a better listener.
  - Confidence is the result of action, not its starting point; you build it by finishing small projects, fixing stubborn bugs, and watching the once-impossible become familiar.
  - When a problem looks impossible, divide it into smaller challenges, rename and reduce it, and if you are stuck step back and change your angle, because for almost every problem there is more than one solution.

## Contact
- Email: dev@attv.uk
- LinkedIn: https://www.linkedin.com/in/attvuk/
- GitHub: https://github.com/AmigoUK