Establish a business baseline before making a digital plan
A baseline is not a lengthy report. It is a shared set of confirmed facts: what you sell, whom you serve, how work flows, where data lives and which problems matter most.
Many technology projects start with a feature list: website, customer management, automated reminders, reporting, AI. But the same feature name can mean very different responsibilities in different businesses. Without shared understanding, people quickly find themselves using the same words for different ideas.
A business baseline records how the company operates at the start of a project in concise, reviewable documents. It is not an encyclopaedia of the business. Its purpose is to give subsequent decisions a common factual foundation.
What should the baseline answer?
A practical baseline usually has six parts:
1. Business and market
- What products or services the business provides.
- Its main customers.
- Why customers choose it.
- The regions and channels through which business happens.
2. Current goals
- The most important goals for the next six to twelve months.
- Which relate to digitalisation.
- Which are only ideas, with no committed resources yet.
3. Core processes
- How customers discover, enquire, buy and receive service.
- How staff take over, approve, deliver and follow up.
- The most common exceptions.
4. Data and tools
- Where customer, order, stock, payment or project data lives.
- Which record is authoritative.
- Which tools duplicate the same data.
- Who owns accounts, domains and systems.
5. Roles and responsibilities
- Who makes business decisions.
- Who performs daily work.
- Who reviews results.
- Who can take over when a key employee is away.
6. Current problems and evidence
- Work that persistently wastes time.
- Recurring errors, delays or complaints.
- Frequency and impact.
- What the team has already tried.
Keep documents short, but reviewable
A small business’s first baseline can be a few pages with two or three diagrams or tables. Length matters less than whether the owner can confirm each statement.
Separate content into:
- Confirmed facts: agreed by the owner and supported by records or actual work.
- Provisional judgements: the most reasonable interpretation now, requiring validation.
- Open questions: conflicting accounts or decisions not yet made.
Do not present uncertain information as fact just to make a document look complete. Identifying unknowns protects later decisions.
Involve the people doing the work
Management alone may describe an ideal process. Frontline staff alone may not reveal commercial goals or who bears risk.
Ask different groups:
- Management: what outcomes matter most, and which risks are unacceptable?
- Frontline staff: how is work actually completed each day, and where do workarounds occur?
- Finance or administration: which data must be accurate, and how do errors affect settlement?
- Customer-facing staff: what do customers commonly misunderstand, wait for or complain about?
Document differences, then have the authorised decision-maker confirm the rules.
A baseline is not an unchanging truth
It captures shared understanding at a point in time. Update it when services, teams or markets change.
Each core document should retain:
- A version or update date.
- What changed.
- Who confirmed the change.
- Which plans need reassessment as a result.
Complex document governance is unnecessary. A clear date, owner and change record are already much more reliable than decisions scattered through chats.
Why this work has value on its own
Even without building a system, a confirmed baseline can support:
- Training new staff.
- Comparing vendor proposals.
- Identifying duplicate work and gaps in responsibility.
- Budget planning.
- Reducing knowledge loss when a key person leaves.
- Getting future projects into useful discussions faster.
Knowledge that previously lived only in the owner’s or senior staff’s heads becomes a shared business asset.
A minimal baseline kit
Start with four items:
- A one-page business and goals summary.
- One core process diagram from customer arrival to delivery.
- A list of tools, data and owners.
- A list of problems ordered by impact and frequency.
Once key owners review them, these are enough to discuss a digital path. Add detail as actual projects need it, rather than writing a large manual nobody maintains.
This article provides a general business-baseline method. Documentation depth should match the business’s size, risks and current decisions.