1End-to-end architecture
I design the whole flow, from the data coming in, to storage, to the AI or email that comes out, and how the team keeps it running.
Customer A: a customer knowledge platformTARGETS
- S
- About 80% of Customer A's conversations with its own customers lived only in Slack and Chatwork. Logging them in the CRM depended on manual notes, so nothing could be searched or reused.
- T
- Design one flow, from capture to AI answers to improvement, that a very small team could run.
- A
- Slack channels are logged automatically on the CRM timeline. Chatwork is handled in a second phase by posting messages to the timeline events API from an integration platform. Tickets get a category property, and the email-to-ticket rules are fixed to stop duplicates. Cross-pipeline dashboards show inquiry patterns. Resolved cases become knowledge base articles, which the customer agent uses as its source. Answer logs are reviewed regularly to improve the knowledge base. Everything is delivered in three phases: 0 to 90 days, 3 to 6 months, 6 to 12 months.
- R
- I handed over the plan with six measurable targets. I did not track attainment after the handover.
Customer B: recommendation emailsNOT LIVE YET
- S
- Customer B wanted purchase-based product recommendations in marketing emails, with a large product catalog.
- T
- Connect data collection, machine learning, CRM storage and email delivery into one flow.
- A
- Purchase data goes to Amazon S3. Amazon Personalize generates the recommendations. The results come back to the CRM as custom objects and are used in marketing emails. A partner built it, and I designed the flow together with them.
- R
- The design is complete, but it is not in production yet because of the customer's other projects. The pattern is reusable, so the partner can offer it to other customers.
Website migrations to the CMS
- S
- As a replatforming specialist, I migrated about 250 customer websites to HubSpot's CMS over one and a half years.
- T
- Take each existing site to launch, using what the CMS can reproduce.
- A
- I reviewed each site, defined what could be reproduced in the CMS, and proposed alternatives for the rest. After the contract, the customer reviewed templates and content, defects and larger changes went to the offshore team, and we finished by connecting the customer's domain.
- R
- The same process ran for about 250 sites.
2Translating between business and technology
I turn vague requests into measurable goals, and difficult technology into something the customer can judge.
Customer A: from a vague request to six targets
- S
- Customer A already owned a service platform but barely used it. The first request was to "turn the tool on", and at the kickoff the president said the requirements were too abstract.
- T
- Turn that into goals everyone could work toward.
- A
- Through interviews I reframed the real problem as running support without adding headcount. I then built six targets and three phases around it, for example automatic Slack logging from 0% to 100%, duplicate tickets to zero, and manual transcription to almost none.
- R
- I handed over a plan that could start in the first phase right away.
Customer C: explaining a partner-built connection appIN PROGRESS
- S
- Customer C is a sports league organization with 56 separate portals: one for the league and 55 for the teams. The partner built an app to connect them.
- T
- Help the customer understand the design well enough to decide.
- A
- I was not part of the design. I interviewed the partner about how it works and ran a session to explain it to the customer.
- R
- The session did not fully land. Expectations from the pre-sales stage had not been aligned, and that had to be resolved first. My lesson is to confirm what was agreed before translating the technology.
3Enterprise-scale readiness
I start from the product's limits, then decide the structure. Where I have no direct experience, I say it is a design proposal.
If Customer A's approach grew to a large enterpriseDESIGN PROPOSAL
- S
- Customer A is a small team. A large enterprise would have many brands, teams and approvers.
- T
- Governance, reliability, security and multi-team agreement become the new concerns.
- A
- Set channel selection rules at the organization level and make them the standard. Design API integrations so a retry never creates duplicate records. Limit what the AI may reference through guidelines. Roll out in stages, starting with one team.
- R
- This is a proposal, not a delivered result. The phased approach from Customer A carries over directly.
Customer C: 56 portalsIN PROGRESS
- S
- One league portal and 55 team portals, run independently.
- T
- Keep shared definitions consistent, report across all portals, and decide what may be shared between teams.
- A
- My design thinking is for the league to distribute common definitions such as property names and templates, to collect cross-portal reporting outside the CRM, and to split organizations where needed. In reality the partner built a connection app, and I helped the customer understand it.
- R
- Support is starting now.
A repeatable process across about 250 sites
- S
- About 250 migrations over one and a half years, each for a different customer.
- T
- Keep quality and speed consistent every time.
- A
- One standard flow: requirements, alternatives, contract, review, fixes, domain connection. The target was go-live within three months, and execution work went to the offshore team while I owned the customer relationship and decisions.
- R
- Roughly 80% went live within three months.
4Architecture trade-offs
I choose based on two questions: can the team operate it, and is this capability the core of the value? A specialist service wins when the answer to the second is yes.
Build or buy: Customer A
- S
- A small team that already owned the service platform.
- T
- Remove manual work with no new investment and minimal operating load.
- A
- Phase 1 uses only standard features and the existing Slack integration, with no custom development. Only Chatwork, which standard features do not cover, needs custom work in phase 2.
- R
- The first 90 days need no extra investment.
All-in-one or specialist service: Customer BNOT LIVE YET
- S
- Recommendation quality was the core of the value.
- T
- Decide between doing it all in the CRM or using a specialist service.
- A
- I used Amazon Personalize for the machine learning and connected it by API, so the CRM focuses on customer data and email.
- R
- The design uses a specialist for the part that matters most. It is not in production yet.
Speed or scalability: phased deliveryTARGETS
- S
- Customer A needed results quickly without overloading a small team.
- T
- Get early value while keeping room to grow.
- A
- Three phases: quick wins in 0 to 90 days, expansion in 3 to 6 months, optimization and scale in 6 to 12 months.
- R
- What finishes in the first 90 days is separate from what comes later.
Fidelity or feasibility: website migration
- S
- An existing site cannot always be reproduced exactly in the CMS.
- T
- Forcing it would produce hard-to-use templates.
- A
- Before the contract I listed what could and could not be reproduced and proposed alternatives for the rest.
- R
- Expectation gaps were smaller by the time we started.
5Technical depth and my own contribution
I can explain the decisions I made myself, with the constraint, the alternative I dropped, and the reason.
Customer B: property or associated custom objectNOT LIVE YET
- S
- Recommendations had to appear in marketing emails for a large product catalog.
- T
- Decide how to store the recommendations.
- A
- I first planned a contact property, but the product count did not fit a dropdown property because of the property limits. I found that a custom object associated with the contact can also feed marketing emails, so I chose that. The decision was mine.
- R
- The structure works for both reporting and dynamic email content. Production launch is still ahead.
Customer A: connecting ChatworkTARGETS
- S
- Slack could be logged with a standard integration. Chatwork could not.
- T
- Get Chatwork conversations onto the same timeline.
- A
- The plan posts messages to the timeline events API from an integration platform in phase 2, and leaves development until after the first phase shows results.
- R
- The first 90 days need no development, and the Chatwork work can be judged on evidence.
Reviewing template code from the offshore team
- S
- The offshore team built templates and modules during site migrations.
- T
- Check quality before the customer sees it.
- A
- I read the template code myself, checked how it was structured, and judged whether it was easy to use and not carelessly built.
- R
- I could check the construction, not just the appearance.
6Project and offshore delivery
I was the customer's front person and my offshore team in India did the build. I owned agreements and requirements, they owned production and fixes.
About 250 migrations with an offshore team in India
- S
- Over one and a half years I ran about 250 website migrations to the CMS, all with the same offshore partner.
- T
- Reach go-live within three months, despite the time difference, with clear responsibilities and consistent quality.
- A
- I reviewed the customer's site, defined what the CMS could reproduce, and proposed alternatives before signing. After the contract, customers reviewed templates and content, and I passed module defects and larger changes to the offshore team. We worked through documents and Slack, and because of the time difference I asked customers to review in small increments. I read the template code myself to check quality. We finished by connecting the customer's domain.
- R
- About 80% went live within three months.
What was hardest: expectation gaps after the contract
- S
- Marketers' expectations and what the tool can do were often different.
- T
- Reduce the gap before the contract rather than after.
- A
- In pre-sales I ran careful demos and wrote down what we agreed.
- R
- Requirements can never be fully fixed in pre-sales, so I put real effort into due diligence early.
Customer B: a domestic partner team
- S
- A partner in Japan implemented the recommendation emails: the founder, who is a developer, and two implementers.
- T
- Split design and implementation clearly, and resolve behavior that was not documented.
- A
- I designed the flow together with them as the technical consultant. They implemented, I made design decisions and gave technical support. We used meetings and Slack, and I confirmed undocumented behavior directly with the product team.
- R
- It went forward without major issues, and the partner was never left waiting.
7Stakeholders and conflict
I do not hold a conflict between individuals. I move it to the right level, and I give abstract problems a shape everyone can see.
Customer A: making an abstract problem visible
- S
- At the kickoff the president said the requirements were too abstract, while the team felt that information piled up in Slack and was hard to find later.
- T
- Put the president and the team on the same picture.
- A
- I summarized the problem as six targets and three phases on one page, showing what is measured, by when, and how.
- R
- Both sides started the first phase with a shared goal.
Customer C: a delivery that broke downIN PROGRESS
- S
- Customer C was meant to implement with a partner. The partner brought in a one-off subcontractor, who could not interpret the specification that was delivered and left. The customer decided to work from the specification themselves but could not follow it.
- T
- The request came to me directly. At the same time, expectations from an earlier stage were still being disputed.
- A
- I advised that the request should go through the proper escalation path instead of being handled between individuals. It was escalated, and I was assigned to support the specification review.
- R
- This is just starting. My plan is to resolve the misunderstanding first, then split the specification by function and explain it in words and diagrams the customer can judge, checking understanding as we go.
8AI architecture and value
I let AI handle routine questions so people can focus on difficult ones, and I use the platform's built-in AI protections rather than building my own.
Customer A: a customer agent on top of a knowledge baseTARGETS
- S
- Most of Customer A's customer conversations could not be searched or reused, and the team could not keep up without hiring.
- T
- The first request was to turn on an owned tool, but the real task was to run support without adding people.
- A
- Conversations are logged on the timeline and turned into categorized tickets. Resolved cases become knowledge base articles, which the customer agent uses as its source. Guidelines set what it may reference, its tone and when to escalate to a person. For data protection I used the platform's built-in controls: customers can opt out of model training, AI providers are contractually barred from training on customer data, and retention is kept to a minimum. For evaluation, answer logs are reviewed regularly and the knowledge base is fixed from wrong or weak answers, with a target of at least 60% answer coverage.
- R
- These are targets that I designed and handed over. I did not track attainment after the handover.
Customer B: machine learning for recommendationsNOT LIVE YET
- S
- Customer B wanted purchase-based recommendations in email.
- T
- Recommendation quality was the core value, so the machine learning needed specialist capability.
- A
- Purchase data goes to S3, Amazon Personalize creates recommendations, the CRM stores them as custom objects, and marketing emails use them. The specialist service does the learning and the CRM handles customer data and delivery.
- R
- It is not in production yet, so measuring the effect is still ahead.
9Customer value and measurable outcomes
My role is to make outcomes measurable and hand them over, with a current value, a target and the means for each.
Customer A: six targetsTARGETS
- S
- Recording was manual, nothing could be searched or reused, and there were no measures.
- T
- Let the customer verify the return on its investment.
- A
- I set six targets, each tied to how it would be achieved (table below).
- R
- The design aims at three outcomes: no manual transcription, knowledge that can be found, and less duplicate work. I did not track attainment after the handover.
Website migrations: go-live in three months
- S
- The value for a migration customer is a live site that matches expectations, quickly.
- T
- Make that measurable.
- A
- The target was go-live on the CMS within three months. I aligned requirements and expectations before the contract and asked customers to review in small increments afterward.
- R
- About 250 sites, with roughly 80% live within three months.