A booking change comes in by phone, a photo arrives on LINE, and a new request sits in email. At closing time, someone copies the details to the team's working sheet. The next morning, the manager opens the paper slips, phone history, and email again because nobody is fully sure whether yesterday's change was reflected.
Repair intake, class applications, event-equipment bookings, and field-service scheduling all grow small rules over time. Regular customers may call directly. A cancellation may need manager confirmation. A booking may look open until you notice the equipment is already out.
“We need an estimate soon. But what do we need to explain before signing so the project does not go wrong?”
This article is for business owners, store managers, and operations staff considering outsourced development. It helps you decide which business assumptions to align before signing a development contract.
Here, “assumptions” means the conditions your team already works with: channels, exceptions, status names, customer information, and post-launch ownership. You do not need a full specification to start. You do need a plain description of how the work actually happens.
It is natural to be unsure what to explain before signing
These situations often create the concern:
- Phone changes are reflected in the working sheet at different times depending on the staff member.
- Photos and extra details sent on LINE are checked separately from the application record.
- Paper intake forms contain notes that do not appear in email or form submissions.
- The manager knows exception rules that staff confirm case by case.
- Month-end counts are unclear because cancellations and schedule changes are handled differently.
- The team is unsure which customer information can be shared with an outside support partner.
Outsourced development does not usually fail because the business side is careless.
It often fails because everyday rules that feel obvious inside the business are invisible to the people building the system.
Saying “we need booking management,” “we need an application form,” or “we need a list” does not explain the daily decisions behind those words.
The goal before signing is not to decide every detail. The goal is to make the assumptions that can easily drift visible.
The short answer
Before signing, align five things:
- Which intake channels are used: phone, LINE, email, paper, forms, or something else.
- Who decides exceptions and when.
- Who views records and who can edit them.
- What customer information is handled.
- Who owns inquiries, updates, and monthly review after launch.
You can begin consultation even when these are not fully decided.
But if the contract scope is fixed while these items remain unclear, later changes to screens, notifications, statuses, access, and review methods become more likely.
For the first consultation, it is enough to say: “Phone, LINE, and paper are mixed today. The manager confirms exceptions. We want to decide what should be included first.”
Separate assumptions that often cause trouble
In this article, an assumption is something your team already treats as normal but an outside partner cannot see.
Use the table below to turn those assumptions into a discussion.
| Assumption to align | Daily situation | What can go wrong | What to note before consultation |
|---|---|---|---|
| Intake channels | The same request type arrives by phone, LINE, email, paper, and forms | The team does not know which source is the trusted record | Where one request enters, who first sees it, and where it is copied |
| Exceptions | Regular customers call directly, late changes need manager approval, or equipment availability changes the answer | The screen appears to accept cases that the business cannot actually handle | Three common exceptions and whether they must be included first |
| People who check records | Reception, operations staff, managers, and admin staff check at different times | One screen may expose more information than each person needs | Who views daily records, who can edit them, and what an outside partner may see |
| Status names | Unresolved, checking, replied, paid, cancelled, and delivered are mixed together | Monthly review and notification timing become unclear | Three to five first statuses and which ones count in monthly review |
| Post-launch owner | Price changes, staff changes, inquiries, and monthly review appear after launch | Small updates stop because nobody knows who owns them | What the internal team wants to edit and what should go to the support partner |
This table is not for drafting a contract alone. It is for making the first conversation clearer.
Compare common ways to proceed
You do not need to choose one perfect path before consultation. Pick the starting point that matches what is currently known.
| Approach | Best fit | Main benefit | What to check | How to ask |
|---|---|---|---|---|
| Start with a current-workflow note | The desired outcome is clear, but screens and features are not decided | The partner can help separate what must be decided from what can wait | Do not rush into fixed contract scope while key items are unknown | Requirements are not fixed yet. We want to start from the current workflow |
| Walk through one real case | It is hard to explain where missed updates happen | Real decisions are easier to understand than feature names | Hide personal details and share the flow, not private information | We want to walk through yesterday's request from intake to reply |
| Use a small prototype first | The team needs to see a screen before judging whether the workflow fits | Input fields, lists, notifications, and statuses can be checked before full development | Treat the prototype as a decision tool, not a production system | We want to prototype intake and the unresolved list first |
| Split the first scope from later additions | Everything feels necessary, but timing or budget is limited | The team can launch with the most important workflow and add later | Mention likely future needs even if they are not included first | First, we need intake and unresolved cases. Monthly review can come later |
| Decide post-launch ownership before signing | Nobody is sure who will handle inquiries and updates after launch | Maintenance, support, and internal work can be discussed before the build | If ownership is unknown, say so directly during consultation | Post-launch ownership is undecided. We want to discuss what our team should handle |
This is not a ranking. It is a way to choose the next useful conversation.
What official documentation changes about the decision
IPA's “Model Transaction and Contract Documents for Information Systems, Second Edition” explains that model contracts help make system-development transactions more transparent and support shared understanding between user companies and vendors at the contract stage (reference).
For a small business, this does not mean you must write legal documents yourself. It means the business side should be able to discuss what the workflow is, who confirms what, and how acceptance or review should work.
Japan's Digital Agency Standard Guidelines collect common rules and reference documents for service and business reform together with information-system planning and management (reference). Although written for public-sector systems, the principle is useful for small projects: do not separate the screen from the work around it.
GOV.UK's discovery guidance says teams should understand users, context, constraints, existing processes, and offline channels before building (reference). Its user research guidance also asks teams to understand what tools and channels people currently use and what problems they experience (reference).
Phone calls, LINE messages, paper slips, and working spreadsheets are therefore not side notes. They are the evidence of how the business actually runs.
When customer names, phone numbers, addresses, application details, or payment status are handled, information security also belongs in the early conversation. IPA's SME information security guideline is designed for small and medium-sized businesses, including sole proprietors and small operators (reference).
The business side does not need to memorize legal or technical terminology. It should identify who may view customer information, what can be shared with an outside partner, and who will update the system after launch.
Five things to align before signing
1. Where requests enter
If phone, LINE, email, paper, and forms are mixed, list the channels first.
Instead of saying “we want everything in one place,” say: “Phone changes are copied to the working sheet later.”
2. Who decides exceptions
An exception is a case handled differently from the usual path.
For example: regular customers call directly, late changes need manager approval, or the request depends on equipment availability.
Write only the three most common exceptions first.
3. Who views and edits records
The people who view a list and the people who edit important information may be different.
Reception may only need unresolved cases. Managers may edit prices or hours. Staff may only need their assigned cases.
If this distinction matters, discuss it before signing.
4. What customer information is handled
Names, phone numbers, email addresses, addresses, payment status, and inquiry details need deliberate handling.
Ask who can view them and what can be shared externally.
This should be checked before convenience features are added.
5. Who owns the system after launch
After launch, inquiries, corrections, price changes, staff changes, and monthly review will appear.
The internal team does not need to own everything.
But it should know who receives the first inquiry and when to ask the outside partner.
Five preparations before consultation
You do not need a perfect specification.
Write these five notes:
- Pick one real request from yesterday or last week and describe it from intake to reply.
- List whether requests arrive by phone, LINE, email, paper, form, or another channel.
- Write three common exceptions.
- Tentatively name who checks daily, who edits, and who gives final confirmation.
- Separate what the internal team wants to update from what should go to the support partner.
Blank items are fine.
They become discussion topics for the first consultation.
As a practical rule of thumb, start with one real case. If you can explain that case, the conversation will be much clearer than a list of feature names.
Pre-contract alignment checklist
Copyable consultation note
Before signing, a current-workflow note can be more useful than a finished specification.
Use the note below for an inquiry or first meeting.
Unknown items can stay as “to decide during consultation.”
Copy a pre-contract alignment note
Use this note to explain current workflow assumptions before outsourcing development. Unknown items can stay as “to decide during consultation.”
What we want to align before outsourcing development: What we want to build: Example: application form, booking management, inquiry tracker, business app Current problem: Example: requests arrive by phone, LINE, email, and paper, then someone copies them to a working sheet and updates are missed One real case: Example: phone change -> paper note -> manager confirmation -> LINE reply -> working sheet at closing time Current intake channels: Example: phone, LINE, email, paper intake form, online form Common exceptions: Example: regular customers call directly, late changes need manager approval, equipment availability can block a booking People who view daily records: Example: reception, operations staff, manager, admin staff People who edit records: Example: reception fixes name typos; only the manager changes prices or hours First status names: Example: unresolved, checking, replied, cancelled Customer information handled: Example: name, phone number, email, address, application details, payment status What the internal team wants to own after launch: Example: first-line inquiries, small wording updates, monthly review What should go to the support partner: Example: adding fields, changing notification recipients, changing screen structure, bug fixes What we want to decide during consultation: Example: first scope, whether to prototype first, and how to divide post-launch ownership
Your next step
Pick one recent request.
Where did it come from: phone, LINE, email, paper, or a form?
Who saw it first?
Where was it copied?
Who gave final confirmation?
If you can answer these four questions, you can start a useful development consultation.
You do not need to decide everything first. Start by saying: “This is the current flow. We want to decide the rest during consultation.”
Further reading
- IPA, Model Transaction and Contract Documents for Information Systems, Second Edition. Used to confirm the importance of shared understanding around specifications, project approach, and review at the contract stage. Published 2020-12-22, last updated 2025-06-17. Accessed 2026-07-21.
- Digital Agency, Digital Society Promotion Standard Guidelines. Used to confirm the relationship between service/business reform and information-system planning and management. Page last updated 2026-07-15; DS-100/110/120 updated 2026-07-15; latest establishment or revision date 2026-06-12. Accessed 2026-07-21.
- GOV.UK Service Manual, How the discovery phase works. Used to confirm the need to understand users, context, constraints, existing processes, and offline channels before building. Published 2016-08-04, last updated 2021-06-21. Accessed 2026-07-21.
- GOV.UK Service Manual, User research in discovery. Used to confirm the value of understanding current tools, channels, problems, observation, interviews, and existing data. Published 2016-11-18; no last updated date shown on the page. Accessed 2026-07-21.
- IPA, SME Information Security Guideline. Used to confirm that security guidance is intended for SMEs including sole proprietors and small operators. Published 2016-11-15, last updated 2026-07-03. Accessed 2026-07-21.